From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 06 Apr 2026 14:04:33 -0700 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 1w9r7X-0004hW-Nu for bitcoindev@gnusha.org; Mon, 06 Apr 2026 14:04:33 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-40efa542b8asf7939845fac.2 for ; Mon, 06 Apr 2026 14:04:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775509466; cv=pass; d=google.com; s=arc-20240605; b=ClvqiATjKsUZtNk2bwiEbhFHTvUU8PsBrCnh7ZWwBQ07lUHwNseUbNj1lMoJD94Vxd jslaj/zGHNiXGKVL7X5xWeRXAlpNgWANcCnihXzWVL6hlvPRMaHksAzRcOWMezodyJPP Jein2PXZ2frQiEsI7lIEeIpzIvoAfu+VpzBtXRRfEg2QOXeSLKUqMTkuOt5NGcobAg7r udvZjGzL/jZNQyXmv6j9pkOR0Jy8r01viS6y9nBKCbMyFqGn2aAQNBzrANfY9yZ1mkmP c/SLddyAMpYmYAIRk2N3ZR0WqEcJr3OfrCbpXD0udVLCfoNr/hYzTkOarFwLgM5Gsf0y TpFA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:sender:dkim-signature; bh=NLGJXqJMMD8PHNjrP+vCw4RF16LqgLm+lA1eTQLvR+U=; fh=mW5Lll5pUesN8bIbgijHMNNjYSPUiQfqtt70ZxcM1f0=; b=MzZvpQ/7x81M+NH0AtUczWBFSJMsGhw3mF9yjzAOryeZwEyRlyUY7w8XVM+JLmm9+5 wdkANYEhFVRMfHNYDDhZS05ei9WdLV/zQn5sQYpynCOnW1mggvyYRiulFHFT3FbrDyUL /wFosTM9rOUlJWMASWUvFlFAsN+7K5XgteRbb8KGQoS4PFQVkpPrw1qT2Ptl2cLzBOxD NkwVBa4WdVZVDaXzfD8NE+6VbvMVqOsY0l+x8d29JOr6kQx7ciyoO1HC3T/Y+8DpmMia txLNwA5Yp7mFm3EmHBAtmWaERGe8x9DAMO+6biJP6Wqa5C/sgCC8H9x1/brCRlEOSQAB wJ4A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=tR0MMfmk; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1775509466; x=1776114266; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=NLGJXqJMMD8PHNjrP+vCw4RF16LqgLm+lA1eTQLvR+U=; b=nRm8J0UiQg4mHmmI/LF+I/QyjWHVcHFfvBdxqCCkM4LVEbA12yjW4VYAPtswETEaie rMzUvBeSEYcURiaQF8GmtTUsbaRbQbzCeLWVY1xj0AIu/8BcZoAiR/ItM7WV2l6/MBmz N1cbQkYLtLuwo08ECTHk5Bgz12yVHnviY9uACAnZlvxFojEB/aAK/WlY3rPNS5CDu82q gtSYkgdSBC90EQW/Dgsc+cQGQ0Ve4/or+tmcF144+23Iv6arLbVGDboed/7NqojZ3KZ7 Wxtfn6heOI5BFCMLkk00p3Z1TD37vyFtxsoprxxsZ6bolLlWX3RAjrdoTGG0CxeW5rAX SU8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775509466; x=1776114266; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-beenthere:x-gm-message-state:sender:from:to:cc :subject:date:message-id:reply-to; bh=NLGJXqJMMD8PHNjrP+vCw4RF16LqgLm+lA1eTQLvR+U=; b=Y5AInR9znlXkaVdztk3vjBUskzvzHOw6vXQDv5zThpyKHr+Wd0h8wrJIT7U2UoQzwo lG/LsdJYUhu+TImxeSIvSt4ELbx+beTu7HyTeqE8l4pyQbzra9D+myfbD2enWHtUhlVV 9Yn6hQqWkA+u7nIZxq+VU4hbaJSdZaW4N+cOFSjYcZkEsWwmj7888nf5bbEqOw4XDg2a M61yCnBuZbHQL/+Bxzf5Td9BYUqwN5IZ0sBo4yrt36/Vw+Rp+gmtdQ6yqIqhhQFUv15w 1ST8zQRFfgbbVcBc6rFCcCWtX+IMYi3HBI4+lqKuni9D4uLAWs1cT8LkJ++WbSvT21C3 WEPA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWu8ZaersA/W4d9YrSdmu3NmhpT4S/fd+AnnFcLqj7x4eNIdNIDJuA4gNFGC1FINbNDvMaTPjL5UrcU@gnusha.org X-Gm-Message-State: AOJu0YxPOR0KkX3MwHrE9ChaLFSgTI5eaWk2n2v2Qz6q6ajz92kako4R WQyOXB36Bjvb/HeXtYJ/vbKNM8eOlLeQYYyCpWF22vj0U+o5RQ/EiC0n X-Received: by 2002:a05:6870:9e8b:b0:422:e938:6b49 with SMTP id 586e51a60fabf-4231009bc3dmr8196737fac.38.1775509465541; Mon, 06 Apr 2026 14:04:25 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKimYclSbHLfUYwgJ8dTz+3YrygJqSTwQm8IqsB0nk/pA==" Received: by 2002:a05:6870:c14d:b0:417:5927:12e9 with SMTP id 586e51a60fabf-422ee5e31e8ls2619165fac.2.-pod-prod-01-us; Mon, 06 Apr 2026 14:04:21 -0700 (PDT) X-Received: by 2002:a54:4385:0:b0:466:f57b:2ae5 with SMTP id 5614622812f47-46ef883d4b9mr5968951b6e.47.1775509461475; Mon, 06 Apr 2026 14:04:21 -0700 (PDT) Received: by 2002:a05:6504:1146:b0:2f6:91ae:47ef with SMTP id a1c4a302cd1d6-2f691ae4989msc7a; Mon, 6 Apr 2026 13:45:53 -0700 (PDT) X-Received: by 2002:a2e:be92:0:b0:38c:6979:f75d with SMTP id 38308e7fff4ca-38d91d89693mr46247021fa.34.1775508351177; Mon, 06 Apr 2026 13:45:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775508351; cv=none; d=google.com; s=arc-20240605; b=X2dEGpXWuAG9U9Gvwaq6jJg/4ZHlzh740EIF+A6dnkLm/oe4sBbm+t9bCgDba/fxLj RnfegIsGkz/g5eLUeFZJPsh1o42BBx4mVUodU4DtBEMZN4fixd6VNBbHGUTXXEBwZWsd HJH7IXdt3ttSK+BHftHbQQBzWifmOvn90XaoOK2eP2Du3beP9VVvi1O1XZLTiyYc+LDm 09mxnuEish9vX/jdHF7bCVXsfYFhc6Jsc6ay5WpSVTtylj/o/5kLlRIH9LxtbCWNEKO3 XbITm9XDfAD7WZcEvc6ySHBpIMLWS/LqJA+j9uYn1C1jb/yAwAoxJTyXQrajqmM/qAQJ kL3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=dkim-signature:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id; bh=tV424YkreHnDxYhdrQIJ4B5oQWcKufI/8GD7aoPfnLE=; fh=UKpYIwyh5zEFLfLJuDhyC43Feg7AYE/ThzGx2r1JLWY=; b=gY8VM9BytNd0R5if5eAqPKH95VSvwrsp7471/HsIpp31dW8fUaYF3KZ+elrFWGRNYB QxMszVFBSeIWsjTwtlJAA4De8wN+boGahlevgWjZYhea0gEJ1mM13UUiy09nHsV7y0+q KAqit+54PaPweDDCGG0j9pe1wHneuhWWUXbFaW8pHPz2G0ZdTLy+JCUboqyhcX4x82Ds jALAuAlxqcz0zIu4O1AvCZYahE9NpDLht2HkvaYydYDHA+L927A4DT5nUCgzSTPsL8gP 0XlFxDTN5M/bSmBjFimIsJA8MG//ph2eBlEbWqmLi75SccWYFu18kN3Ts/jtecMOs4k5 Sw4w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=tR0MMfmk; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one Received: from mailgate02.uberspace.is (mailgate02.uberspace.is. [2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-38cd1f816dfsi2809691fa.1.2026.04.06.13.45.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2026 13:45:50 -0700 (PDT) Received-SPF: pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) client-ip=2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4; Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235]) by mailgate02.uberspace.is (Postfix) with ESMTPS id 50792182FCB for ; Mon, 06 Apr 2026 22:45:50 +0200 (CEST) Received: (qmail 9577 invoked by uid 989); 6 Apr 2026 20:45:50 -0000 Received: from unknown (HELO unkown) (::1) by farbauti.uberspace.de (Haraka/3.1.1) with ESMTPSA; Mon, 06 Apr 2026 22:45:49 +0200 Message-ID: <283ccf28-c0ca-4ba5-9c5b-c4215a2fa0cf@murch.one> Date: Mon, 6 Apr 2026 13:45:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [bitcoindev] [BIP Draft] Dust UTXO Disposal Protocol To: STEVEN SLATER Cc: bitcoindev@googlegroups.com References: <3b3328b8-bba4-4858-b53a-0e9b631044ffn@googlegroups.com> <5028df3d-22ec-4a3e-9b54-64a4f1f0cefc@murch.one> Content-Language: en-US From: Murch In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: --- X-Rspamd-Report: BAYES_HAM(-2.999748) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) X-Rspamd-Score: -3.089748 X-Original-Sender: murch@murch.one X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=tR0MMfmk; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one 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.8 (/) Hi Steven, Thanks for the quick reply, looking forward to reading the updated document= ! I just realized that I forgot another point in my prior email. While=20 there are some other node implementations that still implement BIP=E2=80=AF= 125:=20 Opt-in Full Replace-by-Fee Signaling, Bitcoin Core 28.0 and later will=20 accept replacements even if the original transaction did not signal=20 replaceability=C2=B9, so you could consider dropping the replaceability=20 signal requirement. While the dust disposal transactions will be quite=20 distinguishable either way and it=E2=80=99s unlikely to be a big deal if th= ey=20 were to continue signaling in the future, it may be more forward-looking=20 not to signal. =C2=B9 E.g., see the linked news items regarding `mempoolfullrbf` on https://bitcoinops.org/en/topics/replace-by-fee/ for details Cheers, Murch On 2026-04-06 11:11, STEVEN SLATER wrote: > Response to Feedback on Transaction Aggregation Proposal >=20 > Hi Murch, >=20 > Thank you for taking the time to review my proposal and for raising=20 > these thoughtful points. >=20 > On the question of requiring an ash-output: I did consider the idea of=20 > mandating it universally. The main trade-off is between simplicity in=20 > aggregation and the overhead cost. A fixed 3=E2=80=91byte addition per=20 > transaction is relatively small, but when scaled across high=E2=80=91volu= me=20 > usage it does introduce measurable bloat. My current rationale was to=20 > avoid imposing that cost on transactions that are unlikely to benefit=20 > from aggregation. That said, I agree that in scenarios where feerates=20 > fluctuate significantly and dust transactions linger in the mempool, a=20 > standardized ash-output could make collapsing transactions more=20 > predictable and efficient. I=E2=80=99ll expand the rationale to weigh the= =20 > benefits of guaranteed collapsibility against the marginal overhead, and= =20 > outline conditions where the overhead is justified. >=20 > Regarding incompatible outputs: you=E2=80=99re right that independent=20 > submissions with conflicting outputs cannot be aggregated. My intent was= =20 > to highlight that aggregation works best when inputs are aligned, and=20 > that ash-output could serve as a safeguard to preserve compatibility.=20 > I=E2=80=99ll clarify this point further in the next revision. >=20 > Thank you also for the correction on feerate policy backports to Bitcoin= =20 > Core 29.1 and 28.3. I=E2=80=99ll update the proposal to reflect that user= s on=20 > those branches will indeed propagate sub=E2=80=91sat transactions. >=20 > I appreciate your constructive feedbackit helps sharpen the rationale=20 > and ensures the proposal is practical for broader adoption. I=E2=80=99ll= =20 > incorporate these clarifications before submission. >=20 > Best regards, > Steven >=20 > On Mon, 6 Apr 2026, 5:26=E2=80=AFpm Murch, wrote: >=20 > Hi bubb1es, >=20 > I just skimmed your proposal and was considering the impact of the tw= o > possible output variants. As you mention in the description of the te= st > cases, adding more inputs to a transaction would retain the output of > the first transaction that appeared on the network. However, if two > users independently submit transactions with incompatible outputs, > third > parties would not be able to aggregate those transactions into a sing= le > transaction. >=20 > I was wondering whether you considered generally requiring the > ash-output to ensure that transactions can always be collapsed. This > may > especially be attractive if feerates will be more dynamic in the futu= re > and dust disposal transactions linger in the mempool for a while. >=20 > It probably comes down to how heavily this scheme will be used > whether a > general 3-byte overhead is justifiable to simplify aggregation. Eithe= r > way, perhaps you could expound a bit on that trade-off in your > rationale. >=20 > Also, minor correction: the feerate policy change was backported to > Bitcoin Core 29.1 and Bitcoin Core 28.3, so users running the latest > releases of those major branches would also propagate sub-sat > transactions. >=20 > Otherwise, this proposal looks reasonable to me. Looking forward to > your > submission. >=20 > Cheers, > Murch >=20 > On 2026-03-30 11:34, 'bubb1es' via Bitcoin Development Mailing List > wrote: > > > > Hi, based on a topic I started on Delving delvingbitcoin.org/t/ > > disposing-of-dust-attack-utxos/2215> I'd like to gather feedback > from > > this community for a BIP to standardize disposing of dust UTXOs by > > spending their values to the fee of single OP_RETURN output > transactions. > > > > Thanks in advance for taking your time to consider this proposal. > > > > ``` > > BIP: ? > > Layer: Applications > > Title: Dust UTXO Disposal Protocol > > Authors: bubb1es = > > > harris > > > Status: Draft > > Type: Specification > > Assigned: ? > > License: CC0-1.0 > > Discussion: 2026-01-25: https://delvingbitcoin.org/t/disposing- > of-dust- > > attack-utxos/2215 > > Version: 0.1.0 > > ``` > > > > ## Abstract > > > > This BIP specifies a standardized protocol for safely disposing > of dust > > UTXOs by spending them to an OP_RETURN output with the entire valu= e > > going to transaction fees. The protocol enables wallet software to > > remove unwanted small-value UTXOs, particularly those received in > dust > > attacks, without creating new address linkages or degrading user > > privacy. The specification includes transaction format requirement= s, > > signature conventions enabling third-party batching, and validatio= n > > rules for compliant implementations. > > > > ## Motivation > > > > ### The Dust Attack Problem > > > > Dust attacks are a well-documented privacy threat where attackers > send > > small amounts of bitcoin to numerous addresses. When wallet softwa= re > > later consolidates these dust UTXOs with non-dust UTXOs, the > attacker > > can analyze the blockchain to link previously unassociated > addresses, > > potentially deanonymizing users. > > > > The common solution to this issue is to "lock" dust UTXOs and neve= r > > spend them, but this creates its own problems: > > > > 1. **UTXO Set Bloat**: Unspent dust permanently occupies space in > the > > UTXO set that all full nodes must maintain. > > 2. **Wallet Clutter**: Accumulated dust degrades wallet usability > and > > complicates coin selection. > > 3. **Accidental Consolidation**: Users may inadvertently spend dus= t > > during legitimate transactions, achieving the attacker's goal. > > 4. **Lock Fragility**: Wallet software that "locks" dust UTXOs to > > prevent spending provides only temporary protection; wallet > migrations, > > restores from seed phrases, software bugs, or inheritance > scenarios can > > inadvertently unlock dust, exposing users to the original attack. > > > > ### Why OP_RETURN Disposal > > > > Spending dust to an OP_RETURN output with the entire value going > to fees > > provides several benefits: > > > > 1. **No New UTXOs**: OP_RETURN outputs are provably unspendable > and not > > stored in the UTXO set. > > 2. **No Address Linking**: Without a change output, there is no ne= w > > address to link. > > 3. **Permanent Removal**: The dust UTXOs are removed from the user= 's > > wallet entirely. > > 4. **Miner Compensation**: OP_RETURN outputs are small, providing > higher > > transaction fee rates. > > 5. **No Cost to Victims**: Dust attack UTXO values are used to > pay for > > their own disposal. > > > > ### Why Standardization > > > > A standardized protocol enables: > > > > 1. **Wallet Anonymity**: Transactions with a standard format > cannot be > > used to fingerprint the wallet software a user is running. > > 2. **Third-Party Batching**: Multiple dust disposals can be combin= ed > > into single transactions, reducing overall block space consumption= . > > 3. **Best Practice Codification**: Ensures implementations follow > > privacy-preserving best practices. > > 4. **Easy Identification**: Chain analysis tools can use disposal > > transactions to help trace the sources of dust attacks. > > > > ## Specification > > > > ### Transaction Format > > > > A compliant dust disposal transaction MUST satisfy all the followi= ng > > requirements: > > > > #### Overall > > > > 1. The transaction MUST signal RBF replaceability (nSequence < > 0xFFFFFFFE). > > 2. The ntimelock MUST be set to block height 0. > > 3. The fee rate MUST be at least 0.1 sat/vB. > > > > #### Outputs > > > > 1. The transaction MUST have exactly one output. > > 2. The single output MUST be an OP_RETURN. > > 3. The OP_RETURN data MUST be either: > > - Empty: `0x6a 0x00` (OP_RETURN OP_0), or > > - The ASCII string "ash": `0x6a 0x03 0x61 0x73 0x68` (OP_RETURN > > OP_PUSHBYTES_3 "ash"). > > > > The "ash" marker MUST be used when padding is needed to meet the > 65 vB > > minimum standard transaction size with a single witness input. > > Implementations MUST prefer empty OP_RETURN data when the > transaction > > already meets minimum size requirements. > > > > #### Inputs > > > > 1. All inputs MUST use the signature hash type `SIGHASH_ALL | > > SIGHASH_ANYONECANPAY` (0x81). > > 2. For Taproot (P2TR) inputs using key-path spending, > implementations > > MUST explicitly append the signature hash type byte `SIGHASH_ALL | > > SIGHASH_ANYONECANPAY` (0x81) to enable ANYONECANPAY semantics, as > the > > default sighash for Taproot (SIGHASH_DEFAULT, which omits the > byte) does > > not include ANYONECANPAY. > > 3. All inputs must be confirmed in the blockchain at least one > block deep. > > > > #### Fees > > > > 1. The entire input value MUST go to fees (output value is zero fo= r > > OP_RETURN). > > 2. The transaction fee rate MUST be at least 0.1 sat/vB to meet > minimum > > relay requirements (Bitcoin Core 30.0+). > > 3. The transaction fee rate MAY be higher based on the available > dust > > UTXO amounts and transaction size. > > > > ### Transaction Size > > > > 1. The transaction base size MUST be at least 65 bytes to meet > Bitcoin > > Core's minimum relay size standardness rule. > > 2. If the transaction would otherwise be smaller than 65 bytes, th= e > > OP_RETURN value "ash" as ASCII (UTF-8) bytes (0x61, 0x73, 0x68) > MUST be > > used to pad the transaction's size to 65 bytes. > > > > ### Address Consolidation Rules > > > > Implementations consolidating dust UTXOs for a single user (i.e., > not > > third-party batching services): > > > > - MUST NOT spend dust UTXOs that were sent to different addresses > in the > > same transaction. > > - MUST NOT broadcast dust disposal transactions at the same time f= or > > dust sent to different addresses. > > - SHOULD spend dust UTXOs for dust sent to the same address in one > > transaction. > > > > ### Batching Dust Disposal Transactions via RBF > > > > Multiple unconfirmed dust disposal transactions created by unrelat= ed > > entities MAY be batched into a single replacement transaction usin= g > > Replace-By-Fee (RBF). This is enabled by the inputs > SIGHASH_ANYONECANPAY > > signature type. > > > > In addition to standard RBF rules, batch dust disposal > transactions must > > follow all transaction construction requirements for non-batched > dust > > disposal transactions. > > > > #### Third-Party Batching > > > > A third-party batching service for dust disposal transactions coul= d > > compromise their users' privacy by collecting user-related > network and > > timing metadata. The best practice for these services is: > > > > 1. The service MUST NOT collect pre-signed inputs directly from > wallet > > users. > > 2. The service SHOULD collect pre-signed inputs from the public > bitcoin > > network mempool. > > 3. The service MAY add their own UTXO inputs to improve the batch > > transaction's fee rate as long as all the requirements of this > > specification are still followed. > > > > This mempool-based approach preserves user privacy while enabling > > efficient batching: > > > > 1. Users broadcast their individual dust disposal transactions to > the > > network. > > 2. Batching services monitor the mempool for compliant dust dispos= al > > transactions. > > 3. Services can combine unconfirmed transactions via RBF without > knowing > > user identities. > > > > ### Dust Threshold > > > > Implementations SHOULD allow users to configure their own dust > threshold > > based on: > > > > 1. The current and anticipated fee rates. > > 2. The dust input script type, different types have different > spending > > costs. > > 3. The varying amounts that may be used by dust attack initiators. > > > > A UTXO is generally considered dust if its value is less than the > cost > > to spend it at a reasonable fee rate, but any small UTXO value > could be > > used in a dust attack. > > > > ### Security Considerations > > > > #### Transaction Signing > > > > 1. **Key Security**: Signing dust disposal transactions requires > signing > > with the user's wallet private keys. This could be a risk for cold > > storage wallets where the key or keys needed to sign are not easil= y > > accessible. > > 2. **Transaction Correctness**: Transaction signers must carefully > > review and verify that only dust UTXOs are spent and no other > inputs are > > signed. > > > > #### Privacy Preservation > > > > 1. **Network surveillance**: Internet service providers and other > > internet monitors may be able to determine the nodes that initiall= y > > broadcast a dust disposal transaction. If available the > > `sendrawtransaction -privatebroadcast` RPC feature should be used > > (available in [Bitcoin Core 31.0](https://github.com/bitcoin- > core/ > > bitcoin-devwiki/wiki/31.0-Release-Notes-Draft#p2p-and-network- > changes)). > > 2. **Timing Analysis**: Users should be aware that the timing of > dust > > disposal transactions is publicly observable. Dust disposal > transactions > > should not be broadcast at the same time or on a predictable > schedule. > > 3. **Amount Analysis**: The specific dust amounts selected for dus= t > > disposal if outside the norm may be used to fingerprint the wallet > > creating the disposal transactions. > > > > ## Rationale > > > > ### Why Empty or "ash" OP_RETURN Data? > > > > 1. **Minimal Size**: Empty data (2 bytes: OP_RETURN OP_0) > minimizes the > > transaction size. > > 2. **Standardization**: Consistent transaction construction > eliminates > > wallet fingerprinting. > > 3. **Padding Option**: The "ash" string (5 bytes: OP_RETURN > > OP_PUSHBYTES_3 "ash") provides a standardized way to meet the > minimum > > transaction size; e.g., for a single P2TR dust input. > > 4. **Semantic Meaning**: The word "ash" metaphorically represents > the > > result of "burning" the dust. > > > > ### Why Per-Address Transactions? > > > > Consolidating dust from multiple addresses for the same wallet > creates > > the same privacy harm that dust attacks attempt to achieve. By > requiring > > wallet software to create separate transactions per address (by > > default), the protocol ensures dust disposal doesn't harm privacy. > > > > ### Why 65 Byte Minimum? > > > > Bitcoin Core enforces a minimum transaction base size of 65 bytes > as a > > policy rule to prevent certain attack vectors. Compliant > transactions > > must meet this threshold to be relayed by standard nodes. > > > > ### Why 0.1 sat/vB Minimum Fee Rate? > > > > [Bitcoin Core 30.0](https://bitcoincore.org/en/releases/30.0/ > ) reduced > > the minimum relay fee rate to 0.1 sat/vB (1 sat/kvB). This allows > dust > > UTXOs to be disposed of economically even when their value is very > > small. Implementations targeting earlier node versions may need > higher > > minimum fee rates. > > > > ### Why SIGHASH_ALL|ANYONECANPAY? > > > > The ANYONECANPAY flag allows additional inputs to be added to the > dust > > disposal transaction after signing. This provides several benefits= : > > > > 1. **Batching**: Unrelated dust disposal transactions can be > found in > > the mempool and batched together via RBF. > > 2. **User privacy**: Transactions shared via the public mempool > do not > > reveal user identity metadata. > > 3. **Fee Bumping**: Additional inputs can be added by unrelated > third > > parties to increase the fee rate. > > > > ### Why nLockTime block height 0 > > > > 1. **User privacy**: Using the same nLockTime for all dust disposa= l > > transactions obscures when it was created. > > 2. **Fee sniping**: The value of disposal transactions should be > small > > enough that fee sniping is not a concern. > > > > ## Backwards Compatibility > > > > This BIP introduces no changes to the Bitcoin consensus rules or > peer- > > to-peer protocol. All transactions conforming to this > specification are > > valid under existing consensus rules and can be relayed by nodes > supporting: > > > > - OP_RETURN outputs (Bitcoin Core 0.9.0+) > > - SIGHASH_ANYONECANPAY (original Bitcoin feature) > > - 0.1 sat/vB minimum relay fee (Bitcoin Core 30.0+) > > - Private transaction broadcast (Bitcoin Core 31.0+) > > > > Nodes running Bitcoin Core versions prior to 30.0 do not relay > > transactions with fee rates below 1 sat/vB which could slow the > relaying > > of disposal transactions with lower fee rates. > > > > ## Reference Implementation > > > > A reference implementation is available at: https://github.com/ > > > bubb1es71/ddust > > > > The implementation provides: > > - Command-line tool for creating dust disposal transactions > > - Automatic dust detection based on configurable thresholds > > - Transaction batching via RBF > > - Support for P2PKH, P2SH, P2WPKH, P2WSH, and P2TR input descripto= rs > > - Integration with Bitcoin Core (version 30.0+) via RPC for > syncing and > > broadcasting transactions > > > > ## Test Cases > > > > The test cases below can be used to verify a wallet disposes of du= st > > UTXOs according to the specification in this BIP. > > > > ### List dust > > > > 1. Create payment addresses for multiple address types, send dust > and > > non-dust amounts to these addresses, verify that listing dust only > > returns UTXOs at or below the configured dust threshold (e.g. > 1000 sats). > > 2. Create confirmed and unconfirmed dust UTXOs in the test wallet, > > verify listing dust only returns the confirmed dust UTXOs. > > > > ### Spending dust > > > > All valid dust disposal transactions should be verified to be > accepted > > into the bitcoind (Bitcoin Core 30.0+) mempool. > > > > 1. Spending a single witness (Bech32m/P2TR) dust UTXO must produce= a > > dust disposal transaction with a single "ash" OP_RETURN output. > > 2. Spending multiple dust UTXOs always produces a single empty > OP_RETURN > > output regardless of script type. > > 3. Spending a single 2-of-2 P2SH multisig dust UTXO produces a > single > > empty OP_RETURN output. > > 4. All dust UTXOs sent to the same address are disposed of in the > same > > transaction. > > 5. Dust disposal transactions only include confirmed dust UTXOs. > > > > #### Example dust disposal transaction sizes > > > > | | P2PKH | P2SH (2-3) | P2WPKH | P2WSH (2-3) | P2TR | > > > |-------------------|-------|------------|--------|-------------|----= ---| > > | Overhead (b) | 10 | 10 | 10 | 10 | 10 | > > | Input (b) | 148 | 295 | 41 | 41 | 41 | > > | OP_RETURN (b) | 11 | 11 | 14 | 14 | 14 | > > | Base size (b) | 169 | 316 | 65 | 65 | 65 | > > | Witness data (b) | 0 | 0 | 108 | 255 | 67 | > > | Size (b) | 169 | 316 | 173 | 320 | 132 | > > | Weight (wu) | 676 | 1264 | 370 | 517 | 329 | > > | Virtual Size (vb) | 169 | 316 | 92.5 | 129.25 | 82.25 | > > > > #### Example dust disposal transaction fee rates (sats/vb) > > > > | Input Amount | P2PKH | P2SH (2-3) | P2WPKH | P2WSH (2-3) | P2TR = | > > > |--------------|---------|------------|--------|-------------|-------= | > > | 294 | 1.74 | 0.93 | 3.18 | 2.27 | 3.57 | > > | 300 | 1.78 | 0.95 | 3.24 | 2.32 | 3.65 | > > | 325 | 1.92 | 1.03 | 3.51 | 2.51 | 3.95 | > > | 330 | 1.95 | 1.04 | 3.57 | 2.55 | 4.01 | > > > > ### Batching dust disposal txs via RBF > > > > 1. Adding a Bech32m dust input to an unconfirmed disposal > transaction > > with a legacy dust input keeps the original single empty > OP_RETURN output. > > 2. Adding a Bech32m dust input to an unconfirmed disposal > transaction > > with a Bech32m dust input keeps the original single "ash" > OP_RETURN output. > > 3. Adding a new dust input to an unconfirmed disposal transaction > > results in a new batch disposal transaction with a fee rate > sufficient > > for RBF. > > 4. A new dust input that contributes an insufficient fee rate for > RBF > > with an existing unconfirmed disposal transaction is not batched > with it. > > > > ## Related work > > > > * "dust-b-gone": https://github.com/petertodd/dust-b-gone > > > * "dusts": https://github.com/bubb1es71/dusts github.com/bubb1es71/dusts> > > > > ## Changelog > > > > * **0.1.0** (2026-03-22): > > * Initial draft of the BIP. > > > > ## Copyright > > > > > > This document is licensed under the Creative Commons CC0 1.0 > Universal > > license. > > > > -- > > 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/3b3328b8-bba4-4858- > b53a-0e9b631044ffn%40googlegroups.com > > > > b53a-0e9b631044ffn%40googlegroups.com? > utm_medium=3Demail&utm_source=3Dfooter utm_medium=3Demail&utm_source=3Dfooter>>. >=20 > --=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 email to bitcoindev+unsubscribe@googlegroups.com > . > To view this discussion visit https://groups.google.com/d/msgid/ > bitcoindev/5028df3d-22ec-4a3e-9b54-64a4f1f0cefc%40murch.one > bitcoindev/5028df3d-22ec-4a3e-9b54-64a4f1f0cefc%40murch.one>. >=20 --=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/= 283ccf28-c0ca-4ba5-9c5b-c4215a2fa0cf%40murch.one.