Miner should generate a tenure-extend and continue mining if the next miner does not start mining

[obycode]

Currently, the miner will generate a tenure-extend and continue mining if there is no sortition in the next burn block, but it should also do this if there is a sortition, but the next miner does not mine a block within some threshold time.

[obycode]

Sometimes, the next miner is unable to mine any blocks, so the previous miner should be able to tell for sure that it can extend its tenure. This happens if the winning miner's block commit is not committing to the correct tenure. Sometimes this will happen if a miner's block commit is not RBFed in time. #5064 could help with this, avoiding the need for an RBF.

[obycode]

If a miner sees that the next miner is in this situation, it should go ahead and immediately submit a tenure extend.

[obycode]

I think this scenario is happening often currently in mainnet, causing pauses in block production. One example I looked at:

• 1730421788.150710: 868333 arrives
• 1730421788.918551: Miner submits a block commit committing to 179741
• 1730421790.755410: Tip advances to 179746
• 1730421792.239285: Miner builds 179746'
• 1730421811.364948: Signers reject 179746' because the last miner built 179746 already
• 1730421812.605401: Miner builds 179747
• 1730421824.720642: 179747 is approved and tip advances
• 1730421825.640789: attempt to RBF block commit, committing to 179747
• 1730421849.696787: burn block 868334 arrives, including the original block commit

[obycode]

#5452 solves the case where the winner has a bad block commit. This is the common case that we currently see on mainnet, so it is the more important one to solve.

The timeout case will be done in a separate PR, but there is already an integration test ready for it, tests::signer::v0::tenure_extend_after_bad_commit tests::signer::v0::tenure_extend_after_failed_miner, though not enabled in bitcoin-tests.yml.

[hstove]

The timeout case will be done in a separate PR, but there is already an integration test ready for it, tests::signer::v0::tenure_extend_after_bad_commit, though not enabled in bitcoin-tests.yml.

Typo I think, the non-enabled test is tenure_extend_after_failed_miner

[obycode]

Ah, you're right thanks! I'll edit the earlier comment to avoid confusion later.

[hstove]

@obycode is this good to close?

[obycode]

Not yet. We don't yet extend in the case where the block commit is good but the miner doesn't mine any blocks for some reason. I think this case is less important so we can leave this as a todo after the other tenure extend work is complete.

[obycode]

Another case of this is when there are valid block commits, but the null miner wins the sortition. The previous miner should extend and continue mining in this case.

[obycode]

Sample logs of this happening on 12/11 at ~8:00 PM Eastern here