<p>As Nick answered quite adequately:</p>

<p>After subsidy has diminished sufficiently as soon as a block is mined that clears out the mempool there will be <em>no</em> income for a miner that mines a successor block, but full income if they successfully remine the prior block. Even once more transactions show up, it will continue to be more profitable to remine the last block for some time especially since they can also take the new transactions that show up.</p>

<p>I wanted to also offer an answer to talk about some of what we've been doing about it.</p>

<p>This issue has been known about in the Bitcoin community for a long time, we've normally discussed it under the name "fee sniping"-- and it was one of the points I raised in my <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html" rel="nofollow noreferrer">first post in the modern blocksize debate</a>.</p>

<p><a href="https://github.com/bitcoin/bitcoin/pull/6216" rel="nofollow noreferrer">Already implemented</a> in Bitcoin Core and some other wallets is a anti-fee-sniping technique where wallets nlocktime their newly created transactions to the current block height. The effect of this is that a sniping miner can take the transactions in the prior block, but not newly arriving ones.  This makes the incentive to go forward build faster. Future enhancements to this move could might be to set the locktime further in the future when the user authors a transaction which has a feerate below the next block worth of transactions, or just don't care about confirmation speed.</p>

<p>The primary response, which is why it came up in a post about the block size, is that the blocksize limit helps tremendously: If there is a consistent backlog there is still a drop of income immediately after a block but it is much less significant.  The paper doesn't really consider this case, basically dismissing it, and noting that fees are not isotropic. They aren't but they don't need to be to substantially diminish instability and even today we find that when the network isn't under-loaded the backlog appears to be enough to produce stability. <a href="https://i.sstatic.net/lnHKy.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/lnHKy.png" alt="Fees in a block template immediately before and immediately after a block was found"></a>
(Red: Block template fees immediately before a block was found, green is immediately after)</p>

<p>Finally, it has been proposed that if/when the network is hardforked the rules be adjusted so that coinbase transactions can spend immature coinbase outputs. Among other things, this would allow miners to pay forward excess fees to encourage other miners to confirm their blocks.  Analysis of the strategies seems to suggest that there is no stable equilibrium when there is no block size limit or back-log,  but it seems likely that there is with a limit (e.g. pay forward the difference between your candidate block and a hypothetical double-size alternative, down scaled by your opponents odds of successfully getting two blocks in a row). But this is an open area for research.</p>

<p>Unfortunately the paper you cite just considers perpetual inflation to be the solution and doesn't consider it too carefully. It even advocates Ethereum which at most has an inflation rate which asymptotically tends to zero (meaning even if inflation rescues them from this issue now, it will eventually do so no longer)-- and thats even if it goes that far: It is my understanding that the Ethereum Foundation has recently stated an intent to lower the inflation rate to combat the price falling.</p>

CC BY-SA 3.0
2017-07-28T05:30:12.613Z
2017-07-29T09:09:22.797Z
2017-07-29T09:09:22.797Z
G. Maxwell
<p>Suppose I see that the Bitcoin network has just created block 100. I can mine on top of that block, as the protocol intends.</p>

<p>Or, I could mine my own block 100 to take the mining reward. If enough miners mine on top of my block, I'll steal the block reward. But if I steal the block reward for block 100, I forgo the opportunity to earn the block reward for block 101.</p>

<p>Now, suppose that I see that the Bitcoin network has just created a block that contains transaction A. I could mine a block with transaction B on top of that block, as the protocol intends. </p>

<p>Or, I could mine my own block that contains both A and B, and get the transaction fee for both. If enough miners mine on top of my block, I'll steal the fee from A and earn the fee from B. I can get both fees at the same time.</p>

CC BY-SA 3.0
2017-07-26T20:34:11.133Z
this is somewhat like the selfish mining but my question is how only transaction reward will cause the instability because after certain time the block reward will be 0 and incentives will only come from transaction fee.?
Laxmi Kadariya
CC BY-SA 3.0
2017-07-27T02:40:57.127Z
@LaxmiKadariya Selfish mining is something else. Selfish mining is delaying publishing a block if that would benefit you.
Nick ODell
CC BY-SA 3.0
2017-07-27T17:22:38.590Z
then why the above answer not occur when there is block fee as well? and occurs only with transaction fee only?
Laxmi Kadariya
CC BY-SA 3.0
2017-07-27T17:26:27.720Z
@LaxmiKadariya You cannot mine a block that claims the reward for block 100 and the reward for block 101 at the same time. It is not possible. However, you can mine a block that claims the transaction fees of transaction A and transaction B at the same time.
Nick ODell
CC BY-SA 3.0
2017-07-27T19:35:57.097Z
so this means in case of block reward, if I neglect the network block and mine my own block, there is less probablity of winning next block as other node may solve the block and requires time of 10 min for another block creation . However in only transaction I can add any number of transaction in a block of my own neglecting network block and  can get all the transaction reward  at the same time  and the reward is equal no matter if I mine two blocks or a single block with both transaction without loss of 10min.
Laxmi Kadariya
CC BY-SA 3.0
2017-07-26T19:22:13.500Z
2017-07-26T19:22:13.500Z
Nick ODell
<p>I came across the paper <a href="https://www.cs.princeton.edu/~smattw/CKWN-CCS16.pdf" rel="nofollow noreferrer">On the Instability of Bitcoin Without the Block Reward</a> where it says that in the near future where the incentives are only due to the transactions, instability issues will appear.  With only transaction fees, the variance of the miner reward is very high due to the randomness of the block arrival time, and it becomes attractive to fork a “wealthy” block to “steal” the rewards therein. </p>

<p>I tried to read the paper, however I could not understand the exact reason for the instability. So, what is the simple idea that rewards only composed from transaction fees will result in instability that does not appear while there still is a block subsidy?</p>

<mining-reward><consensus><blockspace-market>
How do transaction fees exacerbate instability in Bitcoin in the future?
Laxmi Kadariya
# How do transaction fees exacerbate instability in Bitcoin in the future?

(Asked by: username_0 on 2017-07-26)

I came across the paper [On the Instability of Bitcoin Without the Block Reward](https://www.cs.princeton.edu/~smattw/CKWN-CCS16.pdf) where it says that in the near future where the incentives are only due to the transactions, instability issues will appear. With only transaction fees, the variance of the miner reward is very high due to the randomness of the block arrival time, and it becomes attractive to fork a “wealthy” block to “steal” the rewards therein.

I tried to read the paper, however I could not understand the exact reason for the instability. So, what is the simple idea that rewards only composed from transaction fees will result in instability that does not appear while there still is a block subsidy?

**Tags:** mining-reward, consensus, blockspace-market


---

## 2 answers

### Answer by username_1 on 2017-07-28. Score: 5

As username_2 answered quite adequately:

After subsidy has diminished sufficiently as soon as a block is mined that clears out the mempool there will be *no* income for a miner that mines a successor block, but full income if they successfully remine the prior block. Even once more transactions show up, it will continue to be more profitable to remine the last block for some time especially since they can also take the new transactions that show up.

I wanted to also offer an answer to talk about some of what we've been doing about it.

This issue has been known about in the Bitcoin community for a long time, we've normally discussed it under the name "fee sniping"-- and it was one of the points I raised in my [first post in the modern blocksize debate](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/007880.html).

[Already implemented](https://github.com/bitcoin/bitcoin/pull/6216) in Bitcoin Core and some other wallets is a anti-fee-sniping technique where wallets nlocktime their newly created transactions to the current block height. The effect of this is that a sniping miner can take the transactions in the prior block, but not newly arriving ones. This makes the incentive to go forward build faster. Future enhancements to this move could might be to set the locktime further in the future when the user authors a transaction which has a feerate below the next block worth of transactions, or just don't care about confirmation speed.

The primary response, which is why it came up in a post about the block size, is that the blocksize limit helps tremendously: If there is a consistent backlog there is still a drop of income immediately after a block but it is much less significant. The paper doesn't really consider this case, basically dismissing it, and noting that fees are not isotropic. They aren't but they don't need to be to substantially diminish instability and even today we find that when the network isn't under-loaded the backlog appears to be enough to produce stability. [![Fees in a block template immediately before and immediately after a block was found](https://i.sstatic.net/lnHKy.png)](https://i.sstatic.net/lnHKy.png)
(Red: Block template fees immediately before a block was found, green is immediately after)

Finally, it has been proposed that if/when the network is hardforked the rules be adjusted so that coinbase transactions can spend immature coinbase outputs. Among other things, this would allow miners to pay forward excess fees to encourage other miners to confirm their blocks. Analysis of the strategies seems to suggest that there is no stable equilibrium when there is no block size limit or back-log, but it seems likely that there is with a limit (e.g. pay forward the difference between your candidate block and a hypothetical double-size alternative, down scaled by your opponents odds of successfully getting two blocks in a row). But this is an open area for research.

Unfortunately the paper you cite just considers perpetual inflation to be the solution and doesn't consider it too carefully. It even advocates Ethereum which at most has an inflation rate which asymptotically tends to zero (meaning even if inflation rescues them from this issue now, it will eventually do so no longer)-- and thats even if it goes that far: It is my understanding that the Ethereum Foundation has recently stated an intent to lower the inflation rate to combat the price falling.


---

### Answer by username_2 on 2017-07-26. Score: 2

Suppose I see that the Bitcoin network has just created block 100. I can mine on top of that block, as the protocol intends.

Or, I could mine my own block 100 to take the mining reward. If enough miners mine on top of my block, I'll steal the block reward. But if I steal the block reward for block 100, I forgo the opportunity to earn the block reward for block 101.

Now, suppose that I see that the Bitcoin network has just created a block that contains transaction A. I could mine a block with transaction B on top of that block, as the protocol intends.

Or, I could mine my own block that contains both A and B, and get the transaction fee for both. If enough miners mine on top of my block, I'll steal the fee from A and earn the fee from B. I can get both fees at the same time.

> **Comments:**
> **username_0**: this is somewhat like the selfish mining but my question is how only transaction reward will cause the instability because after certain time the block reward will be 0 and incentives will only come from transaction fee.?  
> **username_2**: @username_0 Selfish mining is something else. Selfish mining is delaying publishing a block if that would benefit you.  
> **username_0**: then why the above answer not occur when there is block fee as well? and occurs only with transaction fee only?  
> **username_2**: @username_0 You cannot mine a block that claims the reward for block 100 and the reward for block 101 at the same time. It is not possible. However, you can mine a block that claims the transaction fees of transaction A and transaction B at the same time.  
> **username_0**: so this means in case of block reward, if I neglect the network block and mine my own block, there is less probablity of winning next block as other node may solve the block and requires time of 10 min for another block creation . However in only transaction I can add any number of transaction in a block of my own neglecting network block and  can get all the transaction reward  at the same time  and the reward is equal no matter if I mine two blocks or a single block with both transaction without loss of 10min.  

---

