* [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction @ 2025-12-11 12:53 defenwycke 2025-12-12 18:10 ` [bitcoindev] " Jonathan Voss 2025-12-12 22:49 ` [bitcoindev] " Murch 0 siblings, 2 replies; 7+ messages in thread From: defenwycke @ 2025-12-11 12:53 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2740 bytes --] 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/b47aa182-bca7-44d7-bed1-f3cc2df30ef5n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 3129 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* [bitcoindev] Re: Draft BIP: DustSweep – policy-only UTXO dust compaction 2025-12-11 12:53 [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction defenwycke @ 2025-12-12 18:10 ` Jonathan Voss 2025-12-12 20:17 ` Defenwycke 2025-12-12 22:49 ` [bitcoindev] " Murch 1 sibling, 1 reply; 7+ messages in thread From: Jonathan Voss @ 2025-12-12 18:10 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3781 bytes --] 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. [-- Attachment #1.2: Type: text/html, Size: 4272 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Re: Draft BIP: DustSweep – policy-only UTXO dust compaction 2025-12-12 18:10 ` [bitcoindev] " Jonathan Voss @ 2025-12-12 20:17 ` Defenwycke 0 siblings, 0 replies; 7+ messages in thread From: Defenwycke @ 2025-12-12 20:17 UTC (permalink / raw) To: Jonathan Voss; +Cc: Bitcoin Development Mailing List [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction 2025-12-11 12:53 [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction defenwycke 2025-12-12 18:10 ` [bitcoindev] " Jonathan Voss @ 2025-12-12 22:49 ` Murch 2025-12-13 14:56 ` defenwycke 1 sibling, 1 reply; 7+ messages in thread From: Murch @ 2025-12-12 22:49 UTC (permalink / raw) To: bitcoindev [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction 2025-12-12 22:49 ` [bitcoindev] " Murch @ 2025-12-13 14:56 ` defenwycke 2025-12-22 19:06 ` Murch 0 siblings, 1 reply; 7+ messages in thread From: defenwycke @ 2025-12-13 14:56 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 11112 bytes --] 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 > > > > 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+...@googlegroups.com > > <mailto:bitcoindev+...@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/841d6882-9853-4d96-84e8-c4742e17e969n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 13726 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction 2025-12-13 14:56 ` defenwycke @ 2025-12-22 19:06 ` Murch 2025-12-22 19:33 ` Defenwycke 0 siblings, 1 reply; 7+ messages in thread From: Murch @ 2025-12-22 19:06 UTC (permalink / raw) To: defenwycke, Bitcoin Development Mailing List 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 bitcoindev+...@googlegroups.com > > <mailto:bitcoindev+...@googlegroups.com>. > > 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 bitcoindev+unsubscribe@googlegroups.com > <mailto:bitcoindev+unsubscribe@googlegroups.com>. > 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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/3344ee13-ccd9-4f72-baa8-f420f74199b3%40murch.one. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction 2025-12-22 19:06 ` Murch @ 2025-12-22 19:33 ` Defenwycke 0 siblings, 0 replies; 7+ messages in thread From: Defenwycke @ 2025-12-22 19:33 UTC (permalink / raw) To: Murch; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 16817 bytes --] Hello Murch. Thanks for taking the time to follow up and for spelling out the incentive concerns so clearly. You’re right - the recent reduction of the default minimum relay feerate to 0.1 sat/vB materially changes the economic backdrop I was assuming. Under those conditions, most consolidation is already cheap enough that a protocol- or policy-level mechanism no longer makes sense, and the remaining friction is better addressed at the wallet/UX layer rather than through miner or relay rules. I agree with your point that Bitcoin policy should not rely on miners selling blockspace below market value, and that any mechanism that only encourages behavior without enforceable constraints is unlikely to be justified. I’m going to step back from this direction and reconsider the problem in a different scope. I appreciate the careful read and the candid feedback. it was helpful in clarifying where the real boundary lies. Kind regards Defenwycke On Mon, 22 Dec 2025 at 19:06, Murch <murch@murch.one> wrote: > 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 bitcoindev+...@googlegroups.com > > > <mailto:bitcoindev+...@googlegroups.com>. > > > 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 bitcoindev+unsubscribe@googlegroups.com > > <mailto:bitcoindev+unsubscribe@googlegroups.com>. > > 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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOj3_X8cJLJChvv3-QSGA8j5MVwgYxn1BAUeugTTgiqUWzEK_Q%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 25894 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-12-22 19:48 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-12-11 12:53 [bitcoindev] Draft BIP: DustSweep – policy-only UTXO dust compaction defenwycke 2025-12-12 18:10 ` [bitcoindev] " Jonathan Voss 2025-12-12 20:17 ` Defenwycke 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox