UTXO reduction by trx-to-self?

[Wintermute]

Would it be possible to reduce the number of UTXO by making a transaction to self?

For example, if there are 30 payments to the same address A, this means there are 30 UTXO (assuming nothing was spent so far). If a transaction from A to A would be made (spending all BTC and sending all back to A), would this reduce the number of UTXO?

If this is the case wouldn't it be make sense to allow (as an exception) these kind of transactions to be done by anyone (i.e. *without* signing) in order to reduce the number of UTXO, provided that:

(1) the amount is send from A to A
(2) no fees applied
(3) no other trx uses the respective UTXO
(4) number of UTXO is reduced

Sorry, if I completely miss how UTXO work, I am still learning.

[1715421825]

1715421825

[1715421825]

1715421825

[TierNolan]

That would be a hard fork.  Miners could create those transactions to compact the UTXO set.

One of the suggestions for reducing the UTXO set is to put a cost on holding lots of UTXOs.  If there was a limit on the total number of UTXOs (like with the blocksize), then transactions which reduce the UTXO could be free.

A miner might be allowed to add 1000 UTXOs to the output set per block.  If he has already reached his limit, he could include a transaction which spends 10 UTXOs to a single address and then include 9 transactions which increase the UTXO set by 1 each.  The 9 transactions would be fee paying, but unless he includes the first transaction, he can't include them, so he may include it for free (or lower fee).

[cheako]

One of the suggestions for reducing the UTXO set is to put a cost on holding lots of UTXOs.  If there was a limit on the total number of UTXOs (like with the blocksize), then transactions which reduce the UTXO could be free.

A miner might be allowed to add 1000 UTXOs to the output set per block.  If he has already reached his limit, he could include a transaction which spends 10 UTXOs to a single address and then include 9 transactions which increase the UTXO set by 1 each.  The 9 transactions would be fee paying, but unless he includes the first transaction, he can't include them, so he may include it for free (or lower fee).

How are DoS attacks prevented?  Say the network is flooded with these output creating tx.

If I'm not mistaken you'r not a UTXO until after some time you remain unspent.  We already have the more confirmed tx as input is priority and can even be sent with zero fee, so I don't see the advantage here.

One issue with UTXO is old transactions never being spent and thus not prune-able on partial-nodes.  Though this form of check-pointing adds to the overall blockchain size and this doesn't help at all on a full-node.

What are the other issues output script combining with transaction to self meant to solve?  They add more issues with wallets not knowing the txids of the spendable outputs.

[TierNolan]

How are DoS attacks prevented?  Say the network is flooded with these output creating tx.

A transaction which has 10 inputs and 1 outputs counts as -9 UTXOs.  There is not a DOS attack.  In fact, it it is the opposite, it reduces database size for everyone.  Once the transaction is accepted, 10 entries can be deleted from the database, and one entry is inserted.

The suggestion on the mailing list was that removing UTXOs wouldn't quite balance out inserting new ones.  UTXO_change = (input_count - 0.75 * output_count) * UTXO_size_equivalent.  This still encourages removing UTXOs.

UTXO_size_equivalent was 4 bytes.  This means that removing UTXOs made the transaction appear to be slightly smaller.

If I'm not mistaken you'r not a UTXO until after some time you remain unspent.

No UTXOs are added immediately to the database.  Coinbase transactions are not spendable for 100 blocks, but they are still added to the database.

[johoe]

Besides being a hard fork, there are some undesired effects.

• similar to malleability it changes the transaction ids of your valid inputs
• it may invalidate your partially signed transaction that you got from a third party on a common multisig address
• it may make your bitcoins lower priority, since their age is diminished

[sangaman]

Besides being a hard fork, there are some undesired effects.

• similar to malleability it changes the transaction ids of your valid inputs
• it may invalidate your partially signed transaction that you got from a third party on a common multisig address
• it may make your bitcoins lower priority, since their age is diminished

How could the first point be practically exploited? I'm failing to see any issue with inputs being changed. If you're expecting a payment with a certain txid, that txid will still exist even if it is later combined with other utxos right?

I'm not familiar enough with how the second point might pose an issue, do you have an example?

For the third point, this is a valid concern and maybe the priority/age formula would have to be modified not to penalize consolidating utxo's.

[kevinchia0907]

Besides being a hard fork, there are some undesired effects.

• similar to malleability it changes the transaction ids of your valid inputs
• it may invalidate your partially signed transaction that you got from a third party on a common multisig address
• it may make your bitcoins lower priority, since their age is diminished

How could the first point be practically exploited? I'm failing to see any issue with inputs being changed. If you're expecting a payment with a certain txid, that txid will still exist even if it is later combined with other utxos right?

I'm not familiar enough with how the second point might pose an issue, do you have an example?

For the third point, this is a valid concern and maybe the priority/age formula would have to be modified not to penalize consolidating utxo's.

Just reply to the third point, if we use the method to eliminate UTXOs from UTXO database, works have to be done to evaluate the priority of UTXOs will be expensive(Rather than from UTXO database, we have to dig out previous UTXOs from blockchain)

[wumpus]

Would it be possible to reduce the number of UTXO by making a transaction to self?

For example, if there are 30 payments to the same address A, this means there are 30 UTXO (assuming nothing was spent so far). If a transaction from A to A would be made (spending all BTC and sending all back to A), would this reduce the number of UTXO?

Absolutely. You can send transactions to yourself to consolidate the UTXO set. As an added bonus, this will reduce the number of unspent outputs in your wallet, thus simplify (and speed up) output selection on spend. It can also reduce the size of created transactions, thus reduce the total amount of fees paid.

There is a slight disadvantage to privacy as you'd be linking together outputs that might have stayed unlinked. But it could be done strategically for outputs that are known to be linked already (e.g. those zillions of small payouts).

If this is the case wouldn't it be make sense to allow (as an exception) these kind of transactions to be done by anyone (i.e. *without* signing) in order to reduce the number of UTXO, provided that:

This is not possible. Other nodes and miners do not (and should not!) know what UTXOs belong together. That would be a privacy breach. Also they cannot generate a new address for you to send it to.

This kind of consolidation is the responsibility of the wallet software, directed by the user.

[johoe]

• similar to malleability it changes the transaction ids of your valid inputs
• it may invalidate your partially signed transaction that you got from a third party on a common multisig address
• it may make your bitcoins lower priority, since their age is diminished

How could the first point be practically exploited? I'm failing to see any issue with inputs being changed. If you're expecting a payment with a certain txid, that txid will still exist even if it is later combined with other utxos right?

You buy a coffee at your local shop.  At the same time you send the transaction, someone combines your UTXOs with another transaction that uses the same input.   Only one of the two transactions wins.  So you may accidentally double spend on your coffee and do not even know it.

I'm not familiar enough with how the second point might pose an issue, do you have an example?

GreenAddress would be an example.  They have a service to keep your bitcoins safe against someone stealing your private key by requiring that every transaction is additionally signed by them after you logged in with a second factor.  They also give you a pre-signed time-locked transaction that gives you access to your bitcoins after a few weeks/months without their intervention in case they go out of service or lose their private keys.  However if someone in the mean time compresses your UTXOs this transaction would no longer be valid.

Other scenarios are payment channels where you also get a time-locked transaction to reclaim your coins if the server crashes.

[Sukrim]

If this is the case wouldn't it be make sense to allow (as an exception) these kind of transactions to be done by anyone (i.e. *without* signing) in order to reduce the number of UTXO, provided that:

This is not possible. Other nodes and miners do not (and should not!) know what UTXOs belong together. That would be a privacy breach. Also they cannot generate a new address for you to send it to.

The trivial case would be to combine UTXOs whose output scripts are 100% identical. These are all spendable by the same entity and this is publicly known information. This would even increase privacy in some cases, as fewer outputs available might leak less information about output selection algorithms by wallet software.

The Output scripts would remain untouched, it's more of a deduplication effort... a hardfork would make transactions legal that refer to identical UTXOs and combine them to a new UTXO that has the same script, but a combined value (no fee charged of course) of all inputs.

[achow101_alt]

How are DoS attacks prevented?  Say the network is flooded with these output creating tx.

There wouldn't be any DOS attacks from spamming the network. Once one transaction is created to consolidate the UTXO's and that transaction was considered valid, any other transaction spending the same inputs to consolidate would be invalidated and treated as a double spend. These would then be removed from the network. Also, any node spamming the network with these transactions within a very short amount of time would receive a banscore from its peers and thus be disconnected from the network for some amount of time.

[sangaman]

• similar to malleability it changes the transaction ids of your valid inputs
• it may invalidate your partially signed transaction that you got from a third party on a common multisig address
• it may make your bitcoins lower priority, since their age is diminished

How could the first point be practically exploited? I'm failing to see any issue with inputs being changed. If you're expecting a payment with a certain txid, that txid will still exist even if it is later combined with other utxos right?

You buy a coffee at your local shop.  At the same time you send the transaction, someone combines your UTXOs with another transaction that uses the same input.   Only one of the two transactions wins.  So you may accidentally double spend on your coffee and do not even know it.

I'm not familiar enough with how the second point might pose an issue, do you have an example?

GreenAddress would be an example.  They have a service to keep your bitcoins safe against someone stealing your private key by requiring that every transaction is additionally signed by them after you logged in with a second factor.  They also give you a pre-signed time-locked transaction that gives you access to your bitcoins after a few weeks/months without their intervention in case they go out of service or lose their private keys.  However if someone in the mean time compresses your UTXOs this transaction would no longer be valid.

Other scenarios are payment channels where you also get a time-locked transaction to reclaim your coins if the server crashes.

Thanks that makes a lot of sense now. Not sure how to work around those problems. I do hope we come up with some new ways to reduce the UTXO set in the near future, though.