Miner M1 mines block B1 and submits its block commit
Miner M2 mines block B2 and submits its block commit
Miner M3 has not yet received block B2, so it mines block B2', containing 4 transactions, and submits its block commit
Miner M3 receives block B2, so it mines block B3, containing 2 transactions
Miner M3 does not RBF its previous block commit with this new block B3, because B3 has less transactions than B2'
So basically miner M3 is intentionally reorging block B2 -- risking its block getting reorged (which it does) just to get a couple more transactions included in the block. This is not the best default strategy and was likely a mistake in the code. It should only prefer the block with more transactions if they are at the same height.
It hits this case and does not resubmit a new block commit, though the change should likely be made inside get_mine_attempt.
I observed this situation on testnet:
So basically miner M3 is intentionally reorging block B2 -- risking its block getting reorged (which it does) just to get a couple more transactions included in the block. This is not the best default strategy and was likely a mistake in the code. It should only prefer the block with more transactions if they are at the same height.
It hits this case and does not resubmit a new block commit, though the change should likely be made inside
get_mine_attempt
.https://github.com/stacks-network/stacks-core/blob/1c5315606ae0cd006b27617302223b164b6f362f/testnet/stacks-node/src/neon_node.rs#L2634-L2639
Note: this problem is not present after epoch 3.0.