You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
&& max_txs > u64::try_from(anchored_block.txs.len()).expect("too many txs")
{
info!("Relayer: Succeeded assembling subsequent block with {} txs, but had previously produced a block with {} txs", anchored_block.txs.len(), max_txs);
returnNone;
}
Note: this problem is not present after epoch 3.0.
The text was updated successfully, but these errors were encountered:
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
.stacks-core/testnet/stacks-node/src/neon_node.rs
Lines 2634 to 2639 in 1c53156
Note: this problem is not present after epoch 3.0.
The text was updated successfully, but these errors were encountered: