<p>Yes, it is possible. The rule regarding the coinbase reward is that a miner cannot take more than the block subsidy plus the transaction fees in the block. This means that a miner can opt to take less than the full reward that they are entitled to. This has happened before in Bitcoin a few times. The coins that they did not collect are gone forever.</p>

<p>So, you can use this rule to your advantage if you want to decrease the block subsidy via a soft fork. In your soft fork, you simply create a new rule which results in the coinbase reward being less than the current coinbase reward (e.g. the block subsidy is smaller). Because of the rule mentioned earlier, non-upgraded nodes will still accept blocks that have these coinbase transactions with a smaller coinbase reward. Thus this is a soft fork because the new rule is backwards compatible.</p>

CC BY-SA 4.0
2018-12-08T18:08:36.627Z
2018-12-08T18:08:36.627Z
Ava Chow
<p>The way block reward is computed today is :</p>

<pre><code>CAmount blockReward = nFees + GetBlockSubsidy(pindex-&gt;nHeight, chainparams.GetConsensus());
</code></pre>

<p>Which means that the block reward is the total fees in the block plus the current base block subsidy.</p>

<p>It's definitely possible to change this line to (pseudocode) :</p>

<pre><code>CAmount blockReward = std::min(nFees + GetBlockSubsidy(pindex-&gt;nHeight, chainparams.GetConsensus()), 25000000);
</code></pre>

<p>This will be a soft fork which doesn't allow the reward to be larger than 0.25 BTC</p>

<p>To explain what I mean in English, the reward is set minimum taken between the current <code>block subsidy + fees</code>, or <code>0.25 BTC</code>.  This is a constraint on the current rules (where the base subsidy is larger than 0.25 BTC), and forward compatible with the period in the future when the base subsidy is lower than 0.25 BTC.</p>

<p>Adding @pieter-wuille's point from the comment, the current rules don't limit a miner in how <em>low</em> they can set their reward to be (where the minimum is zero), only how high.  That means that a miner doesn't have to reward themselves with the maximum allowed reward.  Such occurences have happened on chain before :</p>

<p>Rootstock accidentally set a zero amount as their reward :
<a href="https://www.smartbit.com.au/tx/9bf8853b3a823bbfa1e54017ae11a9e1f4d08a854dcce9f24e08114f2c921182" rel="nofollow noreferrer">https://www.smartbit.com.au/tx/9bf8853b3a823bbfa1e54017ae11a9e1f4d08a854dcce9f24e08114f2c921182</a></p>

<p>The first satoshi taken out of money supply :</p>

<p><a href="https://www.smartbit.com.au/tx/5d80a29be1609db91658b401f85921a86ab4755969729b65257651bb9fd2c10d" rel="nofollow noreferrer">https://www.smartbit.com.au/tx/5d80a29be1609db91658b401f85921a86ab4755969729b65257651bb9fd2c10d</a></p>

CC BY-SA 4.0
2018-12-08T17:53:55.830Z
How is it possible to reduce/change block subsidy without breaking consensus? That seems impossible without a hardfork. Limiting included tx’s may be possible, to limit fees.
James C.
CC BY-SA 4.0
2018-12-08T17:57:05.210Z
The fees, should they push the reward to be higher than 0.25 btc are simply discarded (effectively burned - taken out of circulation entirely).  This is soft fork compatible and already happened on chain.
arubi
CC BY-SA 4.0
2018-12-08T17:57:50.210Z
Got it. Fees yes. Not subsidy.
James C.
CC BY-SA 4.0
2018-12-08T17:58:21.277Z
@James C: the consensus rule is that the coinbase output cannot be **more** than the reward. It has always been allowed to be less (and there are plenty of examples of miners forgetting to claim some fees for example with badly written software).
Pieter Wuille
CC BY-SA 4.0
2018-12-08T18:03:26.103Z
Ah @PieterWuille I did not known it could be less :) Thanks
James C.
CC BY-SA 4.0
2018-12-08T17:49:18.460Z
2018-12-08T18:09:03.890Z
2018-12-08T18:09:03.890Z
arubi
<p>Changing the block subsidy amount and/or schedule is not possible without breaking consensus.</p>

<p>It can be possible to limit tx’s included in a block to limit the fees received by the miner with a soft fork. Empty blocks can still be valid.</p>

CC BY-SA 4.0
2018-12-08T18:01:58.540Z
It's not an arbitrary change. It's reducing the amount of coinbase reward.
My Quid Pro Quo
CC BY-SA 4.0
2018-12-08T18:04:11.423Z
Yup my mistake. I understand now.
James C.
CC BY-SA 4.0
2018-12-08T17:56:55.060Z
2018-12-08T17:56:55.060Z
James C.
<p>Context:</p>

<p>There is a bet going on r/bitcoin about the possibility of doing a user activated soft fork for reducing current miner reward to 0.25 BTC.</p>

<p>One of the users says the bet had two points:</p>

<ol>
<li>the change must be a soft fork (aka it doesn't break consensus)</li>
<li>no miner must be able to claim more than 0.25 btc.</li>
</ol>

<p>Would it be able to make a change to the Bitcoin consensus rules that would meet this criteria?</p>

CC BY-SA 4.0
2018-12-08T17:50:03.577Z
Maybe I'm not sure what "soft fork" means exactly in this context.  But what about a scheme where > 50% of miners agree that they will not mine on top of any block with a reward larger than 0.25 BTC?  Non-mining nodes don't have to upgrade; they might accept blocks with higher rewards from non-conforming miners, but those blocks will eventually be orphaned.  And because of the 100-block maturation time, no transaction that spends a higher reward will ever be valid.
Nate Eldredge
<blockchain-fork><mining-reward><soft-fork>
Would it be possible to create a soft-fork for reducing miner reward?
My Quid Pro Quo
# Would it be possible to create a soft-fork for reducing miner reward?

(Asked by: username_0 on 2018-12-08)

Context:

There is a bet going on r/bitcoin about the possibility of doing a user activated soft fork for reducing current miner reward to 0.25 BTC.

One of the users says the bet had two points:

1. the change must be a soft fork (aka it doesn't break consensus)
2. no miner must be able to claim more than 0.25 btc.

Would it be able to make a change to the Bitcoin consensus rules that would meet this criteria?

**Tags:** blockchain-fork, mining-reward, soft-fork

> **Comments:**
> **username_1**: Maybe I'm not sure what "soft fork" means exactly in this context.  But what about a scheme where > 50% of miners agree that they will not mine on top of any block with a reward larger than 0.25 BTC?  Non-mining nodes don't have to upgrade; they might accept blocks with higher rewards from non-conforming miners, but those blocks will eventually be orphaned.  And because of the 100-block maturation time, no transaction that spends a higher reward will ever be valid.  

---

## 3 answers

### Answer by username_2 on 2018-12-08. Score: 3 | Accepted answer

Yes, it is possible. The rule regarding the coinbase reward is that a miner cannot take more than the block subsidy plus the transaction fees in the block. This means that a miner can opt to take less than the full reward that they are entitled to. This has happened before in Bitcoin a few times. The coins that they did not collect are gone forever.

So, you can use this rule to your advantage if you want to decrease the block subsidy via a soft fork. In your soft fork, you simply create a new rule which results in the coinbase reward being less than the current coinbase reward (e.g. the block subsidy is smaller). Because of the rule mentioned earlier, non-upgraded nodes will still accept blocks that have these coinbase transactions with a smaller coinbase reward. Thus this is a soft fork because the new rule is backwards compatible.


---

### Answer by username_3 on 2018-12-08. Score: 2

The way block reward is computed today is :

```
CAmount blockReward = nFees + GetBlockSubsidy(pindex->nHeight, chainparams.GetConsensus());

```

Which means that the block reward is the total fees in the block plus the current base block subsidy.

It's definitely possible to change this line to (pseudocode) :

```
CAmount blockReward = std::min(nFees + GetBlockSubsidy(pindex->nHeight, chainparams.GetConsensus()), 25000000);

```

This will be a soft fork which doesn't allow the reward to be larger than 0.25 BTC

To explain what I mean in English, the reward is set minimum taken between the current `block subsidy + fees`, or `0.25 BTC`. This is a constraint on the current rules (where the base subsidy is larger than 0.25 BTC), and forward compatible with the period in the future when the base subsidy is lower than 0.25 BTC.

Adding @username_5-username_5's point from the comment, the current rules don't limit a miner in how *low* they can set their reward to be (where the minimum is zero), only how high. That means that a miner doesn't have to reward themselves with the maximum allowed reward. Such occurences have happened on chain before :

Rootstock accidentally set a zero amount as their reward :
<https://www.smartbit.com.au/tx/9bf8853b3a823bbfa1e54017ae11a9e1f4d08a854dcce9f24e08114f2c921182>

The first satoshi taken out of money supply :

<https://www.smartbit.com.au/tx/5d80a29be1609db91658b401f85921a86ab4755969729b65257651bb9fd2c10d>

> **Comments:**
> **username_4**: How is it possible to reduce/change block subsidy without breaking consensus? That seems impossible without a hardfork. Limiting included tx’s may be possible, to limit fees.  
> **username_3**: The fees, should they push the reward to be higher than 0.25 btc are simply discarded (effectively burned - taken out of circulation entirely).  This is soft fork compatible and already happened on chain.  
> **username_4**: Got it. Fees yes. Not subsidy.  
> **username_5**: @username_4 C: the consensus rule is that the coinbase output cannot be **more** than the reward. It has always been allowed to be less (and there are plenty of examples of miners forgetting to claim some fees for example with badly written software).  
> **username_4**: Ah @username_5 I did not known it could be less :) Thanks  

---

### Answer by username_4 on 2018-12-08. Score: 0

Changing the block subsidy amount and/or schedule is not possible without breaking consensus.

It can be possible to limit tx’s included in a block to limit the fees received by the miner with a soft fork. Empty blocks can still be valid.

> **Comments:**
> **username_0**: It's not an arbitrary change. It's reducing the amount of coinbase reward.  
> **username_4**: Yup my mistake. I understand now.  

---

