From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 09 Apr 2026 20:13:29 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wB2JD-0007QT-EG for bitcoindev@gnusha.org; Thu, 09 Apr 2026 20:13:28 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-415e1e9aa5dsf2339612fac.0 for ; Thu, 09 Apr 2026 20:13:26 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775790801; cv=pass; d=google.com; s=arc-20240605; b=EPCpN8rYLWom2661K8E0mskZK69lbqA1St1YIRAHgIAaxmXDfFdy26N9sZMtPClHGi L88VpdkBb/mCxZxGdx475Vtvj+l3Xm50Uzwjm+soYmeKliM9Q0bjK402Ugi42WYgKA10 ENsyn0Q13mhuShrU5Gtu7bWfzfdfBhhJgY/cJt5QvzmEzj+DofGmjV+0CODvIhXAkhnr GiPCq+/Dyqzrfjvwbp7iYcLS1CODip1b25b88n1c4EkUCtHVnCOBTsrwldJos60DmZ15 tAhHxSzGur+NNsyfyC+if3NhTeedSZ12bMYJChooV2bkCfD6WBfDvTPqh1l2GKx+sk1L DgbA== 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=WCkAX3+ycBZX+2x01+HaaabKebcWLGRiJ0bg+O5x3sw=; fh=xWnUZS2j/Ccs21rHt9Ai4tfmxUujMREx1U36DHYYBq4=; b=QtH5lO9kK3lHLMqeEbcngozIMp8r1kaEYR/FsTIavA2ifw71usokKR3UodbPw70+XG QuZjL6xHgdr9iP1KRpCAYDbF4uN7myYYkYb0JgXmUhuI/ZbPZYdIAGjAmzh5/gBgXyOl RxtLjXunC3WEj7Yk6hJZPsjjJz8CYBncbyLQ/A/FegFIpuW4SEqEHsTr8ym10Ch3grU7 pJccwNHswlLLtZ+Uep5USvmkbV4rTdgzggBzsJhGpgNeHXuhwg9Rzt9LtDfELbsGoK3Y rqsEvuQLfjwUYk5LLhK/y6B0DhvTK4VyiD/qZKT2nFEN9O7dXfwVaJpxd4FIN4EqJeTz 7Jxw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=dVBD1Fuw; spf=pass (google.com: domain of bubb1es71@proton.me designates 185.70.43.166 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=1775790801; x=1776395601; 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=WCkAX3+ycBZX+2x01+HaaabKebcWLGRiJ0bg+O5x3sw=; b=trVdpk/068wKxkpd5ksbNKS7y661C1l0Q0jTmrnPKDnUm71/FJlKDWeROjNhDWssmR x5Cf4d0PC5loQ/mDM3ti/4pXojExlPqIDsGiDuGVR7b4xz8bQaJrBuy5wPoP28Waqj79 y3PoizUj+lXxg5S3x5Wax7wwdgP/rLFHHeLIkfVjwH34ipLJlAWyDFNfhirkonzFia3h +htY4xefZxCJV64pHmdCowhyA+CTWaeELynhQRElLjlaYt9Ws+ErvP7e6pfuVx6uZLqZ 10gb5YnLBq/ZBo0i0C+MdFckXXdRnZvvr4+D9TVAF7CYZBNEkB+go70RZCQApcSKbvxF QStg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775790801; x=1776395601; 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=WCkAX3+ycBZX+2x01+HaaabKebcWLGRiJ0bg+O5x3sw=; b=ZAWp3vxS/jjVSTj/1XPkUCvZ/7iYn/egeEmJbto8VHu/YlZ4CKOVMixBoTsddvphC+ q576gfL8oN16Xkp+pXYqouWoEFzb1XzBkrnoHHnTFDkX68qQXQUjy9NezO6N8LqZn0aZ JhKfPIuU2W+5D5+QOK44nBYBu0IK0g6AxmtH9kblZWVjHcncLWLpOVaC7JuZUgyP2Lv3 8UN6edro+6nxofqV/9yUT/RGXX2LlpFtFRv+17WCsuwBbEgXfVd60XOACXXe5Bws6Mbu a7e/Qaa0yC+8jqFtqL7gEgeOzOFOgwnuXN9umS4orKj0RhWD/mN35biPaJ+17e1ya++z mP1Q== X-Forwarded-Encrypted: i=2; AJvYcCUYPY1EfXFbA6S9oRghaj19tbc0dHq5AGcHZbBlKXHw3LNPBQkA3gVgKoCxUUUVWvFi/EU3LoDhOyfi@gnusha.org X-Gm-Message-State: AOJu0Yy6i3eR+0phbk2umBgNjPCyYkA4/qIS/1BdYygqq+xbcmz24loP +iw7X64p9YaVWjz/0XvnjGQo117UXUfRTS5/Mc4Eg21fL1ohGPgx0PRO X-Received: by 2002:a05:6870:f605:b0:417:70c2:8537 with SMTP id 586e51a60fabf-423e10dc4e3mr843204fac.25.1775790800804; Thu, 09 Apr 2026 20:13:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKXFFx1UFmWyQewoSXtUMuWZTRN734r0Wcdb+F5bXVJcA==" Received: by 2002:a05:6870:d409:b0:409:4c04:fab5 with SMTP id 586e51a60fabf-423dd9b0a41ls304955fac.2.-pod-prod-05-us; Thu, 09 Apr 2026 20:13:16 -0700 (PDT) X-Received: by 2002:a05:6808:6f88:b0:467:2926:1231 with SMTP id 5614622812f47-4789ef13d68mr938227b6e.33.1775790796451; Thu, 09 Apr 2026 20:13:16 -0700 (PDT) Received: by 2002:a05:600c:529b:b0:488:965a:b7a8 with SMTP id 5b1f17b1804b1-488cf323ff6ms5e9; Thu, 9 Apr 2026 19:23:20 -0700 (PDT) X-Received: by 2002:a05:600c:4f95:b0:488:be58:bb5b with SMTP id 5b1f17b1804b1-488d686c443mr13210555e9.24.1775787798710; Thu, 09 Apr 2026 19:23:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775787798; cv=none; d=google.com; s=arc-20240605; b=gBAqdavexPMSkamvxVGmO4Hbcy+jD6oBv/hIGd6FJpjXoOy16XBaMzWQDlOgj4Oym5 +IcZC537+QC1wjHBJRZd6BXnGJSqaYW2GaZFoP/Dd82pqtMtsBZzb6yCz9XmtRsv+XMn 6iaxNVaiQfh19aYR9G4sAJbSB3gY6/aP9fHN7VpcaOLT4qvS8BAJChhJluWHWw/ACY8G 7uWl+TYj7aWwrbgUX/1usgqcP58Pv5OopZZmbOQx1urx4DQKOixo0UlkOPpOaU5kyDYD usWqvpWkfeBDDqlmjtx4phLQdF+khbJmn93uihyPvki0+hGzi6fh/Cw1fwMz+tiTzrKF ygFA== 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=KJ1HtHpPq6VRDFLduD1Jloxmjr6WBoNTujV6omr52AE=; fh=foaZ9w3C3c5ltuXRyLrsJcSZd5F+/L4e8AHpKYxjE8o=; b=Atys8vOipau/HXB3wYHkXHSYgqqfK6gDnrpRAyPj+CegJddyrOfIKaQff4q9WjDHzA WeNcZ3mp569dOQZNme+yB7us7qm9VqNHN5dk9/2jbVx2GFSJmsEQoa3OktEp2x94WaMy vmjj7nvLHFVkksorxRlKMK3eLLKklrH6xW1F9aCSLVcnedlKEEpkMdZ/iuOTNzXBfNJB qGfURVWZ3rYgrSvu4tuN3aFP2MWlJf/+u5oIiKeVzWmfBYhsuxzq+V4JpHXhzExZcxLN +k050YkDZuH2UYAGy5bI201rDmwy4nQFthJmCZ5QUxaYSERhsAqhhfbc5KW+8N8fHhnS LPEQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=dVBD1Fuw; spf=pass (google.com: domain of bubb1es71@proton.me designates 185.70.43.166 as permitted sender) smtp.mailfrom=bubb1es71@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-43166.protonmail.ch (mail-43166.protonmail.ch. [185.70.43.166]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-488d6675e91si135335e9.1.2026.04.09.19.23.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 19:23:18 -0700 (PDT) Received-SPF: pass (google.com: domain of bubb1es71@proton.me designates 185.70.43.166 as permitted sender) client-ip=185.70.43.166; Date: Fri, 10 Apr 2026 02:23:11 +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: <-s2dq7t8eZAKtQO-BvS0Ug3Zgo6D7evmyRgdeWBME_5wIOLasu47umjQikb2-dlWY7_ndn5mTIYZzsxDidMMbboKXF4ElpEHKxQdk60V9c0=@proton.me> In-Reply-To: <283ccf28-c0ca-4ba5-9c5b-c4215a2fa0cf@murch.one> References: <3b3328b8-bba4-4858-b53a-0e9b631044ffn@googlegroups.com> <5028df3d-22ec-4a3e-9b54-64a4f1f0cefc@murch.one> <283ccf28-c0ca-4ba5-9c5b-c4215a2fa0cf@murch.one> Feedback-ID: 172960010:user:proton X-Pm-Message-ID: f3cb4478bdd0bce7a2ce13b21e86d20e0095231b 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=protonmail header.b=dVBD1Fuw; spf=pass (google.com: domain of bubb1es71@proton.me designates 185.70.43.166 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 again Murch, to address your question about BIP 125, the reason we requi= red the opt-in for our dust disposal spec is to prevent implementation fing= erprinting. But if it's more future proof to not signal for it I'll put tha= t in the spec. The most important thing is all implementations do the same = thing. PS. I still don't know who " thugm501@gmail.com" is. I suspe= ct a bot. Sent with Proton Mail secure email. On Monday, April 6th, 2026 at 4:04 PM, Murch wrote: > Hi Steven, >=20 > Thanks for the quick reply, looking forward to reading the updated docume= nt! >=20 > I just realized that I forgot another point in my prior email. While > there are some other node implementations that still implement BIP=E2=80= =AF125: > Opt-in Full Replace-by-Fee Signaling, Bitcoin Core 28.0 and later will > accept replacements even if the original transaction did not signal > replaceability=C2=B9, so you could consider dropping the replaceability > signal requirement. While the dust disposal transactions will be quite > distinguishable either way and it=E2=80=99s unlikely to be a big deal if = they > were to continue signaling in the future, it may be more forward-looking > not to signal. >=20 > =C2=B9 E.g., see the linked news items regarding `mempoolfullrbf` on > https://bitcoinops.org/en/topics/replace-by-fee/ for details >=20 > Cheers, > Murch >=20 > On 2026-04-06 11:11, STEVEN SLATER wrote: > > Response to Feedback on Transaction Aggregation Proposal > > > > Hi Murch, > > > > Thank you for taking the time to review my proposal and for raising > > these thoughtful points. > > > > On the question of requiring an ash-output: I did consider the idea of > > mandating it universally. The main trade-off is between simplicity in > > aggregation and the overhead cost. A fixed 3=E2=80=91byte addition per > > transaction is relatively small, but when scaled across high=E2=80=91vo= lume > > usage it does introduce measurable bloat. My current rationale was to > > avoid imposing that cost on transactions that are unlikely to benefit > > from aggregation. That said, I agree that in scenarios where feerates > > fluctuate significantly and dust transactions linger in the mempool, a > > standardized ash-output could make collapsing transactions more > > predictable and efficient. I=E2=80=99ll expand the rationale to weigh t= he > > benefits of guaranteed collapsibility against the marginal overhead, an= d > > outline conditions where the overhead is justified. > > > > Regarding incompatible outputs: you=E2=80=99re right that independent > > submissions with conflicting outputs cannot be aggregated. My intent wa= s > > to highlight that aggregation works best when inputs are aligned, and > > that ash-output could serve as a safeguard to preserve compatibility. > > I=E2=80=99ll clarify this point further in the next revision. > > > > Thank you also for the correction on feerate policy backports to Bitcoi= n > > Core 29.1 and 28.3. I=E2=80=99ll update the proposal to reflect that us= ers on > > those branches will indeed propagate sub=E2=80=91sat transactions. > > > > I appreciate your constructive feedbackit helps sharpen the rationale > > and ensures the proposal is practical for broader adoption. I=E2=80=99l= l > > incorporate these clarifications before submission. > > > > Best regards, > > Steven > > > > On Mon, 6 Apr 2026, 5:26=E2=80=AFpm 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 = test > > 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 si= ngle > > transaction. > > > > I was wondering whether you considered generally requiring the > > ash-output to ensure that transactions can always be collapsed. Thi= s > > may > > especially be attractive if feerates will be more dynamic in the fu= ture > > 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. Eit= her > > way, perhaps you could expound a bit on that trade-off in your > > rationale. > > > > Also, minor correction: the feerate policy change was backported to > > Bitcoin Core 29.1 and Bitcoin Core 28.3, so users running the lates= t > > releases of those major branches would also propagate sub-sat > > transactions. > > > > Otherwise, this proposal looks reasonable to me. Looking forward to > > your > > submission. > > > > Cheers, > > Murch > > > > 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 va= lue > > > going to transaction fees. The protocol enables wallet software = to > > > remove unwanted small-value UTXOs, particularly those received i= n > > dust > > > attacks, without creating new address linkages or degrading user > > > privacy. The specification includes transaction format requireme= nts, > > > signature conventions enabling third-party batching, and validat= ion > > > rules for compliant implementations. > > > > > > ## Motivation > > > > > > ### The Dust Attack Problem > > > > > > Dust attacks are a well-documented privacy threat where attacker= s > > send > > > small amounts of bitcoin to numerous addresses. When wallet soft= ware > > > 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 ne= ver > > > spend them, but this creates its own problems: > > > > > > 1. **UTXO Set Bloat**: Unspent dust permanently occupies space i= n > > the > > > UTXO set that all full nodes must maintain. > > > 2. **Wallet Clutter**: Accumulated dust degrades wallet usabilit= y > > and > > > complicates coin selection. > > > 3. **Accidental Consolidation**: Users may inadvertently spend d= ust > > > during legitimate transactions, achieving the attacker's goal. > > > 4. **Lock Fragility**: Wallet software that "locks" dust UTXOs t= o > > > 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 = new > > > address to link. > > > 3. **Permanent Removal**: The dust UTXOs are removed from the us= er's > > > wallet entirely. > > > 4. **Miner Compensation**: OP_RETURN outputs are small, providin= g > > 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 comb= ined > > > into single transactions, reducing overall block space consumpti= on. > > > 3. **Best Practice Codification**: Ensures implementations follo= w > > > privacy-preserving best practices. > > > 4. **Easy Identification**: Chain analysis tools can use disposa= l > > > transactions to help trace the sources of dust attacks. > > > > > > ## Specification > > > > > > ### Transaction Format > > > > > > A compliant dust disposal transaction MUST satisfy all the follo= wing > > > 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, a= s > > 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 = for > > > 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, = 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 addresse= s > > 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 o= ne > > > transaction. > > > > > > ### Batching Dust Disposal Transactions via RBF > > > > > > Multiple unconfirmed dust disposal transactions created by unrel= ated > > > entities MAY be batched into a single replacement transaction us= ing > > > 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 co= uld > > > 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 batc= h > > > transaction's fee rate as long as all the requirements of this > > > specification are still followed. > > > > > > This mempool-based approach preserves user privacy while enablin= g > > > efficient batching: > > > > > > 1. Users broadcast their individual dust disposal transactions t= o > > the > > > network. > > > 2. Batching services monitor the mempool for compliant dust disp= osal > > > 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 initiator= s. > > > > > > A UTXO is generally considered dust if its value is less than th= e > > 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 co= ld > > > storage wallets where the key or keys needed to sign are not eas= ily > > > accessible. > > > 2. **Transaction Correctness**: Transaction signers must careful= ly > > > review and verify that only dust UTXOs are spent and no other > > inputs are > > > signed. > > > > > > #### Privacy Preservation > > > > > > 1. **Network surveillance**: Internet service providers and othe= r > > > internet monitors may be able to determine the nodes that initia= lly > > > broadcast a dust disposal transaction. If available the > > > `sendrawtransaction -privatebroadcast` RPC feature should be use= d > > > (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 d= ust > > > disposal if outside the norm may be used to fingerprint the wall= et > > > 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 represent= s > > 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 privac= y. > > > > > > ### Why 65 Byte Minimum? > > > > > > Bitcoin Core enforces a minimum transaction base size of 65 byte= s > > 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 allow= s > > dust > > > UTXOs to be disposed of economically even when their value is ve= ry > > > 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 th= e > > dust > > > disposal transaction after signing. This provides several benefi= ts: > > > > > > 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 dispo= sal > > > 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 descrip= tors > > > - 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 = dust > > > UTXOs according to the specification in this BIP. > > > > > > ### List dust > > > > > > 1. Create payment addresses for multiple address types, send dus= t > > and > > > non-dust amounts to these addresses, verify that listing dust on= ly > > > returns UTXOs at or below the configured dust threshold (e.g. > > 1000 sats). > > > 2. Create confirmed and unconfirmed dust UTXOs in the test walle= t, > > > 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 produ= ce 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 th= e > > 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) | P2T= R | > > > > > |--------------|---------|------------|--------|-------------|-----= --| > > > | 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 transactio= n > > > 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 fo= r > > 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 Goog= le > > > 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>>. > > > > -- > > 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 > -- > 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/283ccf28-c0ca-4ba5-9c5b-c4215a2fa0cf%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/= -s2dq7t8eZAKtQO-BvS0Ug3Zgo6D7evmyRgdeWBME_5wIOLasu47umjQikb2-dlWY7_ndn5mTIY= ZzsxDidMMbboKXF4ElpEHKxQdk60V9c0%3D%40proton.me.