<p>The rule that at least one output is required is part of the original code, and changing it would mean a hard fork. There are <a href="https://en.bitcoin.it/wiki/Hardfork_Wishlist" rel="nofollow">many good changes</a> that are possible with a hard fork, but none of them is considered worth the disruption that a hard fork would create. Changing the rules to permit no-output transactions would not even worth a soft fork, since, just as you said, this can be easily circumvented.</p>

CC BY-SA 3.0
2014-10-01T06:37:16.757Z
2014-10-01T06:37:16.757Z
abacabadabacaba
<p>I was reading this thread about making a transaction without an output:</p>

<p><strong><a href="https://bitcoin.stackexchange.com/questions/12451/are-bitcoin-transactions-permitted-to-have-no-outputs-i-e-all-inputs-become-tr">Are Bitcoin transactions permitted to have no outputs (i.e. all inputs become transaction fee)?</a></strong></p>

<p>The answer is that outputs under a certain value are considered "dust" or "spam".</p>

<p>What is the reasoning behind this? If the input value minus the output value is above the <code>getMinNonDustValue</code> minimum limit, why would the transaction be considered "dust"? The coinbase of the block containing this transaction would simply be allowed to be of higher value, which is how fees usually work.</p>

<p>If my understanding is correct, the network would benefit greatly from a transaction with no outputs. It's fairly easy to circumvent this rule anyway; one could simply add an output that matches <code>getMinNonDustValue</code> and increase the input by that same amount. Allowing a zero output transaction would mean less network load, less data storage requirement, and most importantly less CPU cycles required because the output script is not necessary in this transaction. There is also the added effect of making miners happy by introducing a new rule that allows "donation only" transactions where all Bitcoin go to the miner who solves that block. </p>

<transaction-fees><non-standard-transaction><output><transaction-propagation>
Why are transactions with no outputs not relayed by default?
bvpx
# Why are transactions with no outputs not relayed by default?

(Asked by: username_0 on 2014-01-21)

I was reading this thread about making a transaction without an output:

**[Are Bitcoin transactions permitted to have no outputs (i.e. all inputs become transaction fee)?](https://bitcoin.stackexchange.com/questions/12451/are-bitcoin-transactions-permitted-to-have-no-outputs-i-e-all-inputs-become-tr)**

The answer is that outputs under a certain value are considered "dust" or "spam".

What is the reasoning behind this? If the input value minus the output value is above the `getMinNonDustValue` minimum limit, why would the transaction be considered "dust"? The coinbase of the block containing this transaction would simply be allowed to be of higher value, which is how fees usually work.

If my understanding is correct, the network would benefit greatly from a transaction with no outputs. It's fairly easy to circumvent this rule anyway; one could simply add an output that matches `getMinNonDustValue` and increase the input by that same amount. Allowing a zero output transaction would mean less network load, less data storage requirement, and most importantly less CPU cycles required because the output script is not necessary in this transaction. There is also the added effect of making miners happy by introducing a new rule that allows "donation only" transactions where all Bitcoin go to the miner who solves that block.

**Tags:** transaction-fees, non-standard-transaction, output, transaction-propagation


---

## 1 answers

### Answer by username_1 on 2014-10-01. Score: 4 | Accepted answer

The rule that at least one output is required is part of the original code, and changing it would mean a hard fork. There are [many good changes](https://en.bitcoin.it/wiki/Hardfork_Wishlist) that are possible with a hard fork, but none of them is considered worth the disruption that a hard fork would create. Changing the rules to permit no-output transactions would not even worth a soft fork, since, just as you said, this can be easily circumvented.


---

