feat: stop waiting for signatures if the chain tip advances #5801
Conversation
This could happen at the beginning of a tenure, if the miner for tenure T+1 proposes its first block before it sees the last block from tenure T, so the block it proposed is reorging that last block. Once it sees this block, it should immediately stop waiting for signatures and instead build a new block off of the new tip. Fixes: #5751
|
Looking at integration test failures now... |
|
Hmm -- I was thinking today about reviving this PR (#5284) I think these have some overlapping goals. #5284 is a little more preemptive, with the downside that maybe the block its waiting on doesn't get confirmed. But this PR (#5801) seems like it may not have a very large behavioral impact (presumably, its block proposal is going to be getting rejected pretty quickly anyways?) |
|
Ah, I forgot about that one. They are tackling similar problems. This one was initiated due to seeing this problem on mainnet, worsened by the fact that these blocks at the edges of tenures often hit the "split-brain" responses from signers, where depending on the timing of the Bitcoin block for each signer, some will approve the last block from the previous tenure, and some will approve the first block from this tenure. This creates a scenario where we're more likely to get stuck in limbo, where, due to unresponsive signers, one or both of these blocks is unable to reach 30% rejections or 70% approvals. In the case we saw, the last block of tenure N-1 got approved and the first block of tenure N was stuck with <30% rejections and <70% approvals, so we just had a stall for the rest of the tenure. The solution in #5284 would have worked well for that case, but would still have a problem when the opposite happens -- when the last block of tenure N-1 is stuck in limbo. With #5284 in place, the miner for tenure N would wait unnecessarily for that block to get approved, when it could have successfully mined its own first block, ignoring that proposal. I think the solution here works well in both cases. |
This is needed for the case where the miner is knowingly reorging the previous tenure, which is the canonical tip, but this reorg is allowed because of the bad timing of blocks.
This could happen at the beginning of a tenure, if the miner for tenure T+1 proposes its first block before it sees the last block from tenure T, so the block it proposed is reorging that last block. Once it sees this block, it should immediately stop waiting for signatures and instead build a new block off of the new tip.
Fixes: #5751