From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 11 Dec 2025 05:34:23 -0800 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vTgoI-0005LW-Sd for bitcoindev@gnusha.org; Thu, 11 Dec 2025 05:34:23 -0800 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-3f524bd05bbsf81458fac.1 for ; Thu, 11 Dec 2025 05:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765460056; x=1766064856; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=sBjAAhQY4ATeJXKzLZX7beNyzX2FSZe+1+Q63zDyu34=; b=DYWFypZtib8a3lhIs4mZiIHxeCjI3AC4PuHARvPPj6Q17032VMdcMXXvx0/+qaYaa0 v8AWqtLqDt03lYofFcOI70UjOOAj4HkF4uOakaDxnwbdlnA91QNku1HzcS49HSC4h7T/ mo8blqzaLTVE2ELc33JWHR/epiBm77PdiSQzMRLHdIO0iLtFDG8Pa9jaaPvzOkiEI7Q7 pKbaGnJiTVr3SvTwK2w2p09hFU+2/zWp6eG0xO+c1XnqA1MqA0hKCzmVUMb3oJxV/khe 5QKQtkVxGQ9CklqgN+4dpt+8H4HRocPzt8Y7pAO9aJf+VNVnqwryfaVN5kCYQHlMrWn4 kn7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765460056; x=1766064856; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=sBjAAhQY4ATeJXKzLZX7beNyzX2FSZe+1+Q63zDyu34=; b=mBDQPYPRLbKt5/4C9Qo9756+nexp4nxTv9QFhP07XGAK5TLqcRBfH8kyXcN2FosUzC ip/XYcoyF9cEmWJgNIBNhOwnYi4ui9bvh8Q4NP/QksxgC8TLQMADBPh+34Oqo97q45tY uPs7O7HKl2Kls0mKdeCsalpuJd3vAjzLkgxGBMPQKHhH6mUd2i3r3KwfbDXQRlF+NsNw PxiDCnJBrvAhd1Hv3YzX/CbNhYS94jnWGnjHtyzuhAhv5daWybWFqXGGGfWOKpaK1Q2B UeuNiyzW9cnuSfzQX/+3kVQqkIaqSFrb5oOPgHvQhAcfqOzCa9UuWwcF5Z9mHL9VmmlT E7Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765460056; x=1766064856; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=sBjAAhQY4ATeJXKzLZX7beNyzX2FSZe+1+Q63zDyu34=; b=ndiIBNiQ2LyccGulxgcZvOIAwzxl3xXJoIdgHzzVXELVS3nqYoJ0M2yuPe5sXzyQZV okC4uuZJVA3U7TD7/s31q39RroaHT21uXQcH6e2o1d9q0umkivH74kP0zbalIJiL5H/m 47UDWEzTBRNtwjiAVx/w6s3F9kdjve2KvN3LZq+kww7hjgf0LyQ1piZjwyO1zQHnYqTx lh2GbPXRzbc6rJFzgiVye6hrt5SJj70HE3Z7xCm645hEB+xKzda6vchNWAHmRDIVT7z1 n5LNrWCya5W6Z9WgMclDn6CI1OL0Q1EOR5/QoNN/DfsuSb1xyhmmDvOpoXzRxgSRd3tL 8KEw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXbyQj9S7c9ert3TuBDY/za09ZzHXxz4wlGy6NOi7I1DKSzjESaB64mPt5NGoR1Fs30th5gQHe6mdEo@gnusha.org X-Gm-Message-State: AOJu0YxfjuROjuH372t0JoxTntHT0QNBIOzLDO2UWYpNrCBT2VYoHvC4 +wgOcp10tlEJEeXJ0r+lovwLInBSYMpOCdYRn+H5X9zn9GwARR+bMFKT X-Google-Smtp-Source: AGHT+IH+2DgnX5SXCHewgff/C2q3DqSh89EPOgWbD/pzrgUNRQ8DAyb13+4cnSEdwgmxObJKVJ6a6g== X-Received: by 2002:a05:6870:65aa:b0:3d3:10b4:9cc2 with SMTP id 586e51a60fabf-3f5bde4d34emr3805001fac.44.1765460056108; Thu, 11 Dec 2025 05:34:16 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWax7IuuESp2Wc4zYnXAHikho3MciXKdOKLPLLraACMAdQ==" Received: by 2002:a05:687c:5b:20b0:3e8:4817:7a50 with SMTP id 586e51a60fabf-3f5d73c7e0els336566fac.0.-pod-prod-05-us; Thu, 11 Dec 2025 05:34:12 -0800 (PST) X-Received: by 2002:a05:6808:3206:b0:450:c648:4aeb with SMTP id 5614622812f47-455864ea65fmr3289761b6e.44.1765460052032; Thu, 11 Dec 2025 05:34:12 -0800 (PST) Received: by 2002:a05:690c:768f:b0:786:8d90:70d8 with SMTP id 00721157ae682-78c23b93f22ms7b3; Thu, 11 Dec 2025 04:53:20 -0800 (PST) X-Received: by 2002:a05:690e:419b:b0:644:60d9:753a with SMTP id 956f58d0204a3-6446ec951bcmr4508103d50.96.1765457599104; Thu, 11 Dec 2025 04:53:19 -0800 (PST) Date: Thu, 11 Dec 2025 04:53:18 -0800 (PST) From: defenwycke To: Bitcoin Development Mailing List Message-Id: Subject: =?UTF-8?Q?=5Bbitcoindev=5D_Draft_BIP=3A_DustSweep_=E2=80=93_policy=2Donly_UT?= =?UTF-8?Q?XO_dust_compaction?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_117562_1148971894.1765457598773" 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_117562_1148971894.1765457598773 Content-Type: multipart/alternative; boundary="----=_Part_117563_2028750239.1765457598773" ------=_Part_117563_2028750239.1765457598773 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello list, I=E2=80=99ve been working on a small policy proposal that aims to address o= ne 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 it = 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 underutilised.= =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 ac= cepted=20 when the normal mempool is <50% full, and they=E2=80=99re automatically evi= cted if=20 normal mempool usage hits 95%. Miners can include them up to a small weight= =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 unused= . 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 simp= ly 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 whet= her this=20 fits within what node operators and wallet developers would actually want= =20 to use. Happy to adjust parameters if there=E2=80=99s a better balance poin= t. 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/= b47aa182-bca7-44d7-bed1-f3cc2df30ef5n%40googlegroups.com. ------=_Part_117563_2028750239.1765457598773 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello list,

I=E2=80=99ve been working on a small policy proposal tha= t 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-sweep

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/b47aa182-bca7-44d7-bed1-f3cc2df30ef5n%40googlegroups.com.
------=_Part_117563_2028750239.1765457598773-- ------=_Part_117562_1148971894.1765457598773--