From: Murch <murch@murch.one>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction
Date: Fri, 12 Dec 2025 14:49:42 -0800 [thread overview]
Message-ID: <02d7368e-95d3-4185-b70f-3aa9b5df1e1d@murch.one> (raw)
In-Reply-To: <b47aa182-bca7-44d7-bed1-f3cc2df30ef5n@googlegroups.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 5847 bytes --]
Hey Defenwycke,
> all inputs are “dust-class” UTXOs
What does “dust-class” mean? Are you using the Bitcoin Core dust limit
or talking about small amounts in general? I don’t have figures off the
top of my head, but I would assume that there are relatively few UTXOs
smaller than Bitcoin Core’s dust limit.
> only standard scripts (P2PKH / P2WPKH / P2TR)
You might want to clarify that you mean only P2TR KP inputs. Or would
P2TR SP be permitted?
> 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%.
It would be a lot of work to have a separate pool for this, and I don’t
see a reason why they couldn’t just go in the regular mempool. If the
mempool fills up, they’d have the lowest feerates and they’d get kicked
out first anyway. That said, at 50% full, there are still around ~30
blocks worth of transactions waiting in the mempool that pay fees, …
> Miners can include them up to a small weight fraction (I suggest ~5%)
but only after filling the block with regular fee-paying transactions.
… so if they are only considered in blocks that aren’t full, the only
ones I have seen lately are miners using a minimum feerate of 1 s/vB for
their block templates. Looking at some popular mempool statistic sites,
in the past 32 months, there would have only been organically non-full
blocks between April and August this year.
I assume the intention is to only relay these transactions when there
are blocks that aren’t full, to limit the bandwidth-wasting vector this
feature introduces, but overall it seems to me that it would be most
likely for such transactions to sit in nodes’ memory until they expire.
All that said, at the new minimum feerate of 0.1 s/vB, a 148 vB P2PKH
input costs 15 sats, a 68 vB P2WPKH input costs 7 sats, and a 57.5 vB
P2TR input costs 6 sats. It doesn’t seem obvious to me that saving a few
dozen sats would greatly foster the users’ urge to consolidate. It feels
like a lot of overhead for such a small incentive to the users, and
relying on the miners to give away blockspace below market value feels a
bit optimistic as well.
Cheers,
Murch
On 2025-12-11 04:53, 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
> <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> bitcoindev/b47aa182-bca7-44d7-bed1-f3cc2df30ef5n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/b47aa182-bca7-44d7-bed1-
> f3cc2df30ef5n%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/02d7368e-95d3-4185-b70f-3aa9b5df1e1d%40murch.one.
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 17583 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-12-12 23:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 12:53 defenwycke
2025-12-12 18:10 ` [bitcoindev] " Jonathan Voss
2025-12-12 20:17 ` Defenwycke
2025-12-12 22:49 ` Murch [this message]
2025-12-13 14:56 ` [bitcoindev] " 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=02d7368e-95d3-4185-b70f-3aa9b5df1e1d@murch.one \
--to=murch@murch.one \
--cc=bitcoindev@googlegroups.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