Draft: Better block SIP (not ready for review)#148
Draft: Better block SIP (not ready for review)#148kantai wants to merge 13 commits intostacksgov:mainfrom
Conversation
Use prettier's `prosewrap` setting to wrap lines at column 80.
Open these as discussions in the PR instead.
sips/sip-0xx/sip-0xx-nakamoto.md
Outdated
| open a new DoS vector. This cap will also prevent the block-signing process from | ||
| becoming too expensive. To this end, the total amount of BTC spent in the | ||
| outputs described in "Producer Set Enrollments" is used to select the producer | ||
| set. Would-be producers are ranked by these BTC expenditures, and the top 100 |
There was a problem hiding this comment.
Previously, I brought up rolling over credits for the BTC expenditures of would-be producers that do not make it into the top 100. The point behind this would be to ensure that small miners wouldn't be disadvantaged by a large miner that could push them out of the top 100, thus wasting their BTC for no rewards.
Open questions:
- Do you think this is necessary to avoid disadvantaging small miners?
- Does this open a DoS attack?
- Maybe it should have some minimum amount, some maximum number of consecutive terms that credits can rollover, and/or some maximum number of producers.
There was a problem hiding this comment.
Do you think this is necessary to avoid disadvantaging small miners?
I don't think so. Looking at the history of miner contributions in Stacks 2.0, the highest number of miners is ~7-8, so I think it's probably not worth the mechanics in the protocol to support roll overs.
Does this open a DoS attack?
Depending on implementation, yes. It would need a maximum rollover lifetime and a lower limit.
However, on reflection, I wonder if setting a "top 100" rather than a threshold like 1% of the total is a bad design. A top 100 incentivizes big miners to split up their commitments to crowd out smaller miners.
There was a problem hiding this comment.
I agree. A 1% minimum is a better option.
| During a term, producers in the set are eligible to receive a portion of the | ||
| coinbase rewards and transaction fees for blocks they produce. Since a term is | ||
| defined as 10 Bitcoin blocks, the coinbase reward is equal to 10 times the | ||
| coinbase as defined in **_<which SIP defines this?>_**. This amount is |
There was a problem hiding this comment.
Where is the coinbase amount defined? I couldn't find it.
|
|
||
| The producer set is then incentivized to continue producing blocks throughout | ||
| the term by the transaction fees. Transaction fees are paid only to producer set | ||
| participants who signed the blocks produced. For each block, _B_, the total BTC |
There was a problem hiding this comment.
Does this incentivize some kind of race to submit a block to the stackers to sign before all of the producers have had a chance to sign it (after 67% have signed)?
There was a problem hiding this comment.
I think it does incentivize trying to minimize the set of signers, yes. I'm not sure if this is a time-race, though.
…sips into hirosystems-draft/better-blocks
…ions and related work
…nd stackerdb in more detail
Instead of taking the top 100 would-be producers, any would-be producer that spends more than 1% of the total BTC spent in the selection process will be included. This prevents a large miner from spreading its spend out across multiple different producers to try to crowd out smaller producers.
|
@jcnelson would you be able to add some architecture/flow diagrams? I am definitely a visual learner |
|
@jferrant Yup, sure thing. Will do so as soon as I'm able, once we've had a chance to think more about how the implementation will work out. |
|
Superseded by #155 |
4 participants
This is a draft of the better blocks improvement proposal currently being put together by myself, @obycode, and @jcnelson.
This includes the commits from PR #147 (I can't build on that PR because I don't have branch commit privileges)