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?


2 Answers 2


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

The attack described in that paper consists on re-mining a block to claim less fees and incentivize other miners to continue it instead of mining in the honest chain. The threat of the opposite attack was addressed long time ago.

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.

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

As demand of block space increases, or its supply decreases, it becomes more expensive. Bitcoin users will always face a trade-off between waiting a bit longer to get their transactions into blocks (until congestion subsides) and paying higher fees.

We can observe that the more transactions queued in the mempool, the higher is the price of block space and the flatter is the slope of the fee rate distribution. Thus, the lower will be the difference between contiguous block rewards. Abnormally high fees of high priority transactions published between blocks (that heap on the left of the charts) represent a smaller fraction of the total reward when the mempool is busy.

Check the clear cut at 250 sat/WU for most transactions of December 22, 2017. When fees become significantly high, many people show they are not in such a hurry for transaction confirmation after all, and you cannot expect them to be willing to pay much 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 (this can only happen if some transactions pay economically irrational amounts of fees). So, there is no need to alter transaction selection to make this possible, even in unlikely scenarios.

  • "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, 2020 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, 2020 at 23:45
  • Thanks for the elaboration!
    – Murch
    May 29, 2020 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 and acknowledge you have read our privacy policy.

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