<p><strong>1. You will never be able to re-mine the previous block and get more fees.</strong></p>
<p>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.</p>
<p>Since <a href="https://bitcoin.org/en/release/v0.11.0#change-log" rel="nofollow noreferrer">Bitcoin Core 0.11.0</a> (July 2015) transactions include a <code>nLockTime</code> to <a href="https://github.com/bitcoin/bitcoin/pull/2340" rel="nofollow noreferrer">discourage fee sniping</a> 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 <a href="https://t.co/1nNe9WnrnE?amp=1" rel="nofollow noreferrer">adoption</a> 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.</p>
<p><strong>2. Mempool will not be shallow enough for consecutive blocks to have significantly different reward.</strong></p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><a href="https://i.sstatic.net/ZACPe.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ZACPe.png" alt="Fees 5/9/2018" /></a>
<a href="https://i.sstatic.net/OY75S.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/OY75S.png" alt="Fees 30/5/2019" /></a>
<a href="https://i.sstatic.net/n03UG.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/n03UG.jpg" alt="Fees 22/12/2017" /></a></p>
<p>Rewards immediately after a block is found are certainly NOT zero, &quot;making it unprofitable for any miner to mine&quot;, as they claim.</p>
<p><strong>3. Miners can always hedge undercutting risk.</strong></p>
<p>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.</p>

CC BY-SA 4.0
2020-05-19T00:13:48.793Z
"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
CC BY-SA 4.0
2020-05-26T23:45:01.867Z
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
CC BY-SA 4.0
2020-05-29T17:38:43.317Z
Thanks for the elaboration!
Murch
CC BY-SA 4.0
2019-04-23T17:32:05.693Z
2022-07-13T20:22:50.710Z
2022-07-13T20:22:50.710Z
Fernando N.
<p>Yes, this is also known as fee sniping.</p>

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

<p>(<strong>*</strong>) <a href="https://github.com/bitcoin/bitcoin/pull/2340" rel="nofollow noreferrer">Bitcoin-core</a>, Electrum, <a href="https://github.com/ElementsProject/lightning/pull/3465" rel="nofollow noreferrer">C-lightning</a>, <a href="https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/492" rel="nofollow noreferrer">Joinmarket</a></p>

CC BY-SA 4.0
2020-05-18T08:03:01.950Z
2020-05-19T00:08:44.857Z
2020-05-19T00:08:44.857Z
Antoine Poinsot
<p>An Undercutting attack as described in <a href="http://randomwalker.info/publications/mining_CCS.pdf" rel="noreferrer">this</a> 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.</p>

<p>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).</p>

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

CC BY-SA 4.0
2019-09-21T21:40:11.507Z
You might find this article informative: https://medium.com/@bergealex4/bitcoin-is-unstable-without-the-block-size-size-limit-70db07070a54
G. Maxwell
<mining-theory>
Can Undercutting attacks be Mitigated?
Matthew Stannard
# Can Undercutting attacks be Mitigated?

(Asked by: username_0 on 2018-01-06)

An Undercutting attack as described in [this](http://randomwalker.info/publications/mining_CCS.pdf) 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?

**Tags:** mining-theory

> **Comments:**
> **username_1**: You might find this article informative: https://medium.com/@bergealex4/bitcoin-is-unstable-without-the-block-size-size-limit-70db07070a54  

---

## 2 answers

### Answer by username_2 on 2019-04-23. Score: 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](https://bitcoin.org/en/release/v0.11.0#change-log) (July 2015) transactions include a `nLockTime` to [discourage fee sniping](https://github.com/bitcoin/bitcoin/pull/2340) 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](https://t.co/1nNe9WnrnE?amp=1) 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](https://i.sstatic.net/ZACPe.png)](https://i.sstatic.net/ZACPe.png)
[![Fees 30/5/2019](https://i.sstatic.net/OY75S.png)](https://i.sstatic.net/OY75S.png)
[![Fees 22/12/2017](https://i.sstatic.net/n03UG.jpg)](https://i.sstatic.net/n03UG.jpg)

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.

> **Comments:**
> **username_3**: "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.  
> **username_3**: 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?  
> **username_3**: Thanks for the elaboration!  

---

### Answer by username_4 on 2020-05-18. Score: 1

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](https://github.com/bitcoin/bitcoin/pull/2340), Electrum, [C-lightning](https://github.com/ElementsProject/lightning/pull/3465), [Joinmarket](https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/492)


---

