Improving UTXO privacy through burning small UTXOs #19166

As is known, maintaining privacy on Bitcoin is an ongoing challenge, and one way this could be improved in the Core wallet is by providing a command that uses a standardized transaction template to burn a UTXO.

While you can manually burn a UTXO today, say by making a single-input transaction that only contains an OP_RETURN, actually creating such an OP_RETURN transaction with the Core wallet is a bit complicated and somewhat risky, as it would only be limited by -maxtxfee. Additionally, fingerprinting of whatever data you put in OP_RETURN as well as the rarity of such transactions hurt privacy as well.

My suggestion would be to add a command with similar arguments to lockunspent, so something like;

burnunspent "[{\"txid\":\"mytxid\",\"vout\":myvout}]"

which would create a single-input transaction of the provided UTXO, with an OP_RETURN with sufficient bytes of random data to make it relayable (preferably indistinguishable from some common hashing algorithm), and return this as a hex-encoded transaction that you would then have to send with sendrawtransaction. This would be safer than broadcasting it directly, and allows you to broadcast the transaction through another channel for additional privacy. You would also want some safeguards against burning a large UTXO, which could be done with a (possibly configurable) burn limit.

In other words, it would be equivalent to createrawtransaction "[{\"txid\":\"mytxid\",\"vout\":myvout}]" "[{\"data\":\"myrandomhexbytes\"}]" + signrawtransactionwithwallet, with some built-in safeguards.

From a blockchain health perspective, an empty OP_RETURN would be preferable, but this violates the tx-size-small limit (see #18296) and cannot be relayed with today's relaying policy. Would it be technically feasible/desirable to exempt such a specific template from this policy without opening up vectors for exploiting the merkle leaf-node weakness?

In my humble opinion, the given case does not justify burning. The whole UTXO amount could be set as the transaction fee. To put it another way, tainted coins would be sacrificed to miners.

The whole UTXO amount could be set as the transaction fee. To put it another way, tainted coins would be sacrificed to miners.

Not sure what you mean? The whole UTXO amount would be set as the transaction fee. That's the point.

Of course, if you controlled the transaction that created the UTXO in the first place, you would just not create the change UTXO at all and "burn" it as transaction fee (unless you screwed up your coin control), but this is not always the case.

@Saicere I would expect that burn command actually destroys coins for the purpose of decreasing supply.

I would expect that burn command actually destroys coins for the purpose of decreasing supply.

Right, I guess you have a point in that semantically it might be inaccurate to use "burn" as in the meaning of "donate to miner fee" as opposed to "make a permanently unspendable UTXO", but my suggestion is based on doing the former rather than the latter. Do you have a suggestion for a better term to use here? "Donate" would arguably be more accurate but might imply that it's being sent to some specific address, which it of course isn't.

Do you have a suggestion for a better term to use here? "Donate" would arguably be more accurate but might imply that it's being sent to some specific address, which it of course isn't.

To name it, I can think of "dispel".

Related - dust-b-gone by @petertodd (requires central server, which isn't running anymore, but tech is still there), is more efficient from block space perspective.

Related - dust-b-gone by @petertodd (requires central server, which isn't running anymore, but tech is still there), is more efficient from block space perspective.

I'm not sure complexity of having a central server or the privacy loss of having several of your dust UTXO combined is worth the minor increase in efficiency, though it would fix the tx-size-small issue. I tested a couple of transactions with empty OP_RETURN (that is, assuming that the template could be exempted for the relaying policy), and the numbers I got from decoderawtransaction was:

1 native segwit UTXO: size=171, vsize=89, weight=354 2 native segwit UTXOs: size=319, vsize=157, weight=625

So each UTXO would add ~148 bytes or ~271 weight, meaning the overhead of burning/donating/whatever the UTXOs individually would be ~23 bytes or ~83 weight per UTXO - unless there's something wrong with my math or TX serialization understanding, of course.

The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Pull requests with improvements are always welcome.