Signers should capitulate on allowing a reorg on badly timed block

[obycode]

Currently, a tenure can be reorged when the next Bitcoin block arrives within first_proposal_burn_block_timing_secs of the first block proposal in that tenure. This ensures that an honest miner is not punished because of bad timing of the previous miner and the next Bitcoin block.

This can lead to a standstill scenario when some of the signers, more than 30% but less than 70%, saw the timing which would allow the reorg and the rest of the signers, also more than 30% but less than 70%, saw the timing which would not allow the reorg. In this case, the miner of block N-1 would be rejected when it attempts to tenure extend and the miner of block N would be rejected when it attempts to reorg. This tie will never be broken until the next Bitcoin block arrives, meaning the chain is stalled.

A solution to this problem would be to have the signers that are attempting to allow the reorg to capitulate, and allow the tenure extend if it determines that the reorg will not be accepted by the network.

My initial, simple proposal is to accept the reorg from miner N on the first proposal, but if that reorg attempt is rejected by the network, then they should accept the next attempt to tenure extend from miner N-1 and reject any further attempts to reorg from miner N.

[diwakergupta]

This can lead to a standstill scenario when some of the miners, more than 30% but less than 70%, saw the timing which would allow the reorg and the rest of the miners, also more than 30% but less than 70%, saw the timing which would not allow the reorg.

Did you mean signers instead of miners here?

[obycode]

Did you mean signers instead of miners here?

Yes, fixed. Thanks!

[obycode]

Additional comments from @kantai:

I think we’d want to use the proposal reject reason code for this
Like, the signers know when a proposal crosses the reject threshold
But they need to know if it’s because the tenure reorg was bad (different from just not confirming enough blocks)
And then they should mark that miner as invalid in the chain state sortition tracking struct
And we want to make sure that decision propagates if there’s an empty sortition