An Undercutting attack as described in this paper, is a mining strategy which involves producing new blocks not on the longest known chain, but instead 'undercutting' the longest chain by building a block, which collects less of the available transactions' fees, on a shorter chain. This behavior creates a direct incentive for another miner to now build new blocks on the 'undercutting' chain as there exist a higher sum of transactions' fees for them to collect.

In the paper, the authors describe how this can lead to a situation in which a 51% attack can be successfully carried out with less than 51% of the hashing power of the network. This is enabled due to the undercutters orphaning blocks and lowering the effective hashing power of the network (the 51% attackers have an advantage as they needn't orphan their own blocks, but the honest or undercutting miners work at a cumulatively lower hash rate due to the potential orphaning of higher value blocks).

Are there any solutions which disincentivize Undercutting behavior? Or, can the behavior be mitigated through a change to the protocol?


1. You will never be able to re-mine the previous block and get more fees.

Since Bitcoin Core 0.11.0 (July 2015) transactions include a nLockTime to discourage fee sniping and ensure they can only be mined at a height greater than current head. Their fees can only be collected by moving forward and not by undercutting previous block. Although adoption is not widespread, you can expect it to be if this threat became credible. Also, a chain leaving less fees for the next miner will be less attractive for other miners to continue.

This would be the opposite case to the attack described in the mentioned paper, which consists on re-mining a block to claim less fees and incentivize other miners to continue it instead of the honest one.

2. Mempool will not be shallow enough for consecutive blocks to have significantly different reward.

Marginal utility of transactions decreases as fees get more expensive, so Bitcoin users face a trade-off between waiting a bit longer for block inclusion (until congestion subsides) or pay higher fees.

We can observe that the more transactions are queued in the mempool, the higher and flatter is the fee slope, and the lower will be the difference between contiguous block rewards. This is due to abnormally high fees of high priority transactions published between blocks (that heap on the left of the charts) representing a smaller fraction of the total reward.

Check the clear cut at 250 sat/WU for most transactions of December 22, 2017. Most people is not in such a hurry for transaction confirmation after all when fees become significantly high, and they will be willing to pay little more for their transactions to be mined in 6 hours time instead of 7 hours.

Fees 5/9/2018 Fees 30/5/2019 Fees 22/12/2017

Rewards immediately after a block is found are certainly NOT zero, "making it unprofitable for any miner to mine", as they claim.

3. Miners can always hedge undercutting risk.

Miners could include an anyone-can-spend output in their blocks, as a premium to mitigate the risk of other miners undercutting them, when their rewards are much more valuable than the fees remaining in the mempool. So, there is no need to alter transaction selection to make this possible.

  • "Fee variability between contiguous blocks should be very small" does not seem obvious to me. Given that the block interval can vary substantially just that would create a variance in the block rewards, but then the blockspace demand is highly dependent on other market developments as well as daily and weekly cycles. – Murch May 19 '20 at 0:13
  • This tweet just repeats the point that rewards are flat but doesn't elaborate the thought process to substantiate the claim. Is there a write-up in longer form somewhere? – Murch May 26 '20 at 23:45
  • Thanks for the elaboration! – Murch May 29 '20 at 17:38

Yes, this is also known as fee sniping.

Most wallets I know of (*) set the nLockTime to the tip in order for the created transaction to only be allowed to be included in the next block (or the block would be rejected by all the verifying nodes and the miner would lose money : the nLockTime rule is a consensus one).

(*) Bitcoin-core, Electrum, C-lightning, Joinmarket

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.