From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 06 Apr 2026 14:04:18 -0700 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1w9r7I-0004hE-7X for bitcoindev@gnusha.org; Mon, 06 Apr 2026 14:04:18 -0700 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-42322062cf3sf4218843fac.2 for ; Mon, 06 Apr 2026 14:04:15 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1775509450; cv=pass; d=google.com; s=arc-20240605; b=VWPSOlZ+9y27qPnoJyCYVilAOv2crrrQC3mUVdXZGmr6pIMOIT/Ni9sQH8CfIvkrSm QwIAx2PyNc00TFzs2aFSkIut3Ff8vYCVhXLjb/VvMt5E7+P0YuVpcSpmcWxyMSu/ta7a 0KVTB0G1KikrPta+Dn8aAZmoHpG9xISBXUJ0s3V+aSQzREoUggTU710WpfS4k6N/tTK6 xLtYNmD60LoCjU+m92+toG96mXCYjYqICmqJwoUeG4EPi32V/cXT1P1P/6knSSGKQaAe jghpjrJgkZiddFWR4OHaZFgqSQX+cevoEXziyOyPVKFHUaG8zuCI9WlAj7BFrTqt33GP 1UZg== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=Lgf9lZJiH0InD5yjCHXhwO5UtmIyRlZ0gkk4PseX+wY=; fh=dqeTLfUu0sPNC2PpIvKwhvjhWSKn6zPeVfngnuD61qc=; b=GR0UAazOaiK0QARWXr4K8KQ5CMR6nhRu3YXJjYxokQjA8y7gijBjnk5Q4uFoRq751h waJvMmmk8bsASe4pepmkR+8DKdC0dZYgbtrekVrj5V7nRuZjKSKQ31T7Jm8sQdIKVBsO U21p1vE50/5ild4hiGAzKupB0Emvn89wSByp1rJex/fenskytLC74Sdm2ZNDAvTpd37z VGt3HPD0wmH/+7rba0NBCBlmnvBtOv6qjZ0TzTEtrhJtTHKewj+AWQK65O4r/1J8WPtz 8IjzudFaijBBYz5Jr6+6z/lyBM15wnlrPOnW60YQ0Mw73Qxp/IcubfgF37lHiEIl6dr4 CyGA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=ab4jVmN1; arc=pass (i=1); spf=pass (google.com: domain of thugm501@gmail.com designates 2607:f8b0:4864:20::1133 as permitted sender) smtp.mailfrom=thugm501@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1775509450; x=1776114250; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=Lgf9lZJiH0InD5yjCHXhwO5UtmIyRlZ0gkk4PseX+wY=; b=yAAlHbu67KazZvSTX28IDtLUsNd1R27/+TASxSXIfjYK3pYMmbwvmwl3qWLN+Vo2xY L07np2zsg6FZ7E771gC2fLs6Zw2rbKptOrn/JYro5VCxqruDQR9TNbAGdthcQnX7F1qA vqbubtVzjKOHEq6CdgeulKCzrJV2gJ8ZSgljE8BOItQAtiisUo/CwF7UcAsBqiv3DwsC /nsks1fbXpdtnbj/TPVr8peh8/SDwKxqVXmHVlqy0mMIPDHU1XouoUhGfwwcI/qT82r8 RnPFBaLzh/UyCOI0hly4TG71PXqLDPy0V/AOSOKC/m/RJMdY1A9N5kXzX389JZSK/KLK kL6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775509450; x=1776114250; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Lgf9lZJiH0InD5yjCHXhwO5UtmIyRlZ0gkk4PseX+wY=; b=eTo924adTwoQZZoaqzq8BjN01HSq/OpxWo85wlZyqjgaU5HWVGyyIi5qvw0rTBbbkE Pk2KpsKJLG+/QAjjNZeI2xoAKCTnEuwrUiM+nRo3SRreOZBsaN1y/Z2xMBZxvQXRNOnW hFbJk+nAe7cLQeoX5s8lHd2e7GkQF2Ovkaevrwy+kEf92QUZSOH/OAck6KMDCQQ10/Sy xx6UGZN6HVtw+mvRzHI9uSUvZ5NiAu1XbufqPIX8yGgEF6WFVAR7vG2atny/sjN/z3pm MsoVeByKT/NidSeTN0kCM19nXPBinuWWdEfhEvQywt7q6bEzrQW8ofHvXinNykQbtDhZ pJwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775509450; x=1776114250; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=Lgf9lZJiH0InD5yjCHXhwO5UtmIyRlZ0gkk4PseX+wY=; b=c0EdHhvwXQWWcOZLXe2W/IyH6dGozi9wsER9wgs7quGUVnSacQ5QRiPgYwaRaL4RO1 +rBwBl5YuhTYnpRZuymIOQS1n3a5C4l5H2olDN9wv1nHBR47YzSwtwN+ifb3w2ybgdi9 lw9iPWVoUwrUnWb5miWCuhm3vStGjv0rSxrsIECzPJTtGISDRWFW4tUlCFI7niCIRqtB SoJHb459RCKp1kvCcynnRuQPam0RAa+tzzzs7KZVxYZYSxe3y4a5l/DxJQEQyI9St8GB DPvf6czkMvdmI2pt2o+XZbNZCGmm3mhNYQmlFrbIsgA78qQFKrH7K91YlPv6PhN+lLMp xKJw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCW+EdB8MvF6yD7QT/YdNmAFuyG8I0ugj4WFpDfHEvp6O/h5cY6pRq6DCKeMvxlhZ8sa5RTDsmBfiXAT@gnusha.org X-Gm-Message-State: AOJu0YxLWC4RBCcgM2wiX05SMSpPiVyghvZh8x9L77TD1D3KPrtVUHrB ljVdrJ/jsw4sW1Z68DeHB17p3YahEZF2ynNBkwzivDwEF3jTlWEVeQYS X-Received: by 2002:a05:6871:e024:b0:417:5202:4dfe with SMTP id 586e51a60fabf-4230ffdec3amr8453189fac.26.1775509449377; Mon, 06 Apr 2026 14:04:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIEu28LV2emCWEBjFfS2X1TO9Ksz8i+uuDRVz20iICQ+g==" Received: by 2002:a05:6870:d613:b0:422:c0f1:a9f7 with SMTP id 586e51a60fabf-4235f02c65als470572fac.0.-pod-prod-04-us; Mon, 06 Apr 2026 14:04:04 -0700 (PDT) X-Received: by 2002:a05:6808:2006:10b0:472:f551:767e with SMTP id 5614622812f47-472f55180bemr1685087b6e.8.1775509443968; Mon, 06 Apr 2026 14:04:03 -0700 (PDT) Received: by 2002:a05:6808:22c3:b0:467:52e4:df4a with SMTP id 5614622812f47-47040aea7bcmsb6e; Mon, 6 Apr 2026 11:12:06 -0700 (PDT) X-Received: by 2002:a05:7300:d05:b0:2be:10a6:647e with SMTP id 5a478bee46e88-2cbfc16e113mr7082393eec.19.1775499124687; Mon, 06 Apr 2026 11:12:04 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1775499124; cv=pass; d=google.com; s=arc-20240605; b=HZ8NrM9yGB1rzzWu7au3f8NA5GmBEmkHW56yt4TaV2vMPU8BFlS52otYbmQLz+dy1H 5oaZSYaMjIy3D2E6CdU2lczcjsfHNXEdfCZfFQbPBGE9ASRhEXaWQPgx+OgAOzk1wYvU 2QQeRCeKQQ/qp9QoSHLu3CgiYKY+qjUX3wALE/Iz+EvRDBSRANMgrHdxghSXJdrEFrGL OPnKIq5RaxfsCM9Agvg4ZHObyygvT1vdvEtgsbBIKyxXnSMY96P47dyCJIiQ7fp3Dw+v z8dB3aFXtYvJjkJ6+SRCsA2xNGKwanSDnng7+tNCJoHOKsNRCILgvAmhwC8NkrU8ihKS 2hKA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=kKEPS+fCtR2A+tvtZv07rz55ds4e31WCEOfPNj+E/w8=; fh=foaZ9w3C3c5ltuXRyLrsJcSZd5F+/L4e8AHpKYxjE8o=; b=N8vvUbSV0wFTju2hR3wBxFbB/A5u2V2iQbPEeNpdXAo00Moi9PyzMZZ+ZsMceSqWh0 6zfyy56+3v1NO5ffWY5ljtEVtpRJvgPM+YTWfUc+v3bRR6bnbVJmBPvVwOvMRlA4gO49 LdasQES4s0c47Iw8LtEj+2dwJ0M7fEWg0EZiVGudLShYVx9VoasiQuKnCRAFkCEuNvcy piPzhkdQr0xPQKBPYPx9RNuxQr/+WVlE0pATJloFemG+KntD63NNa2Ag+Zm8sochtzbY DSHaRfXmiejL1Dph+cigiwebkh68FvklVQf50JY+/LcmBi4OBVmg1uuS/LFB3kYDoCAs OXxA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=ab4jVmN1; arc=pass (i=1); spf=pass (google.com: domain of thugm501@gmail.com designates 2607:f8b0:4864:20::1133 as permitted sender) smtp.mailfrom=thugm501@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com. [2607:f8b0:4864:20::1133]) by gmr-mx.google.com with ESMTPS id 5a478bee46e88-2ca760b00f3si455737eec.0.2026.04.06.11.12.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Apr 2026 11:12:04 -0700 (PDT) Received-SPF: pass (google.com: domain of thugm501@gmail.com designates 2607:f8b0:4864:20::1133 as permitted sender) client-ip=2607:f8b0:4864:20::1133; Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-7927261a3acso34708537b3.0 for ; Mon, 06 Apr 2026 11:12:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775499124; cv=none; d=google.com; s=arc-20240605; b=UIp3jLR55G/SFaawhuk+ZWApPyXoM2031R1ngoHdfuXjw+N/mTZjAMJRUDTs/lrtJQ XObZ0PJkzfc1vSG3XVdK67iz5hqNvY748iZlYjSmYQw7pAtxnN+uCUoakRglXk5UAO+3 duBt2A3r4rV05eNwzem6UQOjJ4wnHI703qx8Uoee1+vEn9nLVF+m5FteQv8ur/60iRyJ tmCfCA1GkpWRsiW0w5ilICfSA/U7577ku0Hpq6Yzk7WzzCEhkMGPK0Cox4Y/yEOOWKNe EShF/LWV3rF6pvNzIPLz4OaMpaB2Y43HPMIK9yvMdekt15+9AyQDKhTgLXalhIWBPUID T6bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=kKEPS+fCtR2A+tvtZv07rz55ds4e31WCEOfPNj+E/w8=; fh=foaZ9w3C3c5ltuXRyLrsJcSZd5F+/L4e8AHpKYxjE8o=; b=j54iS/OvaCrsvqTnSbnhGSjlH71Pv9AGiFsGtH92GxddntQLbn9q7/qF5w9qaPKd+O CPzeCKStfY2G+jeRILRC9IVmA4ctBmwN0W0Il3AO2GvrYSYGunt7Sg8vascAtSxqjd77 9v0BHq1kjOLpw5yeypUDVk4KIV2UB7lZKWoBK+xu6IrX4CzNXZscd2xJV9gBQnI3rDsq GHGM89oCIt2qZHO6XIETi3CyUVcCsgHPLClcfQJ7jT2ttjn3U31hIWdAgQujH2+z3Izn 2EpvgaQoJGzPYIVj6Hnxpy/K2SmYPrXjSR7EwjxWefDS8x14BHMCgoh/viQ2m69C1Fjc Hv2w==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AeBDieuMaXce6b+4yR8vU3Ym4TD+cBptxAYCLE47wWV8vBV1dTH5jWYL9UePipVuwjY QMYIbXlLOoF8srV9SsJeVh3j0Yha4/hGBU7NsI3A7NNhTbE3CaunM0qSHoW0BldXHul2teIeLKo jYuvFGnk9EUdj+YfvUn9WkcBUHU8RJMP8yAED3ce5mtaHUo1PUA8xT8ZT2OIJQm1Q4JtUnqKK3t tSP2kIHfo4VuKrUxGIsvfW73UAtwTZqdtXCFkqQBzGoukc4SjN3/WP7sXmLkDhmMqECDTiVNfhZ QqNEsRz9Ef3SqMu0O2Q= X-Received: by 2002:a05:690c:6989:b0:79a:bc1e:a399 with SMTP id 00721157ae682-7a4d84c5acfmr135678057b3.35.1775499123375; Mon, 06 Apr 2026 11:12:03 -0700 (PDT) MIME-Version: 1.0 References: <3b3328b8-bba4-4858-b53a-0e9b631044ffn@googlegroups.com> <5028df3d-22ec-4a3e-9b54-64a4f1f0cefc@murch.one> In-Reply-To: <5028df3d-22ec-4a3e-9b54-64a4f1f0cefc@murch.one> From: STEVEN SLATER Date: Mon, 6 Apr 2026 19:11:49 +0100 X-Gm-Features: AQROBzAkc4y64VLpVe68DBHMLhZIOkuwBWdHXAzI0Pi3yUSEK48_-SNw6usoyC0 Message-ID: Subject: Re: [bitcoindev] [BIP Draft] Dust UTXO Disposal Protocol To: Murch Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000008c416b064ece9aa1" X-Original-Sender: thugm501@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=ab4jVmN1; arc=pass (i=1); spf=pass (google.com: domain of thugm501@gmail.com designates 2607:f8b0:4864:20::1133 as permitted sender) smtp.mailfrom=thugm501@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --0000000000008c416b064ece9aa1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 tran= saction is relatively small, but when scaled across high=E2=80=91volume usage it do= es 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 e= xpand the rationale to weigh the benefits of guaranteed collapsibility against the marginal overhead, and outline conditions where the overhead is justified. Regarding incompatible outputs: you=E2=80=99re right that independent submi= ssions with conflicting outputs cannot be aggregated. My intent was 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 Bitcoin Core 29.1 and 28.3. I=E2=80=99ll update the proposal to reflect that users = 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=99ll incorp= orate 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 single > transaction. > > 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. > > 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. > > 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. > > 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 > 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 < > 0xFFFFFFFE). > > 2. The ntimelock MUST be set to block height 0. > > 3. The fee rate MUST be at least 0.1 sat/vB. > > > > #### Outputs > > > > 1. The transaction MUST have exactly one output. > > 2. The single output MUST be an OP_RETURN. > > 3. The OP_RETURN data MUST be either: > > - Empty: `0x6a 0x00` (OP_RETURN OP_0), or > > - The ASCII string "ash": `0x6a 0x03 0x61 0x73 0x68` (OP_RETURN > > OP_PUSHBYTES_3 "ash"). > > > > The "ash" marker MUST be used when padding is needed to meet the 65 vB > > minimum standard transaction size with a single witness input. > > Implementations MUST prefer empty OP_RETURN data when the transaction > > already meets minimum size requirements. > > > > #### Inputs > > > > 1. All inputs MUST use the signature hash type `SIGHASH_ALL | > > SIGHASH_ANYONECANPAY` (0x81). > > 2. For Taproot (P2TR) inputs using key-path spending, implementations > > MUST explicitly append the signature hash type byte `SIGHASH_ALL | > > SIGHASH_ANYONECANPAY` (0x81) to enable ANYONECANPAY semantics, as the > > default sighash for Taproot (SIGHASH_DEFAULT, which omits the byte) doe= s > > 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 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 > 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 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 > output. > > 2. Adding a Bech32m dust input to an unconfirmed disposal transaction > > with a Bech32m dust input keeps the original single "ash" OP_RETURN > output. > > 3. Adding a new dust input to an unconfirmed disposal transaction > > results in a new batch disposal transaction with a fee rate sufficient > > for RBF. > > 4. A new dust input that contributes an insufficient fee rate for RBF > > with an existing unconfirmed disposal transaction is not batched with 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 > >. > > -- > 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-64a4= f1f0cefc%40murch.one > . > --=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/= CAP%2B9vXOVhnCC5fPjK1q9d_gL0%2BoHs1-Gk3p04%3Dw90W6dW1PbcQ%40mail.gmail.com. --0000000000008c416b064ece9aa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Response to Feedback on Transaction Aggregation Proposal= =C2=A0=C2=A0

Hi Murch,=C2=A0= =C2=A0

Thank you for tak= ing the time to review my proposal and for raising these thoughtful points.= =C2=A0=C2=A0

On the ques= tion of requiring an ash-output: I did consider the idea of mandating it un= iversally. The main trade-off is between simplicity in aggregation and the = overhead cost. A fixed 3=E2=80=91byte addition per transaction is relativel= y small, but when scaled across high=E2=80=91volume 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 ag= ree that in scenarios where feerates fluctuate significantly and dust trans= actions linger in the mempool, a standardized ash-output could make collaps= ing transactions more predictable and efficient. I=E2=80=99ll expand the ra= tionale to weigh the benefits of guaranteed collapsibility against the marg= inal overhead, and outline conditions where the overhead is justified.=C2= =A0=C2=A0

Regarding inco= mpatible outputs: you=E2=80=99re right that independent submissions with co= nflicting outputs cannot be aggregated. My intent was to highlight that agg= regation works best when inputs are aligned, and that ash-output could serv= e as a safeguard to preserve compatibility. I=E2=80=99ll clarify this point= further in the next revision.=C2=A0=C2=A0

Thank you also for the correction on feerate policy back= ports to Bitcoin Core 29.1 and 28.3. I=E2=80=99ll update the proposal to re= flect that users on those branches will indeed propagate sub=E2=80=91sat tr= ansactions.=C2=A0=C2=A0

= I appreciate your constructive feedbackit helps sharpen the rationale and e= nsures the proposal is practical for broader adoption. I=E2=80=99ll incorpo= rate these clarifications before submission.=C2=A0=C2=A0

Best regards,=C2=A0=C2=A0
Steven=C2=A0=C2=A0

On Mon, 6 Apr 2026, 5:= 26=E2=80=AFpm Murch, <murch@murch.one> 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 single transaction.

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.

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.
Also, minor correction: the feerate policy change was backported to
Bitcoin Core 29.1 and Bitcoin Core 28.3, so users running the latest
releases of those major branches would also propagate sub-sat transactions.=

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 <https://d= elvingbitcoin.org/t/
> disposing-of-dust-attack-utxos/2215> I'd like to gather feedbac= k from
> this community for a BIP to standardize disposing of dust UTXOs by > spending their values to the fee of single OP_RETURN output transactio= ns.
>
> Thanks in advance for taking your time to consider this proposal.
>
> ```
> BIP: ?
> Layer: Applications
> Title: Dust UTXO Disposal Protocol
> Authors: bubb1es <bubb1es71@proton.me>
> harris <imtux2@proton.me>
> Status: Draft
> Type: Specification
> Assigned: ?
> License: CC0-1.0
> Discussion: 2026-01-25: https://delvi= ngbitcoin.org/t/disposing-of-dust-
> attack-utxos/2215
> Version: 0.1.0
> ```
>
> ## Abstract
>
> This BIP specifies a standardized protocol for safely disposing of dus= t
> 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, <= br> > 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 <= br> > 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 an= d 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 UTX= Os to
> prevent spending provides only temporary protection; wallet migrations= ,
> restores from seed phrases, software bugs, or inheritance scenarios ca= n
> 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 fe= es
> provides several benefits:
>
> 1. **No New UTXOs**: OP_RETURN outputs are provably unspendable and no= t
> 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 high= er
> 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 <= br> > 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 <= br> > requirements:
>
> #### Overall
>
> 1. The transaction MUST signal RBF replaceability (nSequence < 0xFF= FFFFFE).
> 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_RET= URN
> 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) do= es
> not include ANYONECANPAY.
> 3. All inputs must be confirmed in the blockchain at least one block d= eep.
>
> #### 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 minimu= m
> 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, 0x= 68) 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 t= he
> same transaction.
> - MUST NOT broadcast dust disposal transactions at the same time for <= br> > 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 <= br> > entities MAY be batched into a single replacement transaction using > Replace-By-Fee (RBF). This is enabled by the inputs SIGHASH_ANYONECANP= AY
> signature type.
>
> In addition to standard RBF rules, batch dust disposal transactions mu= st
> 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 bitcoi= n
> 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 <= br> > transactions.
> 3. Services can combine unconfirmed transactions via RBF without knowi= ng
> user identities.
>
> ### Dust Threshold
>
> Implementations SHOULD allow users to configure their own dust thresho= ld
> 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 b= e
> used in a dust attack.
>
> ### Security Considerations
>
> #### Transaction Signing
>
> 1. **Key Security**: Signing dust disposal transactions requires signi= ng
> 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 a= re
> 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 transactio= ns
> 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 th= e
> 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 th= e minimum
> transaction size; e.g., for a single P2TR dust input.
> 4. **Semantic Meaning**: The word "ash" metaphorically repre= sents 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 requiri= ng
> 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 ar= e
> valid under existing consensus rules and can be relayed by nodes suppo= rting:
>
> - 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 relayi= ng
> 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 an= d
> broadcasting transactions
>
> ## Test Cases
>
> The test cases below can be used to verify a wallet disposes of dust <= br> > 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 sat= s).
> 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 <= br> > dust disposal transaction with a single "ash" OP_RETURN outp= ut.
> 2. Spending multiple dust UTXOs always produces a single empty OP_RETU= RN
> 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 out= put.
> 2. Adding a Bech32m dust input to an unconfirmed disposal transaction =
> with a Bech32m dust input keeps the original single "ash" OP= _RETURN output.
> 3. Adding a new dust input to an unconfirmed disposal transaction
> results in a new batch disposal transaction with a fee rate sufficient=
> for RBF.
> 4. A new dust input that contributes an insufficient fee rate for RBF =
> with an existing unconfirmed disposal transaction is not batched with = it.
>
> ## Related work
>
> * "dust-b-gone": https://github.co= m/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
> <mailto:bitcoindev+unsubscribe@googlegroups.= com>.
> To view this discussion visit https://groups.googl= e.com/d/msgid/
> bitcoindev/3b3328b8-bba4-4858-b53a-0e9b631044ffn%40googlegr= oups.com
> <https://groups.g= oogle.com/d/msgid/bitcoindev/3b3328b8-bba4-4858-
> b53a-0e9b631044ffn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>.
--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.=
To view this discussion visit https://groups.google.com/d/msgid/bitcoin= dev/5028df3d-22ec-4a3e-9b54-64a4f1f0cefc%40murch.one.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.co= m/d/msgid/bitcoindev/CAP%2B9vXOVhnCC5fPjK1q9d_gL0%2BoHs1-Gk3p04%3Dw90W6dW1P= bcQ%40mail.gmail.com.
--0000000000008c416b064ece9aa1--