BIP451: Dust UTXO Disposal Protocol

[bubb1es71]

Discussion:

• https://delvingbitcoin.org/t/disposing-of-dust-attack-utxos/2215
• https://groups.google.com/g/bitcoindev/c/pr1z3_j8vTc

co-author: @harismuzaffer

[jonatack]

Looks complete and correct at first glance.

[murchandamus]

Looks pretty good already! Thanks again for working on this so diligently before submitting it here.

[murchandamus]

I had the impression from our discussion on the mailing list that you were considering on always requiring the ash output in order for all transactions to always be aggregatable. Looking at it again, I realize that it was the answer from Steven Slater that made me think so. I assume you considered only standardizing a single output variant, but could you perhaps further explain in the Rationale why you decided to settle on two output variants rather than eating the slightly elevated size for legacy and wrapped segwit transactions in favor of a simpler protocol?

[bubb1es71]

The rationale here is that in most cases there won't be an opportunity to batch, so we should be as efficient as possible for spending the legacy dust who don't get the witness discount. And in practice as legacy usage dies off most dust disposal tx will have witness inputs and need the OP_RETURN "ash" output anyway. I'll add this to the rationale section.

[bubb1es71]

Working on an update to reference code per bubb1es71/ddust#36 and then will update BIP here.

[murchandamus]

My gut feeling is that it is still preferable to only standardize one output variant.
From the sender’s perspective, the transaction will for itself either way. Since the empty OR-output is only feasible for legacy and wrapped segwit inputs, it increases the transaction size by less than 1.8%, but it makes all transactions aggregatable.
It’s just saving 3 bytes, but aggregating a solitary dust input into another transaction saves 21 bytes. So if increased compatibility caused one in seven transactions to be aggregated rather than solitary, it would break even. It would also make it simpler to implement support for this proposal, in particular the aggregation.

[bubb1es71]

I'll think on this a bit more, it would simplify the spec and code.

As mentioned in my other comment our assumption is that batching won't happen too often and eventually be all segwit OR "ash" variety anyway. But OTOH if this spec becomes widely adopted there are plenty of dust UTXOs out there that can/should be disposed of and batching saves more than the extra "ash" bytes.

[murchandamus]

If you are going to retain the two output variants, perhaps it should be best practice that any non-native-segwit input that is added to a dust disposal transaction with an “ash” output is first broadcast as a solitary transaction with an empty OP_RETURN ouput, before the aggregated transaction. This would give the other dust disposer with the ASH output the opportunity to instead add their input to the transaction with the empty OR output.

Still, it seems simpler to only standardize one output variant.

[murchandamus]

Let’s call this BIP 451. Please add the number to the preamble, set the Assigned header to today, rename the BIP file, and add an entry to the README table.

[bubb1es71]

I pushed 54bccb1 with some small edits. I'll squash this and other commits once the review process is done.

[murchandamus]

Yeah, thanks, adding separate commits without squashing them during the review phase is preferred.

[murchandamus]

The Preamble updates and table entry look good. Thanks for the quick turn-around.
Given that you said that you are still mulling over some of the review comments, I’ll leave the “PR Author action required” tag for the time being. Please let me know when you’re ready for another review.

[bubb1es71]

@murchandamus this one is ready for another look. In 686c1b0 I updated it to use only OP_RETURN "ash" and some other small edits.