Conversation
Use prettier's `prosewrap` setting to wrap lines at column 80.
Open these as discussions in the PR instead.
…sips into hirosystems-draft/better-blocks
| set. Would-be producers are ranked by these BTC expenditures, and the top 100 | ||
| will be selected for the producer set. |
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. For example:
| 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 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.
No -- I don't have any commit permissions on this repo. You should have write perms to |
|
Yup, we're good -- I'll push to https://github.com/hirosystems/sips/commits/draft/better-blocks |
3 participants
Supersedes #147