From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 12 Dec 2025 10:16:31 -0800 Received: from mail-ot1-f60.google.com ([209.85.210.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vU7gs-00064z-RV for bitcoindev@gnusha.org; Fri, 12 Dec 2025 10:16:31 -0800 Received: by mail-ot1-f60.google.com with SMTP id 46e09a7af769-7c7028db074sf2853788a34.1 for ; Fri, 12 Dec 2025 10:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765563385; x=1766168185; 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=eiRLW5u45Er75XALBM1TLhJJr8fi0AXPEk/1tz+ogmo=; b=CipMbt6Wql32TKR1VLFulGpMmlCCKzL+gSSHqRKIjkVITGx1WNDsB9BAuqgrtlt2M7 BDCHAR4pwy0e2iLXlAIsQdmKFaW7Kc3RrHl+WiGKEICRqFs1BwrRca3SHdQIR4Lqj4Ux mw+bNkzBzAPlzOWT1gvKTukJGl0uQwxir19qdq7q4sdWobsTJ5449CpUgU4cUnRAx3At VKrx2Dy/nvOaZ3VyQS8p+ZCcqhE8DKmArbLEBzxv5o2v/asfuWBxJJOAsh1X1l6GWz3H 044+PCRivzoQ60azTpaa1GXIqhxRjE0+Viit1Ls0uX9liQmHGAC1Gb9lmBAi0DDCimyj viQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765563385; x=1766168185; 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=eiRLW5u45Er75XALBM1TLhJJr8fi0AXPEk/1tz+ogmo=; b=XTm95iSFYTg7D/E25uPHb5zQq1BkZ3ApMhVQ3TTsEpHLfR9YX4ZjkQADimNcZr+1jW hz21gmIbRNVRyRQk0zsZ6MAjEamWxEdw1laZOvKdJwEfI6x7AxRxOlmXMJ+XvBO1tsfe /djQe+f2UeHWYuAf32K1TbybaTBVHydYZgnec55K6yPUl7kw38zG10iKTZgQvDl7e6S3 9GhiY2rnmdfsvdi0kGcpVEin9+jFF0KbxwH3HgjJ+166T/Vsq5e56bRFCXqc5O6EdTak RgZRIOO6zINiHfuEU4kkvCLqqCwy7BqBsY+M6Ss5/VW34IjnClk6gQGzKNC2xIT8uAex Zetw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765563385; x=1766168185; 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=eiRLW5u45Er75XALBM1TLhJJr8fi0AXPEk/1tz+ogmo=; b=whT+sEdipygyOpeC8NhIQ77N/i02CacWbM/HMABDDjDNQhNqq05P5+s7n9TqiKzib8 ZWWM49X9qFo67DYi4QAZFtxfTWZezVEYPP0NW4LHY8jGyqhL4QirxCUw1XkXtd1799HB hbTUyo6Tm3+Afy+nMiDRuJaNWmO1sxO9dJLTsgt2AM+mJBmpUUOn7Yxc9+b4wLloVlhU FbUBWkBpIsOaAZGDeGPR0TFdOYH6MDalsGOtP/qU8QD/0DAx/2OWwtooXSLd+PvhjEB6 Jq0ryNeDl15/LHnG6y4pjY9eu2qTCNL93ShGtN8BrWBMtnAVEs4i7PW/nsqq41IfyPU2 0T7w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW4zRVdyPhuvKAO1LEggx/vLb/9/ZKBv5SH3xG1ooFmJQ0KOOWiHpe6KUBq7CJzzgSeYjn13XaWivU5@gnusha.org X-Gm-Message-State: AOJu0YyPeyFGEauRwtD5F4qrA8sdYAs9HXhvXlddhxvGGxLVzLUmmq97 Lhj3dEHV6gCobCV3aF/3uJ1owNulguIZG+8ywZll6q4TGvrqfSYr+f1T X-Google-Smtp-Source: AGHT+IFCFZTgsMLMIkEZ0g3o/+7+7UMj2MhuMBtbsmo1QZxQJRZCYREGA2uIol6vl35P24jgzY8xVw== X-Received: by 2002:a05:6820:1522:b0:659:9a49:8ef8 with SMTP id 006d021491bc7-65b4511f7d5mr1128769eaf.9.1765563384528; Fri, 12 Dec 2025 10:16:24 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZ8Vz0VD2LtPWi7YKgt02On26y0auoaaCd8WVCFhkqPAQ==" Received: by 2002:a05:6820:6be3:b0:657:5eba:68b3 with SMTP id 006d021491bc7-65b43998f35ls485506eaf.1.-pod-prod-05-us; Fri, 12 Dec 2025 10:16:20 -0800 (PST) X-Received: by 2002:a05:6808:4f64:b0:450:c423:205d with SMTP id 5614622812f47-455ac9890ebmr1601514b6e.46.1765563380678; Fri, 12 Dec 2025 10:16:20 -0800 (PST) Received: by 2002:a05:690c:950d:b0:786:8d90:70d8 with SMTP id 00721157ae682-78e64591f1ems7b3; Fri, 12 Dec 2025 10:10:53 -0800 (PST) X-Received: by 2002:a05:690c:6502:b0:788:e74:b277 with SMTP id 00721157ae682-78e66c75037mr27866017b3.63.1765563050602; Fri, 12 Dec 2025 10:10:50 -0800 (PST) Date: Fri, 12 Dec 2025 10:10:50 -0800 (PST) From: Jonathan Voss To: Bitcoin Development Mailing List Message-Id: <382cefe0-4ac0-43d7-919b-c56fad0a9b27n@googlegroups.com> In-Reply-To: References: Subject: =?UTF-8?Q?=5Bbitcoindev=5D_Re=3A_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_1722_1173257363.1765563050240" X-Original-Sender: K98kurz@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_1722_1173257363.1765563050240 Content-Type: multipart/alternative; boundary="----=_Part_1723_124489399.1765563050241" ------=_Part_1723_124489399.1765563050241 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Interesting proposal. Something like that would be helpful, but perhaps it= =20 would be more useful if it was not quite so narrowly defined. For example,= =20 instead of requiring all inputs be dust-class UTXO, it could require a=20 minimum of 80% dust-class inputs; instead of exactly one output, it could= =20 be max_outputs =3D floor(n_inputs / 5) to keep a maximum output/input ratio= =20 of 1/5. This could allow for better aggregation of dust outputs into=20 economically meaningful, monetary outputs than the narrower definition=20 while maintaining the incentives for meaningfully reducing UTXO set size. I would run this policy on my node. Hashers should ultimately be okay with= =20 this policy since someone among them also has to run full nodes, and it=20 would provide an additional (albeit very small) fee source when block space= =20 demand is low. On Thursday, December 11, 2025 at 8:34:16=E2=80=AFAM UTC-5 defenwycke wrote= : > Hello list, > > I=E2=80=99ve been working on a small policy proposal that aims to address= one very=20 > specific problem: the long-term accumulation of uneconomical dust in the= =20 > UTXO set. > > The idea is intentionally narrow. I=E2=80=99m calling it DustSweep, and i= t defines=20 > a strict, non-abusable class of transactions that nodes may relay and=20 > miners may include only when the mempool and block space are underutilise= d.=20 > The goal is to give wallets a predictable way to compact dust without=20 > introducing new spam vectors or touching consensus. > > 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 only = accepted=20 > when the normal mempool is <50% full, and they=E2=80=99re automatically e= victed if=20 > normal mempool usage hits 95%. Miners can include them up to a small weig= ht=20 > fraction (I suggest ~5%) but only after filling the block with regular=20 > fee-paying transactions. The intention is that DustSweep never competes= =20 > with the fee market and only uses blockspace that would otherwise go unus= ed. > > This is all policy-level. No consensus changes, no new transaction format= ,=20 > nothing that affects validation. Nodes that don=E2=80=99t implement it si= mply treat=20 > these as low-fee transactions and drop them. > > 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 conditions.=20 > DustSweep tries to offer a predictable, opt-in mechanism for wallets to= =20 > 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=E2=80=99d appreciate feedback on the policy details, thresholds, and wh= ether=20 > this fits within what node operators and wallet developers would actually= =20 > want to use. Happy to adjust parameters if there=E2=80=99s a better balan= ce point. > > Kind regards, > > Defenwycke > --=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/= 382cefe0-4ac0-43d7-919b-c56fad0a9b27n%40googlegroups.com. ------=_Part_1723_124489399.1765563050241 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 mini= mum of 80% dust-class inputs; instead of exactly one output, it could be ma= x_outputs =3D floor(n_inputs / 5) to keep a maximum output/input ratio of 1= /5. This could allow for better aggregation of dust outputs into economical= ly meaningful, monetary outputs than the narrower definition while maintain= ing 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 sp= ace demand is low.

On Thursday, December 11, 2025 at 8:34:16=E2=80= =AFAM UTC-5 defenwycke wrote:
Hello list,

I=E2=80=99ve been working on a small po= licy 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=E2=80=99m calling it DustSweep, and = it defines a strict, non-abusable class of transactions that nodes may rela= y and miners may include only when the mempool and block space are underuti= lised. The goal is to give wallets a predictable way to compact dust withou= t introducing new spam vectors or touching consensus.

A DustSweep transaction has the following properties:

  • all inputs are =E2=80=9Cdust-class=E2=80=9D 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=E2=80=99re only= accepted when the normal mempool is <50% full, and they=E2=80=99re auto= matically 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 b= lock with regular fee-paying transactions. The intention is that DustSweep = never competes with the fee market and only uses blockspace that would othe= rwise go unused.

This is all policy-level. No consensus changes, no new transaction forma= t, nothing that affects validation. Nodes that don=E2=80=99t implement it s= imply treat these as low-fee transactions and drop them.

The motivation is straightforward: we don=E2=80=99t currently have a saf= e, structured way to compact dust, and the UTXO set continues to grow from = outputs that are effectively unspendable under normal fee conditions. DustS= weep tries to offer a predictable, opt-in mechanism for wallets to clean th= at up without creating any new attack surface.

Full draft BIP and supporting documents are here:

https://github.com/defenwycke/bip-dust-swee= p

I=E2=80=99d appreciate feedback on the policy details, thresholds, and w= hether this fits within what node operators and wallet developers would act= ually want to use. Happy to adjust parameters if there=E2=80=99s a better b= alance point.

Kind regards,

Defenwycke

=

--
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/382cefe0-4ac0-43d7-919b-c56fad0a9b27n%40googlegroups.com.
------=_Part_1723_124489399.1765563050241-- ------=_Part_1722_1173257363.1765563050240--