Signer should allow a tenure-extend to let the previous miner continue mining if the next miner did not start mining before the timeout

[obycode]

Signers should accept tenure extends from a previous miner if the current miner did not start mining before the required timeout.

[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

[hstove]

@obycode maybe I'm just forgetting, but I thought we'd implemented extends when there was no sortition winner? What's the difference - to my cursory glance, it seems like when the null miner wins, block_snapshot.sortition == false, so wouldn't that be the same case?

[obycode]

Yeah thanks for pointing that out. Also, we do see these tenure extends working when the cause is not a flash block. It seems that the actual problem is probably solved by #5515. Maybe this scenario just needs an integration test in order to close it.

[aldur]

#5515 solves the miner side of this issue.

Renaming this one so that it tracks what needs to be done on the signer's side.

[jferrant]

It looks like the signer is already primed to accept tenure extends from the prior sortition if the current sortition miner has been marked as SortitionMinerStatus::InvalidatedBeforeFirstBlock (which happens when the block_proposal_timeout has been exceeded). @obycode has written the following test already tenure_extend_after_failed_miner which was written prior to miner changes. Running this test against #5515, it still fails (don't seem to see Miner 1 issue a tenure extend). If anyone takes this ticket, work from there.

[aldur]

CC @kantai since he has taken over #5515

[blockstack-devops]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.