When a sortition is missed and the last miner hasn't mined a block, it doesn't create a TenureExtend transaction

[hstove]

I'm not 100% sure on what's happened, but here's what I'm piecing together:

• During BTC block 687980, miner produces some blocks
• At around 2:33 PM PST, a new BTC block (981) comes in. The same miner is the winner. This miner seems to get the BTC block faster, because it starts proposing a block on the new consensus hash, but every signer is rejecting it (due to "mismatched sortition view").
• After a few fully rejected block proposals, the miner finally starts to get some acceptances, but not enough to produce a block.
• At around 2:34, BTC block 982 happens. There is no sortition winner.
• At ~2:35, the same miner produces another block, but this time using the consensus hash from 980 (??). Signers reject this block and all future block proposals, because the consensus hash is definitely wrong this time.

Once the next BTC block comes in, everything clears up and goes back to normal.

Links:

• https://api.hiro.so/v3/sortitions/burn_height/867980
• https://api.hiro.so/v3/sortitions/burn_height/867981
• https://api.hiro.so/v3/sortitions/burn_height/867982

Miner pubkey: 021b27219c6644eff1e324658aa614a525051f42d60e7f83036ca31d01c362cbb2
Miner addr: 1NDxDDSHVHvSv48vd27NNHkXHYZjDdVLss

[kantai]

Yeah -- this chain of events seems like a correct explanation to me.

In the miner code, each miner thread is associated with a single burnchain view. When the bitcoin block changes, the miner thread finishes any block proposal they had pending and then closes the thread.

Separately, the logic for tenure extensions due to "no sortition" is as follows: if there's a burn block without any sortition, the miner checks if the last tenure with accepted blocks was won by them. If so, a new miner thread is spawned with an instruction to start a tenure extension from that tenure.

Taken together, this means that if the miner for 980 produced blocks, the miner for 981 did not produce blocks, and 982 contains no sortition, the miner for 980 will wake up and attempt to tenure extend.

I think the best behavior here would be for the miner of 981 to try to start a normal tenure and then tenure extend to 982. This logic would come before the tenure extension check in the relayer so that if its the same miner in 980 and 981, they try to build off of 981 rather than trying a tenure extend from 980. If they're not the same miner, the 980 miner may try to perform a tenure extend and it would be up to the signer set to choose whether or not to approve it (which they would if the miner of 981 misbehaved).