From: Defenwycke <cal.defenwycke@gmail.com>
To: Jonathan Voss <k98kurz@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Draft BIP: DustSweep – policy-only UTXO dust compaction
Date: Fri, 12 Dec 2025 20:17:28 +0000 [thread overview]
Message-ID: <CAOj3_X8GtJtAgcvvPZW2Ovxt31CzGtn9tssqTSZ4BeQ_bL6pxg@mail.gmail.com> (raw)
In-Reply-To: <382cefe0-4ac0-43d7-919b-c56fad0a9b27n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 5466 bytes --]
Hello Jonathan,
Thanks for the thoughtful feedback — that makes sense.
I started with a very narrow definition mostly to make the invariant
obvious and easy to reason about. Every DustSweep tx should monotonically
reduce the UTXO set and never meaningfully compete with the fee market. As
long as that holds, I’m not particularly attached to any one parameter.
I agree that requiring 100% dust inputs and exactly one output is probably
overly strict in practice. A majority dust requirement and an output/input
ratio cap seem like reasonable ways to preserve the incentive (net UTXO
reduction) while making it more usable for real wallets.
My main goal here is to give operators something that’s safe to run and
predictable in behaviour — cheap, bounded, and only active when blockspace
would otherwise go unused. I’m happy to adjust thresholds or relax
constraints as long as those properties remain intact.
Appreciate you taking the time to look at it.
Kind regards,
Defenwycke
On Fri, Dec 12, 2025 at 6:16 PM Jonathan Voss <k98kurz@gmail.com> wrote:
> Interesting proposal. Something like that would be helpful, but perhaps it
> would be more useful if it was not quite so narrowly defined. For example,
> instead of requiring all inputs be dust-class UTXO, it could require a
> minimum of 80% dust-class inputs; instead of exactly one output, it could
> be max_outputs = floor(n_inputs / 5) to keep a maximum output/input ratio
> of 1/5. This could allow for better aggregation of dust outputs into
> economically meaningful, monetary outputs than the narrower definition
> while maintaining the incentives for meaningfully reducing UTXO set size.
>
> I would run this policy on my node. Hashers should ultimately be okay with
> this policy since someone among them also has to run full nodes, and it
> would provide an additional (albeit very small) fee source when block space
> demand is low.
>
> On Thursday, December 11, 2025 at 8:34:16 AM UTC-5 defenwycke wrote:
>
>> Hello list,
>>
>> I’ve been working on a small policy proposal that aims to address one
>> very specific problem: the long-term accumulation of uneconomical dust in
>> the UTXO set.
>>
>> The idea is intentionally narrow. I’m calling it DustSweep, and it
>> defines a strict, non-abusable class of transactions that nodes may relay
>> and miners may include only when the mempool and block space are
>> underutilised. The goal is to give wallets a predictable way to compact
>> dust without introducing new spam vectors or touching consensus.
>>
>> A DustSweep transaction has the following properties:
>>
>> -
>>
>> all inputs are “dust-class” UTXOs
>> -
>>
>> only standard scripts (P2PKH / P2WPKH / P2TR)
>> -
>>
>> exactly one output
>> -
>>
>> no metadata at all (no OP_RETURN, inscriptions, TLVs, etc.)
>> -
>>
>> minimum of 5 inputs (to ensure meaningful UTXO reduction)
>> -
>>
>> size capped
>> -
>>
>> it pays a flat 1 sat per input fee
>>
>> Nodes place these in a small, separate sub-mempool. They’re only accepted
>> when the normal mempool is <50% full, and they’re automatically evicted if
>> normal mempool usage hits 95%. Miners can include them up to a small weight
>> fraction (I suggest ~5%) but only after filling the block with regular
>> fee-paying transactions. The intention is that DustSweep never competes
>> with the fee market and only uses blockspace that would otherwise go unused.
>>
>> This is all policy-level. No consensus changes, no new transaction
>> format, nothing that affects validation. Nodes that don’t implement it
>> simply treat these as low-fee transactions and drop them.
>>
>> The motivation is straightforward: we don’t currently have a safe,
>> structured way to compact dust, and the UTXO set continues to grow from
>> outputs that are effectively unspendable under normal fee conditions.
>> DustSweep tries to offer a predictable, opt-in mechanism for wallets to
>> clean that up without creating any new attack surface.
>>
>> Full draft BIP and supporting documents are here:
>>
>> https://github.com/defenwycke/bip-dust-sweep
>>
>> I’d appreciate feedback on the policy details, thresholds, and whether
>> this fits within what node operators and wallet developers would actually
>> want to use. Happy to adjust parameters if there’s a better balance point.
>>
>> Kind regards,
>>
>> Defenwycke
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/382cefe0-4ac0-43d7-919b-c56fad0a9b27n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/382cefe0-4ac0-43d7-919b-c56fad0a9b27n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOj3_X8GtJtAgcvvPZW2Ovxt31CzGtn9tssqTSZ4BeQ_bL6pxg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6401 bytes --]
next prev parent reply other threads:[~2025-12-12 21:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 12:53 [bitcoindev] " defenwycke
2025-12-12 18:10 ` [bitcoindev] " Jonathan Voss
2025-12-12 20:17 ` Defenwycke [this message]
2025-12-12 22:49 ` [bitcoindev] " Murch
2025-12-13 14:56 ` defenwycke
2025-12-22 19:06 ` Murch
2025-12-22 19:33 ` Defenwycke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOj3_X8GtJtAgcvvPZW2Ovxt31CzGtn9tssqTSZ4BeQ_bL6pxg@mail.gmail.com \
--to=cal.defenwycke@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=k98kurz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox