<p>One example of an uneconomical (meeting the dust threshold) UTXO are haircomb commitments. While they could've been encoded as OP_RETURNs, it's preferable to bloat the bitcoin UTXO set. Without this, haircomb couldn't benefit from a fast Bitcoin sync technology that could be invented in the future.</p>

CC BY-SA 4.0
2022-07-17T09:49:51.920Z
2022-07-17T09:49:51.920Z
Hugo Franklin
<p>Bitcoin Core <a href="https://bitcoin.stackexchange.com/a/98652/129640">removes</a> provably unspendable outputs from the UTXO set, since by definition we know they will never be used to verify new transactions.</p>
<p>One could, in theory, do the same for UTXOs that are highly unlikely to ever be spent, such as those that are highly <a href="https://bitcoinops.org/en/topics/uneconomical-outputs/" rel="nofollow noreferrer">uneconomical</a> as per your question. However, this introduces a very real risk of splitting yourself off the chain. If just a single one of those UTXOs is spent in a confirmed transaction, your node would reject that block (and any subsequent blocks building on it) since one of its transactions is spending an input that according to your database does not exist.</p>
<p>While it is reasonable to assume that <em>most</em> uneconomical outputs will not be spent (in the current fee environment), it is extremely risky to assume that <em>none</em> of them will be spent. They can be spent accidentally, as part of L2 protocols, or by an attacker that wants to exploit this vulnerability. As such, removing any UTXO that is not provably unspendable would be unwise.</p>

CC BY-SA 4.0
2022-07-15T17:15:53.553Z
Removing a UTXO from your UTXO set, if it still can be spent, however unlikely that is to actually happen, is a hard forking change. It's not something you should do without extremely widespread understanding that the entire ecosystem will do the same.
Pieter Wuille
CC BY-SA 4.0
2022-07-15T17:44:50.820Z
@PieterWuille: Only a hard forking change if you rejected a spend from that UTXO in a mined block right? If you removed it from your UTXO set then it was spent in a block you would request that transaction and the transaction creating that UTXO in the first place from your peers and update your UTXO set accordingly?
Michael Folkson
CC BY-SA 4.0
2022-07-15T17:52:00.490Z
The Bitcoin protocol doesn't work like that. There is no way to synchronize individual transactions or UTXOs. If you delete something from your UTXO set, then by definition you'll reject any block which tries to spend that UTXO. Or you're talking about a wholly different model of what "UTXO set" means.
Pieter Wuille
CC BY-SA 4.0
2022-07-15T20:04:47.547Z
I imagine a wallet could move dust UTXOs into a separate dust UTXO set so that most transactions would verify with only reference to a smaller index for the non-dust UTXO set. Very few  transactions (perhaps almost none ever) would need the dust UTXO set to be examined. Whether this  significantly speeds up processing of incoming blocks might be doubtful.
RedGrittyBrick
CC BY-SA 4.0
2022-07-16T10:14:01.487Z
@PieterWuille Thanks for this clarification I was thinking that it was possible to erase an Output from the UTXO set but still accepting blocks containing those outputs but yeah you cant verify them then.
leslie
CC BY-SA 4.0
2022-07-16T10:14:09.567Z
@RedGrittyBrick I think moving dust UTXO's to an on-disk storage could be an improvement , but I don't have the skills to predict if it's worthwhile or the risks associated with it
leslie
CC BY-SA 4.0
2022-07-16T11:50:59.980Z
@leslie Bitcoin Core keeps the UTXO database on disk, with an in-memory cache for recently-modified entries.
Pieter Wuille
CC BY-SA 4.0
2022-07-16T13:41:41.940Z
@PieterWuille Disallowing spending a spendable UTXO seems to tighten the rules - therefore it seems to be a soft-fork change, or am I missing something?
Chris Chen
CC BY-SA 4.0
2022-07-16T13:56:53.707Z
@ChrisChen You're right.
Pieter Wuille
CC BY-SA 4.0
2022-07-15T16:57:39.230Z
2022-07-15T16:57:39.230Z
stickies-v
<p>Even though it is consensus valid to spend a UTXO of an amount that is lower than the extra fees it would cost to include it in a transaction, most nodes wouldn't relay them because of the <a href="https://bitcoin.stackexchange.com/questions/48235/what-is-the-minrelaytxfee">minRelayTxFee</a>. Does it make sense to keep those outputs in the UTXO set, increasing its size?</p>

<transactions><transaction-fees><utxo><utxo-set><dust>
Does an uneconomical output need to be kept in the UTXO set?
leslie
# Does an uneconomical output need to be kept in the UTXO set?

(Asked by: username_0 on 2022-07-15)

Even though it is consensus valid to spend a UTXO of an amount that is lower than the extra fees it would cost to include it in a transaction, most nodes wouldn't relay them because of the [minRelayTxFee](https://bitcoin.stackexchange.com/questions/48235/what-is-the-minrelaytxfee). Does it make sense to keep those outputs in the UTXO set, increasing its size?

**Tags:** transactions, transaction-fees, utxo, utxo-set, dust


---

## 2 answers

### Answer by username_2 on 2022-07-15. Score: 4 | Accepted answer

Bitcoin Core [removes](https://bitcoin.stackexchange.com/a/98652/129640) provably unspendable outputs from the UTXO set, since by definition we know they will never be used to verify new transactions.

One could, in theory, do the same for UTXOs that are highly unlikely to ever be spent, such as those that are highly [uneconomical](https://bitcoinops.org/en/topics/uneconomical-outputs/) as per your question. However, this introduces a very real risk of splitting yourself off the chain. If just a single one of those UTXOs is spent in a confirmed transaction, your node would reject that block (and any subsequent blocks building on it) since one of its transactions is spending an input that according to your database does not exist.

While it is reasonable to assume that *most* uneconomical outputs will not be spent (in the current fee environment), it is extremely risky to assume that *none* of them will be spent. They can be spent accidentally, as part of L2 protocols, or by an attacker that wants to exploit this vulnerability. As such, removing any UTXO that is not provably unspendable would be unwise.

> **Comments:**
> **username_3**: Removing a UTXO from your UTXO set, if it still can be spent, however unlikely that is to actually happen, is a hard forking change. It's not something you should do without extremely widespread understanding that the entire ecosystem will do the same.  
> **username_4**: @username_3: Only a hard forking change if you rejected a spend from that UTXO in a mined block right? If you removed it from your UTXO set then it was spent in a block you would request that transaction and the transaction creating that UTXO in the first place from your peers and update your UTXO set accordingly?  
> **username_3**: The Bitcoin protocol doesn't work like that. There is no way to synchronize individual transactions or UTXOs. If you delete something from your UTXO set, then by definition you'll reject any block which tries to spend that UTXO. Or you're talking about a wholly different model of what "UTXO set" means.  
> **username_5**: I imagine a wallet could move dust UTXOs into a separate dust UTXO set so that most transactions would verify with only reference to a smaller index for the non-dust UTXO set. Very few  transactions (perhaps almost none ever) would need the dust UTXO set to be examined. Whether this  significantly speeds up processing of incoming blocks might be doubtful.  
> **username_0**: @username_3 Thanks for this clarification I was thinking that it was possible to erase an Output from the UTXO set but still accepting blocks containing those outputs but yeah you cant verify them then.  
> **username_0**: @username_5 I think moving dust UTXO's to an on-disk storage could be an improvement , but I don't have the skills to predict if it's worthwhile or the risks associated with it  
> **username_3**: @username_0 Bitcoin Core keeps the UTXO database on disk, with an in-memory cache for recently-modified entries.  
> **username_6**: @username_3 Disallowing spending a spendable UTXO seems to tighten the rules - therefore it seems to be a soft-fork change, or am I missing something?  
> **username_3**: @username_6 You're right.  

---

### Answer by username_1 on 2022-07-17. Score: -2

One example of an uneconomical (meeting the dust threshold) UTXO are haircomb commitments. While they could've been encoded as OP\_RETURNs, it's preferable to bloat the bitcoin UTXO set. Without this, haircomb couldn't benefit from a fast Bitcoin sync technology that could be invented in the future.


---

