From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 16 Apr 2026 15:05:55 -0700 Received: from mail-ot1-f56.google.com ([209.85.210.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wDUqQ-0004GZ-5E for bitcoindev@gnusha.org; Thu, 16 Apr 2026 15:05:55 -0700 Received: by mail-ot1-f56.google.com with SMTP id 46e09a7af769-7dbb4f8b314sf216208a34.3 for ; Thu, 16 Apr 2026 15:05:53 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776377148; cv=pass; d=google.com; s=arc-20240605; b=S61hDFKaH9pZLu97e6hkzsK00zFPI8AfrXowRZavqHd55vo1kFDHFiaObEd16IlFW9 TBU6XgcnhOp27DhocOfUBY/e8/joak2k9OhJTS3oqzQCTa179pJv84+qFJpKzdA0Djw9 YSX4HXuyW2dixwm6njeb27sJHqCbRk9prbzRFHIfJwLEHbDVxkJH1ap35Glb7CMaFUOl hVKF7rgLKl+UNkvFjwW2VtE13bL8WRWzMBbmp+iZJk9FVghwuZsdeW4tHFSqZYqRCmfT nVcNpaOaA8tlAi0LUnjEL6JkB1A3pdRotVTeVVyipytJ4fuHzvj+dptk/KsEpr+2mHm6 q5CQ== 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:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=KEPlzG2/aGClR5jp24JivJZazH/sj3+RBnZMFPvtiCI=; fh=b3FMJWBWS6GuneLbwsFfCrIAYWYWK9E6O70XmrB1cLE=; b=iKHTjExvtWjsbkeiMAD8hQYBESU65Xa2qMs8/GALjRSKdVwJbdNyknc9MMSOjtxei7 4g8R8mKnnYt6HKRc4BHZcRJ6rgf/3+Sf1F6uGFYwFe40aQVJgoD71O1WTgEKPEJ+hPJr Dz1w0H8d8fnrWEMZsIHF9Axx0lcJ19xu4NmYL4VxVVntuuvreurkSKJZJXlQWLeH9zQs yF7UYOi30eY2JCHLZ/oLWkZ2oS+1ZvrUozL0ubCLDv4sxk0TuWRKonkP3i53N4L5QKtY SF4Eq4IQG8GLz995R0+ydb53QuzenwjYWgirzVaERW1HBmgFWcYbc0KdRH4EZp4xzC/g oRCA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=rpwjpoxyrrca7hpm4lpczymmvu.protonmail header.b="JXcVKqe/"; spf=pass (google.com: domain of bubb1es71@proton.me designates 79.135.106.98 as permitted sender) smtp.mailfrom=bubb1es71@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776377148; x=1776981948; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=KEPlzG2/aGClR5jp24JivJZazH/sj3+RBnZMFPvtiCI=; b=D01b60XB0WbYeKfTAG6yvEhZEmXJBhVkUri4zKIW1HKOxM63R5gn8wOyTZA9tLxTfC V372qF/oRg05/YblR5ZC4Gk6vqja9c/KWs4Mknu9awkhI9ZVjLTA7JEq1fwB+Ohuh/cb kpYoyeUb1Y31Ecf+JHj5tmPEJOQALd8zO5IxlixkkiV7c6Rycl3ke+jv70v+04/EbBVy 3sTt0ANbTxhWsr/oRYBV/0UlzgJiTb1RaBeJrlCZyNn61zRSmBFz/cJiicJGiwVUBbZU OYscR8UwDW++8xNY454oUAQVyWYqORKui5f59dcN1nGxDRqy5Kxa2OW85in7xSvQeuHP lROA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776377148; x=1776981948; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KEPlzG2/aGClR5jp24JivJZazH/sj3+RBnZMFPvtiCI=; b=PrdkJhKo6mTH6f3g2oKkTrJj4USNCOSH5BmhtLE0xkdxy4VkbajFGzgLOt9Rvf5TEi jYhElzgSCVnuillNP1UC0PFny0fAt5EBr3ggRUR/7PIDuo7iYEBmAQx1aW3WCbuB9RIN j4fIfTJC8v0t1qnKTY3iMjzHpBWSruUI6P/1uCH8/j7MQCkb2rz7oxzG/myUqoIqYmBH +KsQpZstnTedgUR62CiMmZPc8f/wVNiwoeyELJ8+m8P5uVVvVCqT4XWntqHPd3jFZEAC 49IfyVEKxdRo37g0XfEtrl9iA3ud7uujA/dQ80EwONamkIHw/cTNRPh26SEX/5lFMQdx v3gg== X-Forwarded-Encrypted: i=2; AFNElJ/VUAYrT1/pm9IGIBcFoJ+xNiyNabR4UI/EyoYkjL9SO5OmhogEgiZOKsEvFTsScKPXgk0dMapvQOYi@gnusha.org X-Gm-Message-State: AOJu0YxHQwqVn0zm3LyKIlrHPRWzFUvyRjlwDCsfPoLBOyf1iBixhOpR qpZpQ/bCzuhrmOX41HgF1tyU7zplLB2EMEMkld2ryhlnESQcTmMrPBOb X-Received: by 2002:a05:6820:2223:b0:67e:2aa4:ce1d with SMTP id 006d021491bc7-69462f30d23mr258268eaf.54.1776377147777; Thu, 16 Apr 2026 15:05:47 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiI05NkkICBnbU+G9xvACiHkeVFcnGb4HHtXwrBXPso82w==" Received: by 2002:a05:6820:168a:b0:681:a657:932f with SMTP id 006d021491bc7-6943c0f2fe2ls721283eaf.1.-pod-prod-09-us; Thu, 16 Apr 2026 15:05:42 -0700 (PDT) X-Received: by 2002:a05:6808:d54:b0:475:be6f:aa with SMTP id 5614622812f47-4799c86da74mr44635b6e.19.1776377142550; Thu, 16 Apr 2026 15:05:42 -0700 (PDT) Received: by 2002:aa7:c6da:0:b0:670:7127:5bd3 with SMTP id 4fb4d7f45d1cf-672c1aa3ff4msa12; Thu, 16 Apr 2026 15:02:23 -0700 (PDT) X-Received: by 2002:a05:6402:2b9b:b0:670:8b30:a8a7 with SMTP id 4fb4d7f45d1cf-672bfc12ae6mr208104a12.0.1776376942587; Thu, 16 Apr 2026 15:02:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776376942; cv=none; d=google.com; s=arc-20240605; b=iDmn8NUO6otmHKLWOaDPcaIaJ6klMzpIRs6EZVcMtveTscZMVcZ+bYCarAHsMlcwxL lQZmEm9Ebb4I4kAIalCpFzIrY0q0YBpu60s1dEuX9lr/k7B+vkcl++LM8qHrjpVILT6w 4qDsjEE7xtSDh9DBqUNO/Uefccr/9END5n/TsVXLwf8OsO4abiU4zZ07mTwUwjnXYY1R 7jXgZRRsIju3a8KRbTZWjyNqebZCBQUusfsOuLn3RAlmXoM/PccObHVNgGFE52T1jBNR E9qhEvaImpd9tASMGK/GeuW5Isxbu1XTQm6r8pAYTGbMvUApf8tAN+F9ikR/8RtWYsFK urcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=Vx+yx7Hp3D+2UUKyZd0CwAjgLIaPdYCrPH8O+O7wdC4=; fh=foaZ9w3C3c5ltuXRyLrsJcSZd5F+/L4e8AHpKYxjE8o=; b=S89quI8cEW6r2UlRvneVnENsuGGynribja1qmP/ntZ3kGchXnUXfdb4UTGnBqM3yju FUp4xQ42JHnjB+58z0QH7PWYLqvSTD7sZ+ctVmx13jBmDcRwvuiIMl0msQSyeG2yMpyT mlTbMS+Mc53wSgebs87zf5rkX1Lb6eDhNCJTCRBZbwvE/f/ieXgFqVIByQE3fCcjFVkw at3w6UyAT4oPKvPvovu1+qJnj7CClIMLPYQ95EjhqH20mjNhGcG/3gXl2lG61nUhUtfg eYECsSWDnBiXg1bvXaz2Yjcbcz+4PywmkjD9W37+4FG9co2MoqDIg/6s+b9hFE5vmePI xD7w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=rpwjpoxyrrca7hpm4lpczymmvu.protonmail header.b="JXcVKqe/"; spf=pass (google.com: domain of bubb1es71@proton.me designates 79.135.106.98 as permitted sender) smtp.mailfrom=bubb1es71@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10698.protonmail.ch (mail-10698.protonmail.ch. [79.135.106.98]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-67237cf6e13si126158a12.0.2026.04.16.15.02.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2026 15:02:22 -0700 (PDT) Received-SPF: pass (google.com: domain of bubb1es71@proton.me designates 79.135.106.98 as permitted sender) client-ip=79.135.106.98; Date: Thu, 16 Apr 2026 22:02:15 +0000 To: Murch From: "'bubb1es' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] [BIP Draft] Dust UTXO Disposal Protocol Message-ID: In-Reply-To: <4c3bb222-c492-4eb2-af98-68bee09ec5cd@murch.one> References: <3b3328b8-bba4-4858-b53a-0e9b631044ffn@googlegroups.com> <5028df3d-22ec-4a3e-9b54-64a4f1f0cefc@murch.one> <4c3bb222-c492-4eb2-af98-68bee09ec5cd@murch.one> Feedback-ID: 172960010:user:proton X-Pm-Message-ID: c33c935857681327aff4ec99850edb7b8980225b MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: bubb1es71@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=rpwjpoxyrrca7hpm4lpczymmvu.protonmail header.b="JXcVKqe/"; spf=pass (google.com: domain of bubb1es71@proton.me designates 79.135.106.98 as permitted sender) smtp.mailfrom=bubb1es71@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: bubb1es Reply-To: bubb1es 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: -1.0 (-) Hi Murch, thanks for explaining the sighash issue. I understand better now = that a RBF free-for-all caused by signing dust inputs with `NONE|ANYONECANP= AY` is very undesirable in terms of tx relay bandwidth and mempool processi= ng. I've changes our draft BIP spec and reference `ddust` tool back to requ= ire the `ALL|ANYONECANPAY` sighash type. (https://github.com/bubb1es71/ddus= t/pull/31). Next harris is updating the batching spec to select and order dust inputs i= n a more deterministic way. He's also updating the `ddust` tool batching a= nd adding tests to follow the updated spec and make sure it follows all the= RBF rules. =20 Sent with Proton Mail secure email. On Wednesday, April 15th, 2026 at 2:55 AM, Murch wrote: > Hi bubb1les, >=20 > Sorry, I thought Steven might be another co-author or an accidental=20 > reply from a diffierent email account by you. Thanks for clarifying. >=20 > At recent feerates of 0.12=E2=80=930.15=E2=80=AFs/vB, e.g., a P2TR keypat= h-spend input=20 > only costs 6=E2=80=939 sats, but with the P2TR dust limit being defined= =20 > traditionally as 330=E2=80=AFsats, a P2TR keypath-spend could pay for its= elf at=20 > feerates of up to ~5.72=E2=80=AFs/vB. >=20 > Using `NONE|ANYONECANPAY` sighash flags would mean that any sender that= =20 > sees a transaction with the inputs could try to use them to fund their=20 > own transactions for free. With the new incremental relay feerate of=20 > 0.1=E2=80=AFs/vB, this could lead to quite a few replacements and conflic= ting=20 > transactions before any one of them were to get confirmed. Using=20 > `ALL|ANYONECANPAY` would only allow aggregating inputs that commit to=20 > the same dust destruction output script which prevents this potential=20 > bandwidth wasting competition vector. >=20 > Cheers, > Murch >=20 > On 2026-04-09 19:14, bubb1es wrote: > > Hi Murch, since posting we've had some constructive discussion on the D= elving thread with nothingmuch (https://delvingbitcoin.org/t/disposing-of-d= ust-attack-utxos/2215/21). He suggested using the "NONE|ANYONECANPAY" sigha= sh flags instead of "ALL|ANYONECANPAY" as we originally proposed. > > > > > > This change would allow batched dust transactions to replace an unneces= sary OP_RETURN "ash" output with an empty OP_RETURN. I don't see any downsi= de to doing this so I've updated the proposed draft BIP. > > > > I've also updated the draft BIP with your corrections regarding the ver= sions of Bitcoin Core with the new feerate policy. > > > > Thank you for your review and encouragement! We hope to submit it for r= eview soon. > > > > PS. I do not know who " thugm501@gmail.com" is and he ha= s not made any contributions to this project. > > > > On Monday, April 6th, 2026 at 11:26 AM, Murch wrote: > > > >> Hi bubb1es, > >> > >> I just skimmed your proposal and was considering the impact of the two > >> possible output variants. As you mention in the description of the tes= t > >> 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, thi= rd > >> parties would not be able to aggregate those transactions into a singl= e > >> transaction. > >> > >> I was wondering whether you considered generally requiring the > >> ash-output to ensure that transactions can always be collapsed. This m= ay > >> especially be attractive if feerates will be more dynamic in the futur= e > >> and dust disposal transactions linger in the mempool for a while. > >> > >> It probably comes down to how heavily this scheme will be used whether= a > >> general 3-byte overhead is justifiable to simplify aggregation. Either > >> way, perhaps you could expound a bit on that trade-off in your rationa= le. > >> > >> 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 transact= ions. > >> > >> Otherwise, this proposal looks reasonable to me. Looking forward to yo= ur > >> submission. > >> > >> Cheers, > >> Murch > >> > >> On 2026-03-30 11:34, 'bubb1es' via Bitcoin Development Mailing List wr= ote: > >>> Hi, based on a topic I started on Delving >>> 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 transacti= ons. > >>> > >>> 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-dus= t- > >>> attack-utxos/2215 > >>> Version: 0.1.0 > >>> ``` > >>> > >>> ## Abstract > >>> > >>> This BIP specifies a standardized protocol for safely disposing of du= st > >>> UTXOs by spending them to an OP_RETURN output with the entire value > >>> going to transaction fees. The protocol enables wallet software to > >>> remove unwanted small-value UTXOs, particularly those received in dus= t > >>> attacks, without creating new address linkages or degrading user > >>> privacy. The specification includes transaction format requirements, > >>> signature conventions enabling third-party batching, and validation > >>> rules for compliant implementations. > >>> > >>> ## Motivation > >>> > >>> ### The Dust Attack Problem > >>> > >>> Dust attacks are a well-documented privacy threat where attackers sen= d > >>> small amounts of bitcoin to numerous addresses. When wallet software > >>> 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 never > >>> 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 dust > >>> 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 migration= s, > >>> restores from seed phrases, software bugs, or inheritance scenarios c= an > >>> 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 f= ees > >>> provides several benefits: > >>> > >>> 1. **No New UTXOs**: OP_RETURN outputs are provably unspendable and n= ot > >>> stored in the UTXO set. > >>> 2. **No Address Linking**: Without a change output, there is no new > >>> 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 hig= her > >>> transaction fee rates. > >>> 5. **No Cost to Victims**: Dust attack UTXO values are used to pay fo= r > >>> their own disposal. > >>> > >>> ### Why Standardization > >>> > >>> A standardized protocol enables: > >>> > >>> 1. **Wallet Anonymity**: Transactions with a standard format cannot b= e > >>> used to fingerprint the wallet software a user is running. > >>> 2. **Third-Party Batching**: Multiple dust disposals can be combined > >>> 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 following > >>> requirements: > >>> > >>> #### Overall > >>> > >>> 1. The transaction MUST signal RBF replaceability (nSequence < 0xFFFF= FFFE). > >>> 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 v= B > >>> 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) d= oes > >>> 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 for > >>> OP_RETURN). > >>> 2. The transaction fee rate MUST be at least 0.1 sat/vB to meet minim= um > >>> 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 Bitcoi= n > >>> Core's minimum relay size standardness rule. > >>> 2. If the transaction would otherwise be smaller than 65 bytes, the > >>> 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 for > >>> 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 unrelated > >>> entities MAY be batched into a single replacement transaction using > >>> Replace-By-Fee (RBF). This is enabled by the inputs SIGHASH_ANYONECAN= PAY > >>> signature type. > >>> > >>> In addition to standard RBF rules, batch dust disposal transactions m= ust > >>> follow all transaction construction requirements for non-batched dust > >>> disposal transactions. > >>> > >>> #### Third-Party Batching > >>> > >>> A third-party batching service for dust disposal transactions could > >>> compromise their users' privacy by collecting user-related network an= d > >>> timing metadata. The best practice for these services is: > >>> > >>> 1. The service MUST NOT collect pre-signed inputs directly from walle= t > >>> users. > >>> 2. The service SHOULD collect pre-signed inputs from the public bitco= in > >>> 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 disposal > >>> transactions. > >>> 3. Services can combine unconfirmed transactions via RBF without know= ing > >>> user identities. > >>> > >>> ### Dust Threshold > >>> > >>> Implementations SHOULD allow users to configure their own dust thresh= old > >>> based on: > >>> > >>> 1. The current and anticipated fee rates. > >>> 2. The dust input script type, different types have different spendin= g > >>> 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 cos= t > >>> 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 sign= ing > >>> 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 easily > >>> 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 initially > >>> 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 transacti= ons > >>> should not be broadcast at the same time or on a predictable schedule= . > >>> 3. **Amount Analysis**: The specific dust amounts selected for dust > >>> 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 t= he > >>> transaction size. > >>> 2. **Standardization**: Consistent transaction construction eliminate= s > >>> 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 create= s > >>> the same privacy harm that dust attacks attempt to achieve. By requir= ing > >>> 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/) reduce= d > >>> the minimum relay fee rate to 0.1 sat/vB (1 sat/kvB). This allows dus= t > >>> UTXOs to be disposed of economically even when their value is very > >>> small. Implementations targeting earlier node versions may need highe= r > >>> minimum fee rates. > >>> > >>> ### Why SIGHASH_ALL|ANYONECANPAY? > >>> > >>> The ANYONECANPAY flag allows additional inputs to be added to the dus= t > >>> 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 no= t > >>> 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 disposal > >>> transactions obscures when it was created. > >>> 2. **Fee sniping**: The value of disposal transactions should be smal= l > >>> 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 a= re > >>> valid under existing consensus rules and can be relayed by nodes supp= orting: > >>> > >>> - 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 relay= ing > >>> 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 descriptors > >>> - Integration with Bitcoin Core (version 30.0+) via RPC for syncing a= nd > >>> broadcasting transactions > >>> > >>> ## Test Cases > >>> > >>> The test cases below can be used to verify a wallet disposes of dust > >>> 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 sa= ts). > >>> 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 accepte= d > >>> 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_RET= URN > >>> 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 sam= e > >>> 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 ou= tput. > >>> 2. Adding a Bech32m dust input to an unconfirmed disposal transaction > >>> with a Bech32m dust input keeps the original single "ash" OP_RETURN o= utput. > >>> 3. Adding a new dust input to an unconfirmed disposal transaction > >>> results in a new batch disposal transaction with a fee rate sufficien= t > >>> 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 > >>> > >>> ## Changelog > >>> > >>> * **0.1.0** (2026-03-22): > >>> * Initial draft of the BIP. > >>> > >>> ## Copyright > >>> > >>> > >>> This document is licensed under the Creative Commons CC0 1.0 Universa= l > >>> 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, sen= d > >>> 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>. > >> -- > >> You received this message because you are subscribed to the Google Gro= ups "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/bitcoi= ndev/5028df3d-22ec-4a3e-9b54-64a4f1f0cefc%40murch.one. > >> >=20 > --=20 > You received this message because you are subscribed to a topic in the Go= ogle Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/b= itcoindev/pr1z3_j8vTc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to bitco= indev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/4c3bb222-c492-4eb2-af98-68bee09ec5cd%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/= ORIGIO060hH_CrtpqpBQ_WLqZJ2xE41K17-P11n2aUsCpGDqhim0om_kz_rJ2oMjlzmPUt84YlR= Hsvcj1LJAtXQe_FlS0p_SW0Khm5LTN1Y%3D%40proton.me.