From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 09 Apr 2026 20:13:18 -0700 Received: from mail-ot1-f57.google.com ([209.85.210.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 1wB2J3-0007QC-2g for bitcoindev@gnusha.org; Thu, 09 Apr 2026 20:13:18 -0700 Received: by mail-ot1-f57.google.com with SMTP id 46e09a7af769-7d9e1498d4dsf3702317a34.0 for ; Thu, 09 Apr 2026 20:13:16 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775790790; cv=pass; d=google.com; s=arc-20240605; b=TZy0X1lVDXpmg1FrXn5ShZcoVsk/RQ1UuKNDovtz+yj6ksNW7/YomOnC7/DE7Y2/IS IFzPq0BQekRwRHdybeX6lgoZtxvNUYT32G05OLBUXXTCcE4JcdmJDGXdXwfjoSN9UcWz x2hoyl0sDZRkNX0rZl9TIe561ZM47u4ujtzjWUxzdZgFCYALLjDilAKpLi7aMdKAi99G TozYY4ZwBYwKvGtAOvwSa+mLTwCW2kSJwCwp50nRvxQGD5CLcXiC6+GRnvkFffwayFD5 YkFlbXoox+lzRQYvFNdG3vSubsINby07v9ub5rf+qlFFMRzXGYn/ddBHbQAVQlRhXiv/ HO1A== 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=sYk42nCtbXOUS+IX+4r2lbOnfqrvMi0PGljXq3gt0vA=; fh=EmjOWQHHTTH7+xtyaav4XI+e3GJE/t7PZw4slkm1Jqw=; b=LDOc+syp9AQOlKO2J+mv64a+brgglzn9W2oNYv3iiuQhxDNHS8i9+LWow4ljuRXV19 CpCInFZO+5dXgydYNF113w05Ba6b8OfAB7vkABEcVU2JCMHDa9CFDoX3a3R1J9uPsUeh HadqPgGLygRZ5sM2wluykqLh220KlmtkZBSG3Ujhl5e17IHAY+kDHGJj6/fB3vQWBb+U ACIpKnR3ksgMVFK1PmirGVFyhWFZXnuF2q2cjFq8S7qdGaMIhjluZtin/NtnFRGIB0Bm h6zX/saV6H3ueXL4IU8LoEdAX39aCJ5dexasNADY7xbIb6FrBevLd7OeqOT62EDsS5ZE sbdA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=cuVtqhGz; spf=pass (google.com: domain of bubb1es71@proton.me designates 109.224.244.29 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=1775790790; x=1776395590; 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=sYk42nCtbXOUS+IX+4r2lbOnfqrvMi0PGljXq3gt0vA=; b=YqF+atF6EYFhTpV/yRfxxSInz97t2WnHa6SEfvraatN0PXDVPqgj/LPnezX4wWDALl 84bMvYIX0/uVTM2o5Z4WJm6fRuRdHcRKGBb/FJUdcZdYSWYKgvmx8cDycAjrHqOqiS1h wWiNqkEfJIJ5D2wCpV7uzk0akR507hjpS21SvMAC9l/15SzCvf/g5K3HL0Bgsf1mIsJz IYToTFZvydv/VLsUPiNjg/deNJAA7rlhKDiayWoKlN4LSTb/n6p6L7TKN5zORFaZKAki zBNHFWjqlLOXnmu+jJcOw1iGV/QgZkdPXOosarZ/H3PTEXfuXv6WXSWNaw3o8gVW3yhJ DMxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775790790; x=1776395590; 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=sYk42nCtbXOUS+IX+4r2lbOnfqrvMi0PGljXq3gt0vA=; b=pRp2xuw/7ZXc/eKD6yrGL6pY9LKDL+efirtOE4g7XUaNE0FANIm8TGqCLiV9GmqOst H1a4d+ZjjzTqPWtlLyMDApEj+MmhdLkQichBGebB8BydXzji6WO9/OsqH9fBZJ70Qm6j 0hq4dPgNfUm4VQe4SPYA9F9iZsUKbi+vULaiLsclhMah3cB1cFDg44tsMnG2M0AKu+xj ynii0AVoUgXRk2kja7PZnKG2Y3QMW/s1OdMCvAEG/66+zzHmRLmXszma8H0cR1z099lI y6KN2z7Kce78M3rCemnzq676zBl+hYI/gb+kYdd5xllrpz/aHt1v4aopq3uYqKsf0r1x sIsQ== X-Forwarded-Encrypted: i=2; AJvYcCXqJxz+j9Pe4vtbqwbfYTl7GNn7yUMlJ3BB20UwsU+yLjatifMmcgoQt/d9qTzFXXtJiraMOmYj+3q+@gnusha.org X-Gm-Message-State: AOJu0YyZ4XvF/j94I5FyC0FDV7gXQJO+68ZYeuQUTTeznGU/pAEwhhku eavpZCBFXtugkdqYRa36IE50U/H3B/N7CBp36mjvhPpB0Pj0xj5dCH99 X-Received: by 2002:a05:6808:2213:b0:467:3f4:906b with SMTP id 5614622812f47-4789f9064eamr872597b6e.51.1775790790450; Thu, 09 Apr 2026 20:13:10 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLdmjpHfZ+01FL9pxZN81oYSFxxQbBt63cTu/HZ9Lq8GQ==" Received: by 2002:a05:6870:a092:b0:422:c0f1:a9e4 with SMTP id 586e51a60fabf-423dd0223a3ls233247fac.0.-pod-prod-08-us; Thu, 09 Apr 2026 20:13:05 -0700 (PDT) X-Received: by 2002:a05:6808:c297:b0:467:1e7b:72d0 with SMTP id 5614622812f47-4789c64ac25mr858289b6e.5.1775790785358; Thu, 09 Apr 2026 20:13:05 -0700 (PDT) Received: by 2002:a05:620a:7293:b0:8b2:e5d4:9264 with SMTP id af79cd13be357-8db3d124955ms85a; Thu, 9 Apr 2026 19:14:21 -0700 (PDT) X-Received: by 2002:a05:6102:6a94:b0:608:706b:b346 with SMTP id ada2fe7eead31-60a006314a5mr439050137.20.1775787258764; Thu, 09 Apr 2026 19:14:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775787258; cv=none; d=google.com; s=arc-20240605; b=dbave3R5e3hydeGtaGI2tSLdmyn6iJFeUQnI86oci39jU1s93Vatkg4By4CdZ72aBE f0wLHgZszHvFgYjabX2SqF5/+wyP7Y5UTmPG1f/zbInjib+3PT3K7vjozY6Wr1Zdnf2i Hmw9SvlIOHPIUQRMxa2hyRJRmVnMw8gYLiZormz/tPTW36YM8amlHhHq5ENfhvGYtofD y+/iLib0zdUBOSzXBRl8x8ttLB8H7sNKxuCjLqQkNOG//b8TNN6hcDF9RX2GR0h2cjKP 3XC6DeZYJiugQnMoAG2t9rsIkIT2xyWeRRKvQd4rToiSrSnf8thVC+psKXL7TliKe2hH UGwA== 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=Sq1xpQVp8WoADxen0PWKdH6y3wtp/gT87YL2/enIfvM=; fh=foaZ9w3C3c5ltuXRyLrsJcSZd5F+/L4e8AHpKYxjE8o=; b=YR7Jz8NG8k2LWCjco2Si644lM/UkiU5w48yyIzuAXpvgmuEhjxGTEe+w7KE3u4GqXA n/VTM0Ew77OM57G5qERG9wCJyA8EO4F3e4dXM6V8AV+oBndKALgU55bjlgerp6ePZTGr +4rrw8ntxypZxeYWNGLi1VMKttU5WL1JePKFIewMy5NwETIksNoOEWKsy+3n6pEIc0wV 9u/ef62vf4wYpm+WwOKXzX/gvkOhzm06dU0zfU0xN331Vd8xMG/ufSJiGMYjR4h3l6io nV/kvNbwgXhICh6u3e7aS8+1FEXDfV3YkYLHUTHY65eRwIzJtH4rygn8PcS+ER7G8Okv SBDA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=cuVtqhGz; spf=pass (google.com: domain of bubb1es71@proton.me designates 109.224.244.29 as permitted sender) smtp.mailfrom=bubb1es71@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24429.protonmail.ch (mail-24429.protonmail.ch. [109.224.244.29]) by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-954bf183640si47179241.2.2026.04.09.19.14.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 19:14:18 -0700 (PDT) Received-SPF: pass (google.com: domain of bubb1es71@proton.me designates 109.224.244.29 as permitted sender) client-ip=109.224.244.29; Date: Fri, 10 Apr 2026 02:14: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: In-Reply-To: <5028df3d-22ec-4a3e-9b54-64a4f1f0cefc@murch.one> References: <3b3328b8-bba4-4858-b53a-0e9b631044ffn@googlegroups.com> <5028df3d-22ec-4a3e-9b54-64a4f1f0cefc@murch.one> Feedback-ID: 172960010:user:proton X-Pm-Message-ID: 4d1388d4c24b5a4b1d21f8019f6ac324fa224a26 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=cuVtqhGz; spf=pass (google.com: domain of bubb1es71@proton.me designates 109.224.244.29 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, since posting we've had some constructive discussion on the Delvi= ng thread with nothingmuch (https://delvingbitcoin.org/t/disposing-of-dust-= attack-utxos/2215/21). He suggested using the "NONE|ANYONECANPAY" sighash f= lags instead of "ALL|ANYONECANPAY" as we originally proposed.=20 This change would allow batched dust transactions to replace an unnecessary= OP_RETURN "ash" output with an empty OP_RETURN. I don't see any downside t= o doing this so I've updated the proposed draft BIP. I've also updated the draft BIP with your corrections regarding the version= s of Bitcoin Core with the new feerate policy. Thank you for your review and encouragement! We hope to submit it for revie= w soon. PS. I do not know who " thugm501@gmail.com" is and he has no= t made any contributions to this project. On Monday, April 6th, 2026 at 11:26 AM, Murch wrote: > Hi bubb1es, >=20 > 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 single > 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 future > 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. Either > 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 transaction= s. >=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 > 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 transaction= s. > > > > 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 value > > 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 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 send > > 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 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 fee= s > > 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 user's > > wallet entirely. > > 4. **Miner Compensation**: OP_RETURN outputs are small, providing highe= r > > 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 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 < 0xFFFFFF= FE). > > 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) doe= s > > not include ANYONECANPAY. > > 3. All inputs must be confirmed in the blockchain at least one block de= ep. > > > > #### 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 addresses in th= e > > 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_ANYONECANPA= Y > > signature type. > > > > In addition to standard RBF rules, batch dust disposal transactions mus= t > > 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 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 disposal > > transactions. > > 3. Services can combine unconfirmed transactions via RBF without knowin= g > > user identities. > > > > ### Dust Threshold > > > > Implementations SHOULD allow users to configure their own dust threshol= d > > 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 signin= g > > 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 ar= e > > 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 transaction= s > > 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 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 requirin= g > > 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 disposal > > 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 suppor= ting: > > > > - 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 relayin= g > > 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 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 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_RETUR= N > > 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 outp= ut. > > 2. Adding a Bech32m dust input to an unconfirmed disposal transaction > > with a Bech32m dust input keeps the original single "ash" OP_RETURN out= put. > > 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 i= t. > > > > ## 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 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=3Df= ooter>. >=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/bitcoinde= v/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/= s9lD_CC0yTtNN2igb1JAiRCacgPeBB8Za6sC7TE0wljSg2rfuWN0ByWciCdhzKxPoa0FfrYulGB= kKCFlInWg8iJRED5fnItOShtOMuszSN4%3D%40proton.me.