You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The rough design discussed for this involved a bitvector in the block header which would be included in the hash that stackers sign (but not the miner, because the miner cannot know which stackers will participate when the miner signs the block).
But there's several elements that need to implemented (beyond figuring out who to include or not include in the bitvector, and what the punishment for non-participation is):
Construction of the bitvector itself: the order and length of this bitvector is consensus-critical, and so it must be a deterministic function of the stacker set (e.g., the lexicographically sorted list of stacker keys).
Inclusion of the bitvector in the signer's signature
Inclusion of the bitvector in the Nakamoto block header and the stacker signature verification routine
Code in the signer-binary operating as the coordinator which constructs the bitvector at the start of a signing round
Code in the signer-binary operating as a signer which only signs if the bitvector includes themselves (note: what if a coordinator consistently doesn't include a signer -- does the signer have any recourse?)
The text was updated successfully, but these errors were encountered:
Per SIP-021: Signer Liveness Enforcement, the
stacks-node
must have a way to validate which stackers signed a block.The rough design discussed for this involved a bitvector in the block header which would be included in the hash that stackers sign (but not the miner, because the miner cannot know which stackers will participate when the miner signs the block).
But there's several elements that need to implemented (beyond figuring out who to include or not include in the bitvector, and what the punishment for non-participation is):
The text was updated successfully, but these errors were encountered: