Hi Defenwycke,
You replied to every line of my email, except the most relevant one.
Murch wrote:
> 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.
Your proposal prescribes an entire new class of transactions that are
managed by separate rules in a separate data structure. You propose to
charge 5 sats per input for those transactions, and prescribe that
miners should include such transactions even when they lose money by
doing so: at elevated feerates. Especially at high feerates, it is
irrational for miners to follow your proposal of selling blockspace
below value.
This idea is made completely obsolete by the recent lowering of the new
minimum feerate. The most common inputs (P2WPKH) only cost <7 sats at
the new minimum feerate, and the ones that make up the biggest portion
of the UTXO set only costs <6 sats at the new minimum feerate. At low
feerates, your proposal provides negligible benefits to senders compared
to the status quo.
Defenwycke wrote:
> Using current standard input sizes (≈68 vB for P2WPKH, ≈57.5 vB for
P2TR keypath, ≈148 vB for P2PKH), the break-even spend cost quickly
rises into the hundreds of sats once fee rates exceed a few sat/vB. At
more common feerates (≈5–10 sat/vB), outputs below roughly 500–1500 sats
are rationally abandoned depending on script type.
The mempool has been routinely clearing down to 0.2 s/vB in the past
months. Inputs spending low amount P2TR UTXOs of “500–1500 sats” cost
0.8–2.4% of their value at such feerates. I don’t see how getting back
~98% of the value translates to “it being rational to abandon such UTXOs”.
This proposal seems rather laborious and complex, and I sincerely cannot
see much benefit. If you want to incentivize people to consolidate their
UTXOs, you have to design something where the incentives work out for
both the producers and the consumers of blockspace. FWIW, it seems to me
that people would already have a financial incentive to do so right now,
so, perhaps you should first try to find out why they don’t already.
Murch
On 2025-12-13 06:56, defenwycke wrote:
Hello Murch,
Thanks for the thoughtful response. Please find my response below.
> 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 BitcoinCore’s dust limit.
I’m not referring to Bitcoin Core’s relay dust limits here. By “dust-
class” I mean outputs that are economically irrational to spend under
typical fee conditions, even though they remain technically valid. Using
current standard input sizes (≈68 vB for P2WPKH, ≈57.5 vB for P2TR
keypath, ≈148 vB for P2PKH), the break-even spend cost quickly rises
into the hundreds of sats once fee rates exceed a few sat/vB. At more
common feerates (≈5–10 sat/vB), outputs below roughly 500–1500 sats are
rationally abandoned depending on script type. So this is an economic
classification, not a relay-policy one.
> You might want to clarify that you mean only P2TR KP inputs. Or would
P2TR SP be permitted?
Yes — only P2TR key-path spends would be permitted. Script-path spends
would be excluded. I’ll make that explicit.
> 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.
Agreed. A physically separate mempool is not required. The intent is
simply that these transactions sit at the very bottom of the normal
mempool’s priority ordering and are treated as lowest priority for
eviction and inclusion
> That said, at 50% full, there are still around ~30 blocks worth of
transactions waiting in the mempool that pay fees, …
Right - and DustSweep is not intended to provide any liveness guarantees
in that situation. These transactions are explicitly opportunistic and
are expected to idle or expire during sustained congestion. That
behaviour is acceptable and consistent with the goal of ensuring they
never compete with fee-paying transactions. The 50% figure was meant as
an illustrative policy threshold, not a claim that blockspace is
otherwise unused.
> …the only ones I have seen lately are miners using a minimum feerate
of 1 s/vB for their block templates.
That aligns with the intent. DustSweep transactions would only ever be
eligible after normal block assembly, and only in templates that already
include all available fee-paying transactions.
> 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.
That’s a fair characterization, and it matches the design goals. To
further limit policy complexity and relay churn, DustSweep transactions
would also be constrained to:
- Confirmed inputs only (no unconfirmed ancestors
- RBF disabled (no replacement or package churn)
- No CPFP assumptions
This keeps them cheap to reason about for node operators, and expiry
without confirmation is an expected outcome rather than a failure mode.
Importantly, these constraints mean DustSweep transactions require no
additional mempool state tracking, package evaluation, or replacement
logic beyond what nodes already implement today.
> 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.
I agree that the incentive is not primarily about recovering value.
Empirically, outputs in this range represent a large number of UTXOs but
very little aggregate bitcoin value. Even aggressive consolidation would
recover well under a single BTC in total. The motivation is instead
about long-term UTXO set hygiene: providing a narrow, predictable
mechanism for compacting outputs that are otherwise rationally
abandoned, without displacing market transactions or altering fee
dynamics. Because the economic value involved is small, the mechanism is
intentionally constrained to avoid creating meaningful incentives for
either users or miners to game block construction or relay policy. The
benefit is therefore not measured in recovered bitcoin value, but in
avoided long-term UTXO growth and reduced steady-state resource costs
for nodes.
Separately (and not a dependency of this proposal), public analysis of
inscription-related activity shows that a significant share of UTXO
growth is tied to metadata-heavy patterns. Future work on segregated
data lanes could allow voluntary compaction of those UTXOs while
preserving metadata, but that’s orthogonal to DustSweep itself.
Kind regards,
Defenwycke
On Friday, December 12, 2025 at 11:19:17 PM UTC Murch wrote:
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 <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 [email protected]
> <mailto:[email protected]>.
> To view this discussion visit https://groups.google.com/d/msgid/
<https://groups.google.com/d/msgid/>
> bitcoindev/b47aa182-bca7-44d7-bed1-
f3cc2df30ef5n%40googlegroups.com <http://40googlegroups.com>
> <https://groups.google.com/d/msgid/bitcoindev/b47aa182-bca7-44d7-
bed1- <https://groups.google.com/d/msgid/bitcoindev/b47aa182-
bca7-44d7-bed1->
> f3cc2df30ef5n%40googlegroups.com?
utm_medium=email&utm_source=footer <http://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 [email protected]
<mailto:[email protected]>.
To view this discussion visit https://groups.google.com/d/msgid/
bitcoindev/841d6882-9853-4d96-84e8-c4742e17e969n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/841d6882-9853-4d96-84e8-
c4742e17e969n%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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/3344ee13-ccd9-4f72-baa8-f420f74199b3%40murch.one.
