P2w/review spec #2
Conversation
Initial go More comments Remove ~ file added accidentally
| [kp] We don't need stratum v2 at all. If the grinding machines talk to a | ||
| braidpool controller hosted on their facility, then the need for a secure | ||
| communication layer to a pool operator disappears. [/kp] | ||
|
|
There was a problem hiding this comment.
Correct. I'm just trying to isolate concerns that braidpool won't solve here. Encrypted hasher-pool communication is one of them that we won't tackle and if you need that, use StratumV2. That's all I'm saying here.
| @@ -65,6 +77,9 @@ Transaction` transaction is included in the `Merkle Root`. We assume that this | |||
| [consensus mechansim](#consensus-mechanism), for instance in an `OP_RETURN` | |||
| output. | |||
|
|
|||
| [kp] We are getting into too many details here. The reader has no clue | |||
| about why we are using P2TR. [/kp] | |||
|
|
|||
There was a problem hiding this comment.
P2R is required for FROST/ROAST and this doc should specify at that level of detail, though I think at this point in the doc is not the correct place to explain FROST. (which should come below)
| document is going to cover. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
I'm not opposed to combining the two documents...
|
|
||
| [/kp] | ||
|
|
||
|
|
There was a problem hiding this comment.
I think I was trying to get at the difference between committed and uncommitted data, why both exist and the difference between them (which comes down to some being controlled by consensus and some not).
| Why P2TR? Are we just being fancy, or do we really need it? If so, let's | ||
| motivate why and explain it clearly. | ||
|
|
||
| [/kp] |
| write out a simple formula to capture it precisely. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
Here I am describing the sum of all block rewards and fees.
Elsewhere we should describe how shares are paid out. (proportional)
Probably more clarity would be good...
| relationship. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
Because block timestamps are delayed and have very poor resolution. The DAA needs higher resolution timestamps.
| Why is this important? Let's explain that before we provide a solution to the | ||
| problem. | ||
|
|
||
| [/kp] |
There was a problem hiding this comment.
This is described in the DAA algorithm: https://rawgit.com/mcelrath/braidcoin/master/Braid%2BExamples.html
A review of which here is needed, I agree.
| [kp] | ||
| Add referent to Meni Rosenfeld's work here: https://arxiv.org/abs/1112.4980 | ||
| [/kp] | ||
|
|
There was a problem hiding this comment.
👍 I want to use proportional, described there in sec. 2.1.
| don't even mention the nonsense. | ||
|
|
||
| [/kp] | ||
|
|
| me think we need that overview section with a system architecture diagram where | ||
| each component has clearly defined responsibilities. | ||
|
|
||
| [/kp] |
There was a problem hiding this comment.
I claim that none of the pool hopping algorithms actually work. As such I'm trying to keep it simple because there's a very wide space of reward redistribution that can become very political without actually solving the claimed problem (pool hopping). Also as the pool doesn't store funds, most payout mechanisms are not available to us (e.g. PPS and variants which are most popular now).
So IMHO it's best to use the simplest solution, and NOT address the pool hopping problem. If you think you can solve it the go ahead and try, but this has consumed the minds of many without any satisfactory solution.
| that is enough time to be sure the block is not going to be orphaned. | ||
|
|
||
|
|
||
| [/kp] |
There was a problem hiding this comment.
Because the DAG keeps all beads, we can receive a bead that is 100 blocks old, and it will be in the DAG and we have to figure out what to do with it.
We also have to punish latency to the extent that they create orphans. I have a formula somewhere of the probability of becoming an orphan as a function of latency. We could use this to decide rewards.
| using them. | ||
|
|
||
| [/kp] | ||
|
|
| more reward. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
...give the miner
| This is pretty standard in DAG based broadcast and consensus algorithms. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
Let me introduce you to Iota, which violated this, and was top of my mind years ago...
| We therefore don't need any resolution or main chain algorithms here. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
I should clarify these are share-transactions here, not bitcoin transactions.
| are candidate bitcoin blocks, then we don't need the SSDW algorithm. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
For resolving double-spends among share-chain transactions (not bitcoin transactions).
| braidpool. There is no loss of weight over time. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
With two chains in a fork, one having half the difficulty per block of the other chain, the one with half-difficulty blocks can be "longer" but have less work.
| minimum difficulty and maybe even geographic location. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
Yes. If a miner-selected difficulty is too low it cases the DAG to be very thick and is a DOS vector.
Multiple instances of braidpool don't serve much purpose. It's best to have everyone using the same instance for variance reduction reasons. Markets gravitate to liquidity and having all the mining in one place is a benefit to all (without the attendant risks of centralized markets or 51% attacks).
| This sounds like a problem. | ||
|
|
||
| [kp] | ||
|
|
There was a problem hiding this comment.
Correct.
If we fully sign the UHPO transaction before it is needed, anyone can broadcast it and it's a DOS vector. If we don't, we have to figure out how to sign it after pool failure. Those are the only choices and we'll have to figure it out...
|
|
||
| [/kp] | ||
|
|
||
|
|
There was a problem hiding this comment.
A cash-out storm is expected at each DA epoch. This is partially mitigated by having 2 weeks in which market makers and miners can swap and aggregate their shares.
I'm not sure what else we can do about this. We could rate-limit withdrawal transactions, or just let the fee market take care of it.
| get close to that difficulty. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
The share value is determined by both (1) difficulty and (2) earned income (number of blocks won and fees).
After (2) is determined at the end of the epoch, the share value can be calculated and indeed all beads with that difficulty will have the same value, up to latency punishment.
The point of the above paragraph is that the UHPO transaction is constructed before the end of the epoch and before (2) is known. Therefore a different calculation must be used. But it's not that big a deal, you just pretend that the current epoch ends at the current block.
| an attacker? | ||
|
|
||
| [kp] | ||
|
|
There was a problem hiding this comment.
If the attacker knows the IPs of miners in the ceremony he can DoS them.
Therefore IPs involved in the ceremony must be hidden from public. I suggest that when publishing a block, the miner finding the block encrypts the relevant IP/API endpoint in the corresponding bead for each other miner involved in the ceremony. Therefore only miners involved in the ceremony will know each other's IPs.
A second mechanism would be to use a mixnet or Tor or something. This question needs more thought.
| constitutes the ceremony. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
RCA = Rolling Commitment Authorization -- the output representing the sum of pool funds, which is then spent by the UHPO transaction.
Deleting key shares -- this is possible with Verifiable Secret Sharing. As long as
| transaction. | ||
|
|
||
| [kp] | ||
|
|
There was a problem hiding this comment.
This is part of market design. As we don't want to design a market, we don't have to solve atomic swaps or guarantee that this (private) contract is executed.
| contracts. If we can, I think we should. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
Holding shares is a futures contract that is cryptographically guaranteed.
| have no market value at all. Meanwhile G BTC is G BTC. | ||
|
|
||
| [/kp] | ||
|
|
There was a problem hiding this comment.
The hashrate derivative is a bet on this epoch's shares vs next epoch's shares. (e.g. does the hashrate go up or down?) One can do that by promising to buy the next epoch's shares using this epoch's shares at a fixed price. Could also be done using bitcoin as the denominator. But fundamentally hashrate derivatives are a 2-epoch discrete derivative.
Some more questions and comments.
I feel we still have some way to clarify various components - how they work and what is their responsibility. We also need to align on a few things. I have taken notes on where I think we are not aligned, will send them offline via email.
Note: This PR is meant to share comments, it shouldn't be merged.