From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 18 Dec 2025 17:49:51 -0800 Received: from mail-qk1-f191.google.com ([209.85.222.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vWPcs-0008Cb-Be for bitcoindev@gnusha.org; Thu, 18 Dec 2025 17:49:51 -0800 Received: by mail-qk1-f191.google.com with SMTP id af79cd13be357-8b2f0be2cf0sf441287985a.0 for ; Thu, 18 Dec 2025 17:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1766108984; x=1766713784; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=pD79Rv6kYcfi8M6+q7AnFMeE1PvTfwI9Bckpl26FRS4=; b=vA1FHFfySil6lONiRsDx2USOH+2zu7OMU6cTB2gIAaz52dRuLs7WIEz9kZq2T5hbgF tq8e8tHDaEz4wBakvFDRSNSEKRu1/sxLQCuIWKlMmGncPdJsrCFwwXjMU/lYfPPES+w1 OR+1bXOCMX4zYpItXu2RsJ2T+FvhcKrPYEf13p7CKlECjU8TDtXxsjlbQQHClu2lGy7S XVjkJ6FV+94SMABskXtc0bS7QpR6IoWC8LBlcUDXzwyXYWugJVp8LyqIzResfXPCazm9 3xhLQlzxZGA9J5hGDvR6ogmXcjEYF2A0g3AllBWBIfHaQNvTW5dGTdqHzKVAUgNUnw3I vesA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766108984; x=1766713784; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=pD79Rv6kYcfi8M6+q7AnFMeE1PvTfwI9Bckpl26FRS4=; b=fpf1MWu81QJd3JrJgoJp6qRFhGnCq7QyBoToMaAkITspa46E84zljNqgnSmktVqe9x vNaDQwzli0MsCl1rY8xRc5ST8PSwqT+k70NvRdCRBy+NOdz6Xl5FDJzkipTqY54jwGNg PpPSxdwPOjnw/K+Q5ChG9z5JZT3n3KrSNMHwoL66jtF7ziso7kbTQ/WoD7IlTj+8GWpG 7bRkoFr/TeJQaBeBmilcmAVm/qotqtvwyL2AfOrcvMLczP8XvdT8rnEk4nsp0O81G5AA EO0KLhiKlkRxYChZyCVLiSjw4YF6I3f1p3kzf58TpxnS1lqK3TcJotmrNmzB+bn7RbFv tbIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766108984; x=1766713784; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=pD79Rv6kYcfi8M6+q7AnFMeE1PvTfwI9Bckpl26FRS4=; b=NoQKyZ7yavbs4gA8jk+7U7sUhj7zEWhG51bl1gBa9DnwjH0Yv8Bbvb9RTiVIOB2NS/ GyZNtvyLFvbmXzknczBNqhUe3CZJgswHtuUtEwAPcBBMgOlnS95Tc5Z0m9t4ucUK+FZ1 KzJWHI14oEmJNg8L44pRFPEQVr1IXMAgnEpvWAuvCKVcGHEjrOtlLYWxF8zS/5WnS98i uPa8b6lxliw0ycEAsSximi2MrUVB4GKc4z8CjimWTEFQBYxvnA7K+5u20Ru83egxEivb YqWnyC5xUvuNtomylyPBrQYYSXtJ2+uFx0VGNoUu4K9bTH/bMLv5sD1djYVatxtQ9zNR ZX0A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWWN1nWoPNkUtV/kthhrG/tlz1ip2SqWg31G3kr9BNsi2KRrHZbr4BD905jbINZV6wIU8TUI5B7Z8+o@gnusha.org X-Gm-Message-State: AOJu0YyKCJQSWgFmgytZ/0IcWkFl7DzxGZWhMHzA8E8zBGMLC5JLL2Cg zGZYijDhx9CxkUZb1qOnO4Jff4YKBb8DepWtvmFTtG8noNcf2qKu8FoI X-Google-Smtp-Source: AGHT+IHzMGqLdY0Go0tj9ekLdTWtpREFTKNZ1t9ZRzLG8fnQDj3F3V4cRJA8SGZnoku+z9xHjhyBTw== X-Received: by 2002:a05:620a:710c:b0:8b2:e87e:1093 with SMTP id af79cd13be357-8c08fa9c378mr264634285a.3.1766108983367; Thu, 18 Dec 2025 17:49:43 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYIeM9AO44itYuYWb2OqXt+PpJCOVEnTQvUTgxJwe1ACA==" Received: by 2002:a0c:d806:0:b0:88a:577b:fa53 with SMTP id 6a1803df08f44-88a577bfc16ls34171136d6.2.-pod-prod-02-us; Thu, 18 Dec 2025 17:49:36 -0800 (PST) X-Received: by 2002:a05:620a:298a:b0:893:b99:711a with SMTP id af79cd13be357-8c08f6668a9mr266840185a.19.1766108976833; Thu, 18 Dec 2025 17:49:36 -0800 (PST) Received: by 2002:a05:690c:48c1:b0:786:6c46:840 with SMTP id 00721157ae682-78e642e9732ms7b3; Sat, 13 Dec 2025 06:56:33 -0800 (PST) X-Received: by 2002:a05:690e:12cf:b0:642:f9a9:74eb with SMTP id 956f58d0204a3-64555663516mr3849414d50.71.1765637792269; Sat, 13 Dec 2025 06:56:32 -0800 (PST) Date: Sat, 13 Dec 2025 06:56:31 -0800 (PST) From: defenwycke To: Bitcoin Development Mailing List Message-Id: <841d6882-9853-4d96-84e8-c4742e17e969n@googlegroups.com> In-Reply-To: <02d7368e-95d3-4185-b70f-3aa9b5df1e1d@murch.one> References: <02d7368e-95d3-4185-b70f-3aa9b5df1e1d@murch.one> Subject: =?UTF-8?Q?Re=3A_=5Bbitcoindev=5D_Draft_BIP=3A_DustSweep_=E2=80=93_policy=2Donl?= =?UTF-8?Q?y_UTXO_dust_compaction?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_321110_930870268.1765637791925" X-Original-Sender: cal.defenwycke@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_321110_930870268.1765637791925 Content-Type: multipart/alternative; boundary="----=_Part_321111_1818376120.1765637791925" ------=_Part_321111_1818376120.1765637791925 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Murch, Thanks for the thoughtful response. Please find my response below. > What does =E2=80=9Cdust-class=E2=80=9D mean? Are you using the Bitcoin Co= re dust limit or=20 talking about small amounts in general? I don=E2=80=99t have figures off th= e top of=20 my head, but I would assume that there are relatively few UTXOs smaller=20 than BitcoinCore=E2=80=99s dust limit. I=E2=80=99m not referring to Bitcoin Core=E2=80=99s relay dust limits here.= By =E2=80=9Cdust-class=E2=80=9D=20 I mean outputs that are economically irrational to spend under typical fee= =20 conditions, even though they remain technically valid. Using current=20 standard input sizes (=E2=89=8868 vB for P2WPKH, =E2=89=8857.5 vB for P2TR = keypath, =E2=89=88148 vB=20 for P2PKH), the break-even spend cost quickly rises into the hundreds of=20 sats once fee rates exceed a few sat/vB. At more common feerates (=E2=89=88= 5=E2=80=9310=20 sat/vB), outputs below roughly 500=E2=80=931500 sats are rationally abandon= ed=20 depending on script type. So this is an economic classification, not a=20 relay-policy one. > You might want to clarify that you mean only P2TR KP inputs. Or would=20 P2TR SP be permitted? Yes =E2=80=94 only P2TR key-path spends would be permitted. Script-path spe= nds=20 would be excluded. I=E2=80=99ll make that explicit. > It would be a lot of work to have a separate pool for this, and I don=E2= =80=99t=20 see a reason why they couldn=E2=80=99t just go in the regular mempool. Agreed. A physically separate mempool is not required. The intent is simply= =20 that these transactions sit at the very bottom of the normal mempool=E2=80= =99s=20 priority ordering and are treated as lowest priority for eviction and=20 inclusion > That said, at 50% full, there are still around ~30 blocks worth of=20 transactions waiting in the mempool that pay fees, =E2=80=A6 Right - and DustSweep is not intended to provide any liveness guarantees in= =20 that situation. These transactions are explicitly opportunistic and are=20 expected to idle or expire during sustained congestion. That behaviour is= =20 acceptable and consistent with the goal of ensuring they never compete with= =20 fee-paying transactions. The 50% figure was meant as an illustrative policy= =20 threshold, not a claim that blockspace is otherwise unused. > =E2=80=A6the only ones I have seen lately are miners using a minimum feer= ate of 1=20 s/vB for their block templates. That aligns with the intent. DustSweep transactions would only ever be=20 eligible after normal block assembly, and only in templates that already=20 include all available fee-paying transactions. > I assume the intention is to only relay these transactions when there are= =20 blocks that aren=E2=80=99t full, to limit the bandwidth-wasting vector this= feature=20 introduces, but overall it seems to me that it would be most likely for=20 such transactions to sit in nodes=E2=80=99 memory until they expire. That=E2=80=99s a fair characterization, and it matches the design goals. To= further=20 limit policy complexity and relay churn, DustSweep transactions would also= =20 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=20 without confirmation is an expected outcome rather than a failure mode.=20 Importantly, these constraints mean DustSweep transactions require no=20 additional mempool state tracking, package evaluation, or replacement logic= =20 beyond what nodes already implement today.=20 > It doesn=E2=80=99t seem obvious to me that saving a few dozen sats would = greatly=20 foster the users=E2=80=99 urge to consolidate. It feels like a lot of overh= ead for=20 such a small incentive to the users, and relying on the miners to give away= =20 blockspace below market value feels a bit optimistic as well. I agree that the incentive is not primarily about recovering value.=20 Empirically, outputs in this range represent a large number of UTXOs but=20 very little aggregate bitcoin value. Even aggressive consolidation would=20 recover well under a single BTC in total. The motivation is instead about= =20 long-term UTXO set hygiene: providing a narrow, predictable mechanism for= =20 compacting outputs that are otherwise rationally abandoned, without=20 displacing market transactions or altering fee dynamics. Because the=20 economic value involved is small, the mechanism is intentionally=20 constrained to avoid creating meaningful incentives for either users or=20 miners to game block construction or relay policy. The benefit is therefore= =20 not measured in recovered bitcoin value, but in avoided long-term UTXO=20 growth and reduced steady-state resource costs for nodes.=20 Separately (and not a dependency of this proposal), public analysis of=20 inscription-related activity shows that a significant share of UTXO growth= =20 is tied to metadata-heavy patterns. Future work on segregated data lanes=20 could allow voluntary compaction of those UTXOs while preserving metadata,= =20 but that=E2=80=99s orthogonal to DustSweep itself. Kind regards, Defenwycke On Friday, December 12, 2025 at 11:19:17=E2=80=AFPM UTC Murch wrote: > Hey Defenwycke, > > > all inputs are =E2=80=9Cdust-class=E2=80=9D UTXOs > > What does =E2=80=9Cdust-class=E2=80=9D mean? Are you using the Bitcoin Co= re dust limit=20 > or talking about small amounts in general? I don=E2=80=99t have figures o= ff the=20 > top of my head, but I would assume that there are relatively few UTXOs=20 > smaller than Bitcoin Core=E2=80=99s dust limit. > > > only standard scripts (P2PKH / P2WPKH / P2TR) > > You might want to clarify that you mean only P2TR KP inputs. Or would=20 > P2TR SP be permitted? > > > Nodes place these in a small, separate sub-mempool. They=E2=80=99re onl= y > > accepted when the normal mempool is <50% full, and they=E2=80=99re > > 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=E2= =80=99t=20 > see a reason why they couldn=E2=80=99t just go in the regular mempool. If= the=20 > mempool fills up, they=E2=80=99d have the lowest feerates and they=E2=80= =99d get kicked=20 > out first anyway. That said, at 50% full, there are still around ~30=20 > blocks worth of transactions waiting in the mempool that pay fees, =E2=80= =A6 > > > Miners can include them up to a small weight fraction (I suggest ~5%)= =20 > but only after filling the block with regular fee-paying transactions. > > =E2=80=A6 so if they are only considered in blocks that aren=E2=80=99t fu= ll, the only=20 > ones I have seen lately are miners using a minimum feerate of 1=E2=80=AFs= /vB for=20 > their block templates. Looking at some popular mempool statistic sites,= =20 > in the past 32 months, there would have only been organically non-full=20 > blocks between April and August this year. > > I assume the intention is to only relay these transactions when there=20 > are blocks that aren=E2=80=99t full, to limit the bandwidth-wasting vecto= r this=20 > feature introduces, but overall it seems to me that it would be most=20 > likely for such transactions to sit in nodes=E2=80=99 memory until they e= xpire. > > All that said, at the new minimum feerate of 0.1=E2=80=AFs/vB, a 148=E2= =80=AFvB P2PKH=20 > input costs 15=E2=80=AFsats, a 68 vB P2WPKH input costs 7 sats, and a 57.= 5 vB=20 > P2TR input costs 6 sats. It doesn=E2=80=99t seem obvious to me that savin= g a few=20 > dozen sats would greatly foster the users=E2=80=99 urge to consolidate. I= t feels=20 > like a lot of overhead for such a small incentive to the users, and=20 > relying on the miners to give away blockspace below market value feels a= =20 > bit optimistic as well. > > Cheers, > Murch > > On 2025-12-11 04:53, defenwycke wrote: > > Hello list, > >=20 > > I=E2=80=99ve been working on a small policy proposal that aims to addre= ss one=20 > > very specific problem: the long-term accumulation of uneconomical dust= =20 > > in the UTXO set. > >=20 > > The idea is intentionally narrow. I=E2=80=99m calling it DustSweep, and= it=20 > > defines a strict, non-abusable class of transactions that nodes may=20 > > relay and miners may include only when the mempool and block space are= =20 > > underutilised. The goal is to give wallets a predictable way to compact= =20 > > dust without introducing new spam vectors or touching consensus. > >=20 > > A DustSweep transaction has the following properties: > >=20 > > * > >=20 > > all inputs are =E2=80=9Cdust-class=E2=80=9D UTXOs > >=20 > > * > >=20 > > only standard scripts (P2PKH / P2WPKH / P2TR) > >=20 > > * > >=20 > > exactly one output > >=20 > > * > >=20 > > no metadata at all (no OP_RETURN, inscriptions, TLVs, etc.) > >=20 > > * > >=20 > > minimum of 5 inputs (to ensure meaningful UTXO reduction) > >=20 > > * > >=20 > > size capped > >=20 > > * > >=20 > > it pays a flat 1 sat per input fee > >=20 > > Nodes place these in a small, separate sub-mempool. They=E2=80=99re onl= y=20 > > accepted when the normal mempool is <50% full, and they=E2=80=99re auto= matically=20 > > evicted if normal mempool usage hits 95%. Miners can include them up to= =20 > > a small weight fraction (I suggest ~5%) but only after filling the bloc= k=20 > > with regular fee-paying transactions. The intention is that DustSweep= =20 > > never competes with the fee market and only uses blockspace that would= =20 > > otherwise go unused. > >=20 > > This is all policy-level. No consensus changes, no new transaction=20 > > format, nothing that affects validation. Nodes that don=E2=80=99t imple= ment it=20 > > simply treat these as low-fee transactions and drop them. > >=20 > > The motivation is straightforward: we don=E2=80=99t currently have a sa= fe,=20 > > structured way to compact dust, and the UTXO set continues to grow from= =20 > > outputs that are effectively unspendable under normal fee conditions.= =20 > > DustSweep tries to offer a predictable, opt-in mechanism for wallets to= =20 > > clean that up without creating any new attack surface. > >=20 > > Full draft BIP and supporting documents are here: > >=20 > > https://github.com/defenwycke/bip-dust-sweep > >=20 > > I=E2=80=99d appreciate feedback on the policy details, thresholds, and = whether=20 > > this fits within what node operators and wallet developers would=20 > > actually want to use. Happy to adjust parameters if there=E2=80=99s a b= etter=20 > > balance point. > >=20 > > Kind regards, > >=20 > > Defenwycke > >=20 > > --=20 > > You received this message because you are subscribed to the Google=20 > > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send= =20 > > an email to bitcoindev+...@googlegroups.com=20 > > . > > To view this discussion visit https://groups.google.com/d/msgid/=20 > > bitcoindev/b47aa182-bca7-44d7-bed1-f3cc2df30ef5n%40googlegroups.com=20 > > > f3cc2df30ef5n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter= >. > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 841d6882-9853-4d96-84e8-c4742e17e969n%40googlegroups.com. ------=_Part_321111_1818376120.1765637791925 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Murch,

Thanks for the thoughtful response. Please find my response below.

> What does =E2=80=9Cdust-class=E2=80=9D mean? Are you using the Bitcoi= n Core dust limit or talking about small amounts in general? I don=E2=80=99= t have figures off the top of my head, but I would assume that there are re= latively few UTXOs smaller than BitcoinCore=E2=80=99s dust limit.

I=E2=80=99m not referring to Bitcoin Core=E2=80=99s relay dust limits he= re. By =E2=80=9Cdust-class=E2=80=9D I mean outputs that are economically ir= rational to spend under typical fee conditions, even though they remain tec= hnically valid. Using current standard input sizes (=E2=89=8868 vB for P2WP= KH, =E2=89=8857.5 vB for P2TR keypath, =E2=89=88148 vB for P2PKH), the brea= k-even spend cost quickly rises into the hundreds of sats once fee rates ex= ceed a few sat/vB. At more common feerates (=E2=89=885=E2=80=9310 sat/vB), = outputs below roughly 500=E2=80=931500 sats are rationally abandoned depend= ing on script type. So this is an economic classification, not a relay-poli= cy one.

> You might want to clarify that you mean only P2TR KP inp= uts. Or would P2TR SP be permitted?

Yes =E2=80=94 only P2TR key-path spends would be permitted. Script-path = spends would be excluded. I=E2=80=99ll make that explicit.

> It wo= uld be a lot of work to have a separate pool for this, and I don=E2=80=99t = see a reason why they couldn=E2=80=99t just go in the regular mempool.

Agreed. A physically separate mempool is not required. The intent is sim= ply that these transactions sit at the very bottom of the normal mempool=E2= =80=99s priority ordering and are treated as lowest priority for eviction a= nd inclusion

> That said, at 50% full, there are still around ~30 = blocks worth of transactions waiting in the mempool that pay fees, =E2=80= =A6

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 polic= y threshold, not a claim that blockspace is otherwise unused.

> = =E2=80=A6the only ones I have seen lately are miners using a minimum feerat= e of 1 s/vB for their block templates.

That aligns with the intent. DustSweep transactions would only ever be e= ligible after normal block assembly, and only in templates that already inc= lude all available fee-paying transactions.

> I assume the intenti= on is to only relay these transactions when there are blocks that aren=E2= =80=99t full, to limit the bandwidth-wasting vector this feature introduces= , but overall it seems to me that it would be most likely for such transact= ions to sit in nodes=E2=80=99 memory until they expire.

That=E2=80=99s 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 unconfirme= d ancestors

- RBF disabled (no replacement or package churn)

- = No CPFP assumptions

This keeps them cheap to reason about for node operators, and expiry wit= hout confirmation is an expected outcome rather than a failure mode. Import= antly, these constraints mean DustSweep transactions require no additional = mempool state tracking, package evaluation, or replacement logic beyond wha= t nodes already implement today.

> It doesn=E2=80=99t seem obvious to me that saving a few dozen s= ats would greatly foster the users=E2=80=99 urge to consolidate. It feels l= ike 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 optimi= stic as well.

I agree that the incentive is not primarily about recovering value. Empi= rically, outputs in this range represent a large number of UTXOs but very l= ittle 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 mea= ningful incentives for either users or miners=C2=A0to game block constructi= on or relay policy. The benefit is therefore not measured in recovered bitc= oin value, but in avoided long-term UTXO growth and reduced steady-state re= source costs for nodes.

Separately (and not a dependency of this proposal), public analysis of i= nscription-related activity shows that a significant share of UTXO growth i= s tied to metadata-heavy patterns. Future work on segregated data lanes cou= ld allow voluntary compaction of those UTXOs while preserving metadata, but= that=E2=80=99s orthogonal to DustSweep itself.

Kind regards,

Defenwycke


On Friday, December 12, 2025 at 11:19:17=E2=80=AFPM UTC Murch wr= ote:
Hey Defe= nwycke,

> all inputs are =E2=80=9Cdust-class=E2=80=9D UTXOs

What does =E2=80=9Cdust-class=E2=80=9D mean? Are you using the Bitcoin = Core dust limit=20
or talking about small amounts in general? I don=E2=80=99t have figures= off the=20
top of my head, but I would assume that there are relatively few UTXOs= =20
smaller than Bitcoin Core=E2=80=99s dust limit.

> only standard scripts (P2PKH / P2WPKH / P2TR)

You might want to clarify that you mean only P2TR KP inputs. Or would= =20
P2TR SP be permitted?

> Nodes place these in a small, separate sub-mempool. They=E2=80=99= re only
> accepted when the normal mempool is <50% full, and they=E2=80= =99re
> 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= =E2=80=99t=20
see a reason why they couldn=E2=80=99t just go in the regular mempool. = If the=20
mempool fills up, they=E2=80=99d have the lowest feerates and they=E2= =80=99d get kicked=20
out first anyway. That said, at 50% full, there are still around ~30=20
blocks worth of transactions waiting in the mempool that pay fees, =E2= =80=A6

> Miners can include them up to a small weight fraction (I suggest = ~5%)=20
but only after filling the block with regular fee-paying transactions.

=E2=80=A6 so if they are only considered in blocks that aren=E2=80=99t = full, the only=20
ones I have seen lately are miners using a minimum feerate of 1=E2=80= =AFs/vB for=20
their block templates. Looking at some popular mempool statistic sites,= =20
in the past 32 months, there would have only been organically non-full= =20
blocks between April and August this year.

I assume the intention is to only relay these transactions when there= =20
are blocks that aren=E2=80=99t full, to limit the bandwidth-wasting vec= tor this=20
feature introduces, but overall it seems to me that it would be most=20
likely for such transactions to sit in nodes=E2=80=99 memory until they= expire.

All that said, at the new minimum feerate of 0.1=E2=80=AFs/vB, a 148=E2= =80=AFvB P2PKH=20
input costs 15=E2=80=AFsats, a 68 vB P2WPKH input costs 7 sats, and a 5= 7.5 vB=20
P2TR input costs 6 sats. It doesn=E2=80=99t seem obvious to me that sav= ing a few=20
dozen sats would greatly foster the users=E2=80=99 urge to consolidate.= It feels=20
like a lot of overhead for such a small incentive to the users, and=20
relying on the miners to give away blockspace below market value feels = a=20
bit optimistic as well.

Cheers,
Murch

On 2025-12-11 04:53, defenwycke wrote:
> Hello list,
>=20
> I=E2=80=99ve been working on a small policy proposal that aims to = address one=20
> very specific problem: the long-term accumulation of uneconomical = dust=20
> in the UTXO set.
>=20
> The idea is intentionally narrow. I=E2=80=99m calling it DustSweep= , and it=20
> defines a strict, non-abusable class of transactions that nodes ma= y=20
> relay and miners may include only when the mempool and block space= are=20
> underutilised. The goal is to give wallets a predictable way to co= mpact=20
> dust without introducing new spam vectors or touching consensus.
>=20
> A DustSweep transaction has the following properties:
>=20
> *
>=20
> all inputs are =E2=80=9Cdust-class=E2=80=9D UTXOs
>=20
> *
>=20
> only standard scripts (P2PKH / P2WPKH / P2TR)
>=20
> *
>=20
> exactly one output
>=20
> *
>=20
> no metadata at all (no OP_RETURN, inscriptions, TLVs, etc.)
>=20
> *
>=20
> minimum of 5 inputs (to ensure meaningful UTXO reduction)
>=20
> *
>=20
> size capped
>=20
> *
>=20
> it pays a flat 1 sat per input fee
>=20
> Nodes place these in a small, separate sub-mempool. They=E2=80=99r= e only=20
> accepted when the normal mempool is <50% full, and they=E2=80= =99re automatically=20
> evicted if normal mempool usage hits 95%. Miners can include them = up to=20
> a small weight fraction (I suggest ~5%) but only after filling the= block=20
> with regular fee-paying transactions. The intention is that DustSw= eep=20
> never competes with the fee market and only uses blockspace that w= ould=20
> otherwise go unused.
>=20
> This is all policy-level. No consensus changes, no new transaction= =20
> format, nothing that affects validation. Nodes that don=E2=80=99t = implement it=20
> simply treat these as low-fee transactions and drop them.
>=20
> The motivation is straightforward: we don=E2=80=99t currently have= a safe,=20
> structured way to compact dust, and the UTXO set continues to grow= from=20
> outputs that are effectively unspendable under normal fee conditio= ns.=20
> DustSweep tries to offer a predictable, opt-in mechanism for walle= ts to=20
> clean that up without creating any new attack surface.
>=20
> Full draft BIP and supporting documents are here:
>=20
> https://github.com/defenwycke/bip-dust-sweep
>=20
> I=E2=80=99d appreciate feedback on the policy details, thresholds,= and whether=20
> this fits within what node operators and wallet developers would= =20
> actually want to use. Happy to adjust parameters if there=E2=80=99= s a better=20
> balance point.
>=20
> Kind regards,
>=20
> Defenwycke
>=20
> --=20
> You received this message because you are subscribed to the Google= =20
> Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, = send=20
> an email to bitcoindev+= ...@googlegroups.com=20
> <mailto:bitcoindev+.= ..@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/=20
> bitcoindev/b47aa182-bca7-44d7-bed1-f3cc2df30ef5n%40googlegroups.com=20
> <https://groups.google.= com/d/msgid/bitcoindev/b47aa182-bca7-44d7-bed1-=20
> f3cc2df30ef5n%40googlegroups.= com?utm_medium=3Demail&utm_source=3Dfooter>.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/841d6882-9853-4d96-84e8-c4742e17e969n%40googlegroups.com.
------=_Part_321111_1818376120.1765637791925-- ------=_Part_321110_930870268.1765637791925--