<p>Very interesting brain teaser. I agree that this could be interesting in combination with CPFP. The sender could defer the transaction fees to the recipient which would probably be an interesting proposition for some services in the Bitcoin space.</p>

<p>There are a few problems with negative fees from an operational perspective, though:  </p>

<p>The sender defers prioritization to the recipient. However, if the sender needs to access the funds that are assigned to the change output of the transaction, he'll either have to CPFP the transaction himself after all, or doublespend the transaction to add more outputs.</p>

<p>In the first case, he ends up paying the fees himself, in the second case, he creates a scenario where multiple valid conflicting transactions float about unconfirmed, and since he doesn't know which one will confirm first, he'd better also broadcast all alternative complementary transactions. </p>

<p>I.e.</p>

<pre><code>tx1: S --&gt; R1 + C

tx2: S --&gt; R1 + R2 + (C-R2)  
tx1b: C --&gt; R2 + (C-R2)
</code></pre>

<p>This would quickly increase the amount of transaction combinations that could be accepted on the network, create unnecessary network traffic, and would create a headache for fee estimation: At the same negative feerate, it would be much cheaper for R1 to just purchase tx1, while R2 would have to come up with the fees for tx2 (which is cheaper than tx1+tx1b).</p>

<p>In general, if there are multiple recipients to the transaction, the first to spend from the transaction has to pay for everyone to receive their money.</p>

<p>Another problem is that it may further incentivize out of band payments for transactions which at a larger scale could cause unpredictability in transaction confirmation times, and may skew other incentives in the network.</p>

CC BY-SA 3.0
2017-09-04T16:44:15.317Z
2017-09-04T17:18:11.190Z
2017-09-04T17:18:11.190Z
Murch
<p>A negative fee transaction is a transaction whose outputs' value is larger than its inputs. So that transaction is effectively creating money out of thin air.</p>

<p>The transaction creator is thus getting free money, that's why such transactions are not valid, even if the money created out of thin air would be compensated by a lower block reward for the miner.</p>

CC BY-SA 3.0
2017-09-04T15:48:37.423Z
I know, but that is not important for the consensus rules. If the miner wants to give up the block reward, it is his problem. This rule does not have to be enforced by all nodes. Also child transactions can pay more block reward to compensate the negative fee.
Leonidaz0r
CC BY-SA 3.0
2017-09-04T15:51:14.727Z
I see what you mean, it's possible to keep Bitcoin's supply finite and allow negative fees. But why for? It adds extra complexity since a negative fee transaction can only be validated inside a block. It would also make mining more complex, and what's the incentive for a miner to mine negative fee transactions?
alcio
CC BY-SA 3.0
2017-09-04T16:07:44.047Z
It removes complexity. The script can be validated outside of a block and the check for a correct fee can just be removed. What else can you not validate? The block reward is checked already, so this is just removing a redundant check.
Mining also does not get more complex. Miners already take the transactions paying the largest fees.
A miner would like to mine a negative fee transaction, if a child transaction pays a larger fee, that compensates the loss and can be mined in the same block.
Leonidaz0r
CC BY-SA 3.0
2017-09-04T16:10:24.020Z
Then I can just spam negative fee transactions and actually make money if some miner mine it. That's why individual transactions must pay at least 1 sat/B to be relayed on the network.
alcio
CC BY-SA 3.0
2018-01-27T10:18:28.643Z
The transactions don't have to be relayed. Or they could only be relayed together with a child transaction that compensates the fee with CPFP.
Leonidaz0r
CC BY-SA 3.0
2017-09-04T15:46:29.177Z
2017-09-04T15:46:29.177Z
alcio
<p>Why does Bitcoin consensus require blocks to contain only non negative fee transactions? Also why does the coinbase have to be the first transaction in a block with this rule lifted?</p>

<p>Instead of having those rules, which need to be special cases in the software, I suppose one could just have this rule:</p>

<blockquote>
  <p>The sum of all outputs in a block minus the sum of all input values in the block must not exceed the block reward.</p>
</blockquote>

<p>This rule is already in place to check the block reward, so the other two rules seem useless. A miner which includes a transaction with a negative fee will have to pay for it by the one rule, so nothing bad can happen.</p>

<p>If Bitcoin was using just this one rule I could imagine interesting things could be done with CPFP.</p>

<p>One possible reason I could think of was spam protection, however nothing prevents me from creating a huge amount of spam transactions with 0 or 1 satoshi/B anyway.</p>

CC BY-SA 3.0
2017-10-05T23:12:05.353Z
Wow, a great question
Karel Bílek
<transaction-fees><consensus><child-pays-for-parent>
Why are negative fees not allowed?
Leonidaz0r
# Why are negative fees not allowed?

(Asked by: username_0 on 2017-09-04)

Why does Bitcoin consensus require blocks to contain only non negative fee transactions? Also why does the coinbase have to be the first transaction in a block with this rule lifted?

Instead of having those rules, which need to be special cases in the software, I suppose one could just have this rule:

> The sum of all outputs in a block minus the sum of all input values in the block must not exceed the block reward.

This rule is already in place to check the block reward, so the other two rules seem useless. A miner which includes a transaction with a negative fee will have to pay for it by the one rule, so nothing bad can happen.

If Bitcoin was using just this one rule I could imagine interesting things could be done with CPFP.

One possible reason I could think of was spam protection, however nothing prevents me from creating a huge amount of spam transactions with 0 or 1 satoshi/B anyway.

**Tags:** transaction-fees, consensus, child-pays-for-parent

> **Comments:**
> **username_1**: Wow, a great question  

---

## 2 answers

### Answer by username_2 on 2017-09-04. Score: 3

Very interesting brain teaser. I agree that this could be interesting in combination with CPFP. The sender could defer the transaction fees to the recipient which would probably be an interesting proposition for some services in the Bitcoin space.
There are a few problems with negative fees from an operational perspective, though:  
The sender defers prioritization to the recipient. However, if the sender needs to access the funds that are assigned to the change output of the transaction, he'll either have to CPFP the transaction himself after all, or doublespend the transaction to add more outputs.
In the first case, he ends up paying the fees himself, in the second case, he creates a scenario where multiple valid conflicting transactions float about unconfirmed, and since he doesn't know which one will confirm first, he'd better also broadcast all alternative complementary transactions. 
I.e.
tx1: S --> R1 + C

tx2: S --> R1 + R2 + (C-R2)  
tx1b: C --> R2 + (C-R2)

This would quickly increase the amount of transaction combinations that could be accepted on the network, create unnecessary network traffic, and would create a headache for fee estimation: At the same negative feerate, it would be much cheaper for R1 to just purchase tx1, while R2 would have to come up with the fees for tx2 (which is cheaper than tx1+tx1b).
In general, if there are multiple recipients to the transaction, the first to spend from the transaction has to pay for everyone to receive their money.
Another problem is that it may further incentivize out of band payments for transactions which at a larger scale could cause unpredictability in transaction confirmation times, and may skew other incentives in the network.


---

### Answer by username_3 on 2017-09-04. Score: -1

A negative fee transaction is a transaction whose outputs' value is larger than its inputs. So that transaction is effectively creating money out of thin air.

The transaction creator is thus getting free money, that's why such transactions are not valid, even if the money created out of thin air would be compensated by a lower block reward for the miner.

> **Comments:**
> **username_0**: I know, but that is not important for the consensus rules. If the miner wants to give up the block reward, it is his problem. This rule does not have to be enforced by all nodes. Also child transactions can pay more block reward to compensate the negative fee.  
> **username_3**: I see what you mean, it's possible to keep Bitcoin's supply finite and allow negative fees. But why for? It adds extra complexity since a negative fee transaction can only be validated inside a block. It would also make mining more complex, and what's the incentive for a miner to mine negative fee transactions?  
> **username_0**: It removes complexity. The script can be validated outside of a block and the check for a correct fee can just be removed. What else can you not validate? The block reward is checked already, so this is just removing a redundant check. Mining also does not get more complex. Miners already take the transactions paying the largest fees. A miner would like to mine a negative fee transaction, if a child transaction pays a larger fee, that compensates the loss and can be mined in the same block.  
> **username_3**: Then I can just spam negative fee transactions and actually make money if some miner mine it. That's why individual transactions must pay at least 1 sat/B to be relayed on the network.  
> **username_0**: The transactions don't have to be relayed. Or they could only be relayed together with a child transaction that compensates the fee with CPFP.  

---

