From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 22 Dec 2025 11:48:43 -0800 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vXlta-0001Og-0X for bitcoindev@gnusha.org; Mon, 22 Dec 2025 11:48:43 -0800 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-3f578b8136fsf6113481fac.0 for ; Mon, 22 Dec 2025 11:48:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1766432916; cv=pass; d=google.com; s=arc-20240605; b=HK0VMNlq6J8r77saOLYB1wNrPuT3Z3mz9P1F2HMr5f6WLDTyCFDtl1q3ser6eNoqRn QwWLrL7n9nhikJyQeEraauuC6B6Egahxw602i+NuFfFPR2R50s6b209BuPnvY2kFwQ8b N2x0fubKHA+aC3NbCVL6FzNqeyiKPasV2nIVHWi9Zn+n601otSadEry9z12OjZ06YXNP 5YOTh7gUUAtErCRPIsq+lTqnhJbImivErqKNFHSYSv5HeqUyROMbndxtusGe3TLFeykZ GJxbVuO/LU9VMRD7wQUbfKyFvGl3w+wTIkJRDrzbvMDT1wyWSW8Hpm21BnOYZLVV0WCS Fivg== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=1gM5u02qlDzW2mc5JlK7ZSdtVB4nL+D4ZsL1vdcO+yw=; fh=iS0Z+pq6aenu0qjNk3xllw8w1bEjNvNKSE3X6g7pZgo=; b=Nio0aUQWCIKMfZHvPT1mLXkfOx844tKM0+umi+jvVlagqszv62+IZ4Tm0GnS9kL271 Lu6/1wQPaHkdT4pB5dhttz4IDUYV0RanWYnL9SVC4IMzEn3Uy4IpQzT91BbXszFikHDw b0Y4NYMefg4buuzqdMlBJUi5MYSmMisCV0ifxuJQjlDlCsParRF7X4E6MdeDu8f3ajZ9 w9kOqztN79PzaldHxKnv6v5hd6xG405kj1f9kX6R40Z5uFF0lEa+i4priQQNMdGwlR8w bX23QnJqbrapgPqkV4KxD0dCrP1hhBk5hHEIvpsxtlNwB97fag5SBdknSk/MdGHDG0sh 2U5g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=IKh1h3CT; spf=pass (google.com: domain of cal.defenwycke@gmail.com designates 2607:f8b0:4864:20::b132 as permitted sender) smtp.mailfrom=cal.defenwycke@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=20230601; t=1766432916; x=1767037716; 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=1gM5u02qlDzW2mc5JlK7ZSdtVB4nL+D4ZsL1vdcO+yw=; b=xCZeAlcCwiFWwfS9hxW9qU1gCYBdguqc9d3pgo9As3++Zp6WdNvBIdS0RGe7Rv/X9K fXGMm8LPBYerXjIwn5/UfUDAOyd4mE4FKRpabnk3wxZ1mruNonINF/CLCGMkjpR87282 Xo8Qflao5kcIDKd9ENoPFhZ/EVZjXaCpJQ/CMLDm0LW/ifHevWtb4iRqmvl9caEEMWms g1zORaIjO8ad1A8yeofqC6RH0Y6UBjjQiw9T1ZG6hy6JFSFhA3yZUvgobCC7l1eP2EBt kC3TwtQGBpb0xVQ+znOYEJf1eY8e+i/HsI7CgxPAkG5ncTyVvui646O2mb8jfpjat2Nw WQfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766432916; x=1767037716; 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=1gM5u02qlDzW2mc5JlK7ZSdtVB4nL+D4ZsL1vdcO+yw=; b=Do8F1GerKyeZzreLHaCPaxqkTEB7If4y473bPtSRuEbSTz0sogHtU/2Nt+LgEs3OUL 22npVMpBZkx2v0Y2xRFWNDThuf72Q46v80hLgPyctjHSiWvu8/n2mh/Gkdjd+ULY6+yO fGsAsX3uF7Wii+kcNkVgIzGVT/29ZmuNh1L0mnZFt/jYKEv537Bquig1kVhvUM0Rjoos GnH0i7m10ksWjxtURDTwQESZ5mcC20tjhdjjGW/0Hd6DV3VHT6ulsvUv4Lx88uAkuiIJ K/Iq6XXSPdMjZLCkhBrKF4BbyEYVwDgMo1bYpVYWhNlEiz3GIkIWH/9w1moLYxojxsGi Vysw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766432916; x=1767037716; 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=1gM5u02qlDzW2mc5JlK7ZSdtVB4nL+D4ZsL1vdcO+yw=; b=Tdddddvesl2uzeDKH6wZqggvR307mOi7D3LQ0uAnW86oqhGRvRpVPEltsyMXRuuhqb QvRBqNg8AzVEDAjRaXNhcbXta7tMdbGc/g4XB08O5i4hULxjgbsDiZN9obJijrH3fquG 0+BeJbMD6Qq322g4iS8Nj3E942LwqHCAbXl940PbhPyfCenKWtPF1VsI306FZ0/TzALg VAT1EJ/H1TLkjNvu7h/pMMcU1cHZK5it1kptPXbHlPLJZId2GTRonAW7bvzxM3a6YuaH ZthYG1b2EroOmD5BhftM7kLd69kj3KJVE+gZtqD+UJdkyQ/WDuKlZgrPaZQgdrLuNDmm LsIw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWvC/Ml+pxOkpPr6r/qUmxvr6RCp/2HYUYcqd32KT1LTif/JJYQNsC+JIBRgPU/Ee0KWnFZokJVSCVw@gnusha.org X-Gm-Message-State: AOJu0YyLJ55DfuGQ5ZLVkF62ccS6zFPuTB5fcM8WPbbhFyu64akyJSoq aGwktyWZj9+vzv+gOvnIEQrL8yHBa28jM2Sbq2UsvPNnQMid8bKtFl6Z X-Google-Smtp-Source: AGHT+IGNwZqNbr4Jfex5bZ0jq02Bmho+1dzGiA9BHRLrwUxCuiYF4Q0r3QgQLEKaT5Ep+41VHzwpcw== X-Received: by 2002:a05:6871:6a9:b0:2d5:ba2d:80df with SMTP id 586e51a60fabf-3fda560d663mr5671005fac.8.1766432915370; Mon, 22 Dec 2025 11:48:35 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYTmncILYtQn+C3k5aMqjHLHBlAl9ZC59VltGcPGwTmhQ==" Received: by 2002:a05:6870:164a:b0:3ec:4eb6:abba with SMTP id 586e51a60fabf-3f5f877fc23ls5845601fac.1.-pod-prod-05-us; Mon, 22 Dec 2025 11:48:31 -0800 (PST) X-Received: by 2002:a05:6808:1805:b0:457:a9bc:dbe5 with SMTP id 5614622812f47-457b21f4029mr5314261b6e.42.1766432911511; Mon, 22 Dec 2025 11:48:31 -0800 (PST) Received: by 2002:a05:6808:4a59:20b0:44f:fe66:38a2 with SMTP id 5614622812f47-457b2896d2emsb6e; Mon, 22 Dec 2025 11:33:14 -0800 (PST) X-Received: by 2002:a05:6830:2e03:b0:7c7:266:392d with SMTP id 46e09a7af769-7cc668bb792mr7462240a34.13.1766431993226; Mon, 22 Dec 2025 11:33:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1766431993; cv=none; d=google.com; s=arc-20240605; b=cBVXHm54nZKY8G453fkLL2tYGJL3ALXE61xNpoL8m+eQy2zbfr6dijnKLPhf6Ac2ac LtDkmvzCVaVR6gm5r2OqQRu30o+BjkHG/6GsgKKYeTAqEv6FQ0kYYF8mcnHJdhdrtrf0 Dq/VrfmkWmwVLutbEGN6SwH88ctscmkat2QrfTVdPnGgz5CXPlwF2UfIBZkJL/fNfGVH 1z1f29l+kAjTf0wv/wqKJEl+KbiIVCBoN5CZjxeSe1myEeg6QlbHSlufpXCS0LxTFVrH su6nxanJy6DByHu59xu3mFR66cKzjoKBZ5wXGKOUDiQfjqgZPZCnWwOaZ/jsZSthm2rV iZAQ== 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=KH/f+xOaBDJRMMIgizh9RZijbsiT7+zlhloKj/fdGqM=; fh=VafBKbm81sMdCBhZa8cNxSRP186+dHuRkgnGxcDOwXg=; b=bkTgEAKumGRDAJ7oiwgLLGj0vSNgbO0xymEH9YAjXNMVls9Z8PUmHlGmD7wzojOmcQ un931bb9RjY75WRqbwE/ChMJNsZY6y6yIWW8d9m2Q/fin1Nf25eeBsh4C5n2dmKzqVal PKUeA6kZCJl9f4eQnfNWGZ/SyWwNZsS5FBcFTqpjwekdi3ml4NfT1iRmlS6sCPLPz0SG xSxb9nx/HCLcrJNOTFc/mjzcDDGclUFxOvtH4OnWxj46ivOq6xwt2Jt4c6isb5ClVNJ5 2YvJXv2VpIQUKGo+bKF9GlRqyhLQJU7NddKsU0ICocU5iyE1XE87ZD7yA6NUzt3oBALD HGgw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=IKh1h3CT; spf=pass (google.com: domain of cal.defenwycke@gmail.com designates 2607:f8b0:4864:20::b132 as permitted sender) smtp.mailfrom=cal.defenwycke@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yx1-xb132.google.com (mail-yx1-xb132.google.com. [2607:f8b0:4864:20::b132]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-7cc667b5952si979326a34.3.2025.12.22.11.33.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Dec 2025 11:33:13 -0800 (PST) Received-SPF: pass (google.com: domain of cal.defenwycke@gmail.com designates 2607:f8b0:4864:20::b132 as permitted sender) client-ip=2607:f8b0:4864:20::b132; Received: by mail-yx1-xb132.google.com with SMTP id 956f58d0204a3-6467c5acb7dso1213705d50.1 for ; Mon, 22 Dec 2025 11:33:13 -0800 (PST) X-Gm-Gg: AY/fxX4KejZfXWSVdJ2AIVB8KtSziirr7TS1/cxS2hftHTahHNcAd+eVyk9pZAKluhn L0VqlX6R7oE/OFW0fE1brI9gs/rxuIUWxFyRCbNqb8R0s7hn46+DYmpqXBS4YVVWwsvKfrsz2c3 2wuuHz2dXMGLQinNwd6ATKg3nsjvPboMwjDAIrtyW1QjRTHuXTsbYbey5+TSWHehUKjmhPcR9qb G5BAMd0pLsHuwdGDJrUVH1fxVi+1RDdoVR0RYgDDSdW2ADFPZDOk+cQuFPft+G5usTX9NKgFT48 DQ44GETcR62lRZmL/U6MR+uZawY1s+w0iis9XQ4= X-Received: by 2002:a53:bb04:0:b0:644:4a95:c15 with SMTP id 956f58d0204a3-6466a8d7fbcmr7101230d50.80.1766431992501; Mon, 22 Dec 2025 11:33:12 -0800 (PST) MIME-Version: 1.0 References: <02d7368e-95d3-4185-b70f-3aa9b5df1e1d@murch.one> <841d6882-9853-4d96-84e8-c4742e17e969n@googlegroups.com> <3344ee13-ccd9-4f72-baa8-f420f74199b3@murch.one> In-Reply-To: <3344ee13-ccd9-4f72-baa8-f420f74199b3@murch.one> From: Defenwycke Date: Mon, 22 Dec 2025 19:33:01 +0000 X-Gm-Features: AQt7F2pyKMEvEXa88ppEVPCcbqEUmFuvsI0GrvOqgvvKG6FCRvHGFj7yNlCIcJE Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Bbitcoindev=5D_Draft_BIP=3A_DustSweep_=E2=80=93_policy=2Donl?= =?UTF-8?Q?y_UTXO_dust_compaction?= To: Murch Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006ed89206468f7f0a" X-Original-Sender: cal.defenwycke@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=IKh1h3CT; spf=pass (google.com: domain of cal.defenwycke@gmail.com designates 2607:f8b0:4864:20::b132 as permitted sender) smtp.mailfrom=cal.defenwycke@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 (/) --0000000000006ed89206468f7f0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Murch. Thanks for taking the time to follow up and for spelling out the incentive concerns so clearly. You=E2=80=99re right - the recent reduction of the default minimum relay fe= erate to 0.1 sat/vB materially changes the economic backdrop I was assuming. Under those conditions, most consolidation is already cheap enough that a protocol- or policy-level mechanism no longer makes sense, and the remaining friction is better addressed at the wallet/UX layer rather than through miner or relay rules. I agree with your point that Bitcoin policy should not rely on miners selling blockspace below market value, and that any mechanism that only encourages behavior without enforceable constraints is unlikely to be justified. I=E2=80=99m going to step back from this direction and reconsider the probl= em in a different scope. I appreciate the careful read and the candid feedback. it was helpful in clarifying where the real boundary lies. Kind regards Defenwycke On Mon, 22 Dec 2025 at 19:06, Murch wrote: > Hi Defenwycke, > > You replied to every line of my email, except the most relevant one. > > Murch wrote: > > All that said, at the new minimum feerate of 0.1=E2=80=AFs/vB, a 148= =E2=80=AFvB P2PKH > input costs 15=E2=80=AFsats, a 68 vB P2WPKH input costs 7 sats, and a 57.= 5 vB > P2TR input costs 6 sats. > > Your proposal prescribes an entire new class of transactions that are > managed by separate rules in a separate data structure. You propose to > charge 5=E2=80=AFsats per input for those transactions, and prescribe tha= t > miners should include such transactions even when they lose money by > doing so: at elevated feerates. Especially at high feerates, it is > irrational for miners to follow your proposal of selling blockspace > below value. > > This idea is made completely obsolete by the recent lowering of the new > minimum feerate. The most common inputs (P2WPKH) only cost <7=E2=80=AFsat= s at > the new minimum feerate, and the ones that make up the biggest portion > of the UTXO set only costs <6=E2=80=AFsats at the new minimum feerate. At= low > feerates, your proposal provides negligible benefits to senders compared > to the status quo. > > Defenwycke wrote: > > Using current standard input sizes (=E2=89=8868 vB for P2WPKH, =E2=89= =8857.5 vB for > P2TR keypath, =E2=89=88148 vB for P2PKH), the break-even spend cost quick= ly > rises into the hundreds of sats once fee rates exceed a few sat/vB. At > more common feerates (=E2=89=885=E2=80=9310 sat/vB), outputs below roughl= y 500=E2=80=931500 sats > are rationally abandoned depending on script type. > > The mempool has been routinely clearing down to 0.2=E2=80=AFs/vB in the p= ast > months. Inputs spending low amount P2TR UTXOs of =E2=80=9C500=E2=80=93150= 0 sats=E2=80=9D cost > 0.8=E2=80=932.4% of their value at such feerates. I don=E2=80=99t see how= getting back > ~98% of the value translates to =E2=80=9Cit being rational to abandon suc= h UTXOs=E2=80=9D. > > This proposal seems rather laborious and complex, and I sincerely cannot > see much benefit. If you want to incentivize people to consolidate their > UTXOs, you have to design something where the incentives work out for > both the producers and the consumers of blockspace. FWIW, it seems to me > that people would already have a financial incentive to do so right now, > so, perhaps you should first try to find out why they don=E2=80=99t alrea= dy. > > Murch > > > On 2025-12-13 06:56, defenwycke wrote: > > Hello Murch, > > > > Thanks for the thoughtful response. Please find my response below. > > > > > What does =E2=80=9Cdust-class=E2=80=9D mean? Are you using the Bitco= in Core dust > > limit or talking about small amounts in general? I don=E2=80=99t have f= igures > > off the top of my head, but I would assume that there are relatively fe= w > > UTXOs smaller than BitcoinCore=E2=80=99s dust limit. > > > > I=E2=80=99m not referring to Bitcoin Core=E2=80=99s relay dust limits h= ere. By =E2=80=9Cdust- > > class=E2=80=9D I mean outputs that are economically irrational to spend= under > > typical fee conditions, even though they remain technically valid. Usin= g > > current standard input sizes (=E2=89=8868 vB for P2WPKH, =E2=89=8857.5 = vB for P2TR > > keypath, =E2=89=88148 vB for P2PKH), the break-even spend cost quickly = rises > > into the hundreds of sats once fee rates exceed a few sat/vB. At more > > common feerates (=E2=89=885=E2=80=9310 sat/vB), outputs below roughly 5= 00=E2=80=931500 sats are > > rationally abandoned depending on script type. So this is an economic > > classification, not a relay-policy one. > > > > > You might want to clarify that you mean only P2TR KP inputs. Or woul= d > > P2TR SP be permitted? > > > > Yes =E2=80=94 only P2TR key-path spends would be permitted. Script-path= spends > > would be excluded. I=E2=80=99ll make that explicit. > > > > > It would be a lot of work to have a separate pool for this, and I > > don=E2=80=99t see a reason why they couldn=E2=80=99t just go in the reg= ular mempool. > > > > Agreed. A physically separate mempool is not required. The intent is > > simply that these transactions sit at the very bottom of the normal > > mempool=E2=80=99s priority ordering and are treated as lowest priority = for > > eviction and inclusion > > > > > That said, at 50% full, there are still around ~30 blocks worth of > > transactions waiting in the mempool that pay fees, =E2=80=A6 > > > > Right - and DustSweep is not intended to provide any liveness guarantee= s > > in that situation. These transactions are explicitly opportunistic and > > are expected to idle or expire during sustained congestion. That > > behaviour is acceptable and consistent with the goal of ensuring they > > never compete with fee-paying transactions. The 50% figure was meant as > > an illustrative policy threshold, not a claim that blockspace is > > otherwise unused. > > > > > =E2=80=A6the only ones I have seen lately are miners using a minimum= feerate > > of 1 s/vB for their block templates. > > > > That aligns with the intent. DustSweep transactions would only ever be > > eligible after normal block assembly, and only in templates that alread= y > > include all available fee-paying transactions. > > > > > I assume the intention is to only relay these transactions when ther= e > > are blocks that aren=E2=80=99t full, to limit the bandwidth-wasting vec= tor this > > feature introduces, but overall it seems to me that it would be most > > likely for such transactions to sit in nodes=E2=80=99 memory until they= expire. > > > > That=E2=80=99s a fair characterization, and it matches the design goals= . To > > further limit policy complexity and relay churn, DustSweep transactions > > would also be constrained to: > > > > - Confirmed inputs only (no unconfirmed ancestors > > > > - RBF disabled (no replacement or package churn) > > > > - No CPFP assumptions > > > > This keeps them cheap to reason about for node operators, and expiry > > without confirmation is an expected outcome rather than a failure mode. > > Importantly, these constraints mean DustSweep transactions require no > > additional mempool state tracking, package evaluation, or replacement > > logic beyond what nodes already implement today. > > > > > It doesn=E2=80=99t seem obvious to me that saving a few dozen sats w= ould > > greatly foster the users=E2=80=99 urge to consolidate. It feels like a = lot of > > overhead for such a small incentive to the users, and relying on the > > miners to give away blockspace below market value feels a bit optimisti= c > > as well. > > > > I agree that the incentive is not primarily about recovering value. > > Empirically, outputs in this range represent a large number of UTXOs bu= t > > very little aggregate bitcoin value. Even aggressive consolidation woul= d > > recover well under a single BTC in total. The motivation is instead > > about long-term UTXO set hygiene: providing a narrow, predictable > > mechanism for compacting outputs that are otherwise rationally > > abandoned, without displacing market transactions or altering fee > > dynamics. Because the economic value involved is small, the mechanism i= s > > intentionally constrained to avoid creating meaningful incentives for > > either users or miners to game block construction or relay policy. The > > benefit is therefore not measured in recovered bitcoin value, but in > > avoided long-term UTXO growth and reduced steady-state resource costs > > for nodes. > > > > Separately (and not a dependency of this proposal), public analysis of > > inscription-related activity shows that a significant share of UTXO > > growth is tied to metadata-heavy patterns. Future work on segregated > > data lanes could allow voluntary compaction of those UTXOs while > > preserving metadata, but that=E2=80=99s orthogonal to DustSweep itself. > > > > Kind regards, > > > > Defenwycke > > > > > > On Friday, December 12, 2025 at 11:19:17=E2=80=AFPM UTC Murch wrote: > > > > Hey Defenwycke, > > > > > all inputs are =E2=80=9Cdust-class=E2=80=9D UTXOs > > > > What does =E2=80=9Cdust-class=E2=80=9D mean? Are you using the Bitc= oin Core dust > limit > > or talking about small amounts in general? I don=E2=80=99t have fig= ures off > the > > top of my head, but I would assume that there are relatively few > UTXOs > > smaller than Bitcoin Core=E2=80=99s dust limit. > > > > > only standard scripts (P2PKH / P2WPKH / P2TR) > > > > You might want to clarify that you mean only P2TR KP inputs. Or wou= ld > > P2TR SP be permitted? > > > > > Nodes place these in a small, separate sub-mempool. They=E2=80= =99re only > > > accepted when the normal mempool is <50% full, and they=E2=80=99= re > > > automatically evicted if normal mempool usage hits 95%. > > > > It would be a lot of work to have a separate pool for this, and I > don=E2=80=99t > > see a reason why they couldn=E2=80=99t just go in the regular mempo= ol. If the > > mempool fills up, they=E2=80=99d have the lowest feerates and they= =E2=80=99d get > kicked > > out first anyway. That said, at 50% full, there are still around ~3= 0 > > blocks worth of transactions waiting in the mempool that pay fees, = =E2=80=A6 > > > > > Miners can include them up to a small weight fraction (I suggest > > ~5%) > > but only after filling the block with regular fee-paying > transactions. > > > > =E2=80=A6 so if they are only considered in blocks that aren=E2=80= =99t full, the only > > ones I have seen lately are miners using a minimum feerate of 1=E2= =80=AFs/vB > > for > > their block templates. Looking at some popular mempool statistic > sites, > > in the past 32 months, there would have only been organically > non-full > > blocks between April and August this year. > > > > I assume the intention is to only relay these transactions when the= re > > are blocks that aren=E2=80=99t full, to limit the bandwidth-wasting= vector > this > > feature introduces, but overall it seems to me that it would be mos= t > > likely for such transactions to sit in nodes=E2=80=99 memory until = they > expire. > > > > All that said, at the new minimum feerate of 0.1=E2=80=AFs/vB, a 14= 8=E2=80=AFvB P2PKH > > input costs 15=E2=80=AFsats, a 68 vB P2WPKH input costs 7 sats, and= a 57.5 vB > > P2TR input costs 6 sats. It doesn=E2=80=99t seem obvious to me that= saving a > > few > > dozen sats would greatly foster the users=E2=80=99 urge to consolid= ate. It > > feels > > like a lot of overhead for such a small incentive to the users, and > > relying on the miners to give away blockspace below market value > > feels a > > bit optimistic as well. > > > > Cheers, > > Murch > > > > On 2025-12-11 04:53, defenwycke wrote: > > > Hello list, > > > > > > I=E2=80=99ve been working on a small policy proposal that aims t= o address > > one > > > very specific problem: the long-term accumulation of uneconomica= l > > dust > > > in the UTXO set. > > > > > > The idea is intentionally narrow. I=E2=80=99m calling it DustSwe= ep, and it > > > defines a strict, non-abusable class of transactions that nodes > may > > > relay and miners may include only when the mempool and block > > space are > > > underutilised. The goal is to give wallets a predictable way to > > compact > > > dust without introducing new spam vectors or touching consensus. > > > > > > A DustSweep transaction has the following properties: > > > > > > * > > > > > > all inputs are =E2=80=9Cdust-class=E2=80=9D UTXOs > > > > > > * > > > > > > only standard scripts (P2PKH / P2WPKH / P2TR) > > > > > > * > > > > > > exactly one output > > > > > > * > > > > > > no metadata at all (no OP_RETURN, inscriptions, TLVs, etc.) > > > > > > * > > > > > > minimum of 5 inputs (to ensure meaningful UTXO reduction) > > > > > > * > > > > > > size capped > > > > > > * > > > > > > it pays a flat 1 sat per input fee > > > > > > Nodes place these in a small, separate sub-mempool. They=E2=80= =99re only > > > accepted when the normal mempool is <50% full, and they=E2=80=99= re > > automatically > > > evicted if normal mempool usage hits 95%. Miners can include the= m > > up to > > > a small weight fraction (I suggest ~5%) but only after filling > > the block > > > with regular fee-paying transactions. The intention is that > > DustSweep > > > never competes with the fee market and only uses blockspace that > > would > > > otherwise go unused. > > > > > > This is all policy-level. No consensus changes, no new transacti= on > > > format, nothing that affects validation. Nodes that don=E2=80=99= t > > implement it > > > simply treat these as low-fee transactions and drop them. > > > > > > The motivation is straightforward: we don=E2=80=99t currently ha= ve a safe, > > > structured way to compact dust, and the UTXO set continues to > > grow from > > > outputs that are effectively unspendable under normal fee > > conditions. > > > DustSweep tries to offer a predictable, opt-in mechanism for > > wallets to > > > clean that up without creating any new attack surface. > > > > > > Full draft BIP and supporting documents are here: > > > > > > https://github.com/defenwycke/bip-dust-sweep > defenwycke/bip-dust-sweep> > > > > > > I=E2=80=99d appreciate feedback on the policy details, threshold= s, and > > whether > > > this fits within what node operators and wallet developers would > > > actually want to use. Happy to adjust parameters if there=E2=80= =99s a > better > > > balance point. > > > > > > Kind regards, > > > > > > Defenwycke > > > > > > -- > > > 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+...@googlegroups.com > > > . > > > To view this discussion visit https://groups.google.com/d/msgid/ > > > > > bitcoindev/b47aa182-bca7-44d7-bed1- > > f3cc2df30ef5n%40googlegroups.com > > > > bed1- > bca7-44d7-bed1-> > > > f3cc2df30ef5n%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/841d6882-9853-4d96-84e8-c4742e17e969n%40googlegroups.com > > > c4742e17e969n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter= >. > > --=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/= CAOj3_X8cJLJChvv3-QSGA8j5MVwgYxn1BAUeugTTgiqUWzEK_Q%40mail.gmail.com. --0000000000006ed89206468f7f0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Hello Murch.

=
Tha= nks for taking the time to follow up and for spelling out the incentive con= cerns so clearly.

You= =E2=80=99re right - the recent reduction of the default minimum relay feera= te to 0.1 sat/vB materially changes the economic backdrop I was assuming. U= nder those conditions, most consolidation is already cheap enough that a pr= otocol- or policy-level mechanism no longer makes sense, and the remaining = friction is better addressed at the wallet/UX layer rather than through min= er or relay rules.

I ag= ree with your point that Bitcoin policy should not rely on miners selling b= lockspace below market value, and that any mechanism that only encourages b= ehavior without enforceable constraints is unlikely to be justified.

I=E2=80=99m going to step bac= k from this direction and reconsider the problem in a different scope. I ap= preciate the careful read and the candid feedback.=C2=A0it was helpful in c= larifying where the real boundary lies.

Kind regards

Defenwycke
=C2=A0

On Mon, 22 Dec 2025 at 19:06, Murch <murch@murch.one>= wrote:
Hi Defenwycke,

You replied to every line of my email, except the most relevant one.

Murch wrote:
=C2=A0> All that said, at the new minimum feerate of 0.1=E2=80=AFs/vB, a= 148=E2=80=AFvB P2PKH
input costs 15=E2=80=AFsats, a 68 vB P2WPKH input costs 7 sats, and a 57.5 = vB
P2TR input costs 6 sats.

Your proposal prescribes an entire new class of transactions that are
managed by separate rules in a separate data structure. You propose to
charge 5=E2=80=AFsats per input for those transactions, and prescribe that =
miners should include such transactions even when they lose money by
doing so: at elevated feerates. Especially at high feerates, it is
irrational for miners to follow your proposal of selling blockspace
below value.

This idea is made completely obsolete by the recent lowering of the new minimum feerate. The most common inputs (P2WPKH) only cost <7=E2=80=AFsa= ts at
the new minimum feerate, and the ones that make up the biggest portion
of the UTXO set only costs <6=E2=80=AFsats at the new minimum feerate. A= t low
feerates, your proposal provides negligible benefits to senders compared to the status quo.

Defenwycke wrote:
=C2=A0> Using current standard input sizes (=E2=89=8868 vB for P2WPKH, = =E2=89=8857.5 vB for
P2TR keypath, =E2=89=88148 vB for P2PKH), the break-even spend cost quickly=
rises into the hundreds of sats once fee rates exceed a few sat/vB. At
more common feerates (=E2=89=885=E2=80=9310 sat/vB), outputs below roughly = 500=E2=80=931500 sats
are rationally abandoned depending on script type.

The mempool has been routinely clearing down to 0.2=E2=80=AFs/vB in the pas= t
months. Inputs spending low amount P2TR UTXOs of =E2=80=9C500=E2=80=931500 = sats=E2=80=9D cost
0.8=E2=80=932.4% of their value at such feerates. I don=E2=80=99t see how g= etting back
~98% of the value translates to =E2=80=9Cit being rational to abandon such = UTXOs=E2=80=9D.

This proposal seems rather laborious and complex, and I sincerely cannot see much benefit. If you want to incentivize people to consolidate their UTXOs, you have to design something where the incentives work out for
both the producers and the consumers of blockspace. FWIW, it seems to me that people would already have a financial incentive to do so right now, so, perhaps you should first try to find out why they don=E2=80=99t already= .

Murch


On 2025-12-13 06:56, defenwycke wrote:
> Hello Murch,
>
> Thanks for the thoughtful response. Please find my response below.
>
>=C2=A0 > What does =E2=80=9Cdust-class=E2=80=9D mean? Are you using = the Bitcoin Core dust
> limit or talking about small amounts in general? I don=E2=80=99t have = figures
> off the top of my head, but I would assume that there are relatively f= ew
> UTXOs smaller than BitcoinCore=E2=80=99s dust limit.
>
> I=E2=80=99m not referring to Bitcoin Core=E2=80=99s relay dust limits = here. By =E2=80=9Cdust-
> class=E2=80=9D I mean outputs that are economically irrational to spen= d under
> typical fee conditions, even though they remain technically valid. Usi= ng
> current standard input sizes (=E2=89=8868 vB for P2WPKH, =E2=89=8857.5= vB for P2TR
> keypath, =E2=89=88148 vB for P2PKH), the break-even spend cost quickly= rises
> into the hundreds of sats once fee rates exceed a few sat/vB. At more =
> common feerates (=E2=89=885=E2=80=9310 sat/vB), outputs below roughly = 500=E2=80=931500 sats are
> rationally abandoned depending on script type. So this is an economic =
> classification, not a relay-policy one.
>
>=C2=A0 > You might want to clarify that you mean only P2TR KP inputs= . Or would
> P2TR SP be permitted?
>
> Yes =E2=80=94 only P2TR key-path spends would be permitted. Script-pat= h spends
> would be excluded. I=E2=80=99ll make that explicit.
>
>=C2=A0 > It would be a lot of work to have a separate pool for this,= and I
> don=E2=80=99t see a reason why they couldn=E2=80=99t just go in the re= gular mempool.
>
> Agreed. A physically separate mempool is not required. The intent is <= br> > simply that these transactions sit at the very bottom of the normal > mempool=E2=80=99s priority ordering and are treated as lowest priority= for
> eviction and inclusion
>
>=C2=A0 > That said, at 50% full, there are still around ~30 blocks w= orth of
> transactions waiting in the mempool that pay fees, =E2=80=A6
>
> Right - and DustSweep is not intended to provide any liveness guarante= es
> in that situation. These transactions are explicitly opportunistic and=
> are expected to idle or expire during sustained congestion. That
> behaviour is acceptable and consistent with the goal of ensuring they =
> never compete with fee-paying transactions. The 50% figure was meant a= s
> an illustrative policy threshold, not a claim that blockspace is
> otherwise unused.
>
>=C2=A0 > =E2=80=A6the only ones I have seen lately are miners using = a minimum feerate
> of 1 s/vB for their block templates.
>
> That aligns with the intent. DustSweep transactions would only ever be=
> eligible after normal block assembly, and only in templates that alrea= dy
> include all available fee-paying transactions.
>
>=C2=A0 > I assume the intention is to only relay these transactions = when there
> are blocks that aren=E2=80=99t full, to limit the bandwidth-wasting ve= ctor this
> feature introduces, but overall it seems to me that it would be most <= br> > likely for such transactions to sit in nodes=E2=80=99 memory until the= y expire.
>
> That=E2=80=99s a fair characterization, and it matches the design goal= s. To
> further limit policy complexity and relay churn, DustSweep transaction= s
> would also be constrained to:
>
> - Confirmed inputs only (no unconfirmed ancestors
>
> - RBF disabled (no replacement or package churn)
>
> - No CPFP assumptions
>
> This keeps them cheap to reason about for node operators, and expiry <= br> > without confirmation is an expected outcome rather than a failure mode= .
> Importantly, these constraints mean DustSweep transactions require no =
> additional mempool state tracking, package evaluation, or replacement =
> logic beyond what nodes already implement today.
>
>=C2=A0 > It doesn=E2=80=99t seem obvious to me that saving a few doz= en sats would
> greatly foster the users=E2=80=99 urge to consolidate. It feels like a= lot of
> overhead for such a small incentive to the users, and relying on the <= br> > miners to give away blockspace below market value feels a bit optimist= ic
> as well.
>
> I agree that the incentive is not primarily about recovering value. > Empirically, outputs in this range represent a large number of UTXOs b= ut
> very little aggregate bitcoin value. Even aggressive consolidation wou= ld
> recover well under a single BTC in total. The motivation is instead > about long-term UTXO set hygiene: providing a narrow, predictable
> mechanism for compacting outputs that are otherwise rationally
> abandoned, without displacing market transactions or altering fee
> dynamics. Because the economic value involved is small, the mechanism = is
> intentionally constrained to avoid creating meaningful incentives for =
> either users or miners=C2=A0to game block construction or relay policy= . The
> benefit is therefore not measured in recovered bitcoin value, but in <= br> > avoided long-term UTXO growth and reduced steady-state resource costs =
> for nodes.
>
> Separately (and not a dependency of this proposal), public analysis of=
> inscription-related activity shows that a significant share of UTXO > growth is tied to metadata-heavy patterns. Future work on segregated <= br> > data lanes could allow voluntary compaction of those UTXOs while
> preserving metadata, but that=E2=80=99s orthogonal to DustSweep itself= .
>
> Kind regards,
>
> Defenwycke
>
>
> On Friday, December 12, 2025 at 11:19:17=E2=80=AFPM UTC Murch wrote: >
>=C2=A0 =C2=A0 =C2=A0Hey Defenwycke,
>
>=C2=A0 =C2=A0 =C2=A0 > all inputs are =E2=80=9Cdust-class=E2=80=9D U= TXOs
>
>=C2=A0 =C2=A0 =C2=A0What does =E2=80=9Cdust-class=E2=80=9D mean? Are yo= u using the Bitcoin Core dust limit
>=C2=A0 =C2=A0 =C2=A0or talking about small amounts in general? I don=E2= =80=99t have figures off the
>=C2=A0 =C2=A0 =C2=A0top of my head, but I would assume that there are r= elatively few UTXOs
>=C2=A0 =C2=A0 =C2=A0smaller than Bitcoin Core=E2=80=99s dust limit.
>
>=C2=A0 =C2=A0 =C2=A0 > only standard scripts (P2PKH / P2WPKH / P2TR)=
>
>=C2=A0 =C2=A0 =C2=A0You might want to clarify that you mean only P2TR K= P inputs. Or would
>=C2=A0 =C2=A0 =C2=A0P2TR SP be permitted?
>
>=C2=A0 =C2=A0 =C2=A0 > Nodes place these in a small, separate sub-me= mpool. They=E2=80=99re only
>=C2=A0 =C2=A0 =C2=A0 > accepted when the normal mempool is <50% f= ull, and they=E2=80=99re
>=C2=A0 =C2=A0 =C2=A0 > automatically evicted if normal mempool usage= hits 95%.
>
>=C2=A0 =C2=A0 =C2=A0It would be a lot of work to have a separate pool f= or this, and I don=E2=80=99t
>=C2=A0 =C2=A0 =C2=A0see a reason why they couldn=E2=80=99t just go in t= he regular mempool. If the
>=C2=A0 =C2=A0 =C2=A0mempool fills up, they=E2=80=99d have the lowest fe= erates and they=E2=80=99d get kicked
>=C2=A0 =C2=A0 =C2=A0out first anyway. That said, at 50% full, there are= still around ~30
>=C2=A0 =C2=A0 =C2=A0blocks worth of transactions waiting in the mempool= that pay fees, =E2=80=A6
>
>=C2=A0 =C2=A0 =C2=A0 > Miners can include them up to a small weight = fraction (I suggest
>=C2=A0 =C2=A0 =C2=A0~5%)
>=C2=A0 =C2=A0 =C2=A0but only after filling the block with regular fee-p= aying transactions.
>
>=C2=A0 =C2=A0 =C2=A0=E2=80=A6 so if they are only considered in blocks = that aren=E2=80=99t full, the only
>=C2=A0 =C2=A0 =C2=A0ones I have seen lately are miners using a minimum = feerate of 1=E2=80=AFs/vB
>=C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0their block templates. Looking at some popular memp= ool statistic sites,
>=C2=A0 =C2=A0 =C2=A0in the past 32 months, there would have only been o= rganically non-full
>=C2=A0 =C2=A0 =C2=A0blocks between April and August this year.
>
>=C2=A0 =C2=A0 =C2=A0I assume the intention is to only relay these trans= actions when there
>=C2=A0 =C2=A0 =C2=A0are blocks that aren=E2=80=99t full, to limit the b= andwidth-wasting vector this
>=C2=A0 =C2=A0 =C2=A0feature introduces, but overall it seems to me that= it would be most
>=C2=A0 =C2=A0 =C2=A0likely for such transactions to sit in nodes=E2=80= =99 memory until they expire.
>
>=C2=A0 =C2=A0 =C2=A0All that said, at the new minimum feerate of 0.1=E2= =80=AFs/vB, a 148=E2=80=AFvB P2PKH
>=C2=A0 =C2=A0 =C2=A0input costs 15=E2=80=AFsats, a 68 vB P2WPKH input c= osts 7 sats, and a 57.5 vB
>=C2=A0 =C2=A0 =C2=A0P2TR input costs 6 sats. It doesn=E2=80=99t seem ob= vious to me that saving a
>=C2=A0 =C2=A0 =C2=A0few
>=C2=A0 =C2=A0 =C2=A0dozen sats would greatly foster the users=E2=80=99 = urge to consolidate. It
>=C2=A0 =C2=A0 =C2=A0feels
>=C2=A0 =C2=A0 =C2=A0like a lot of overhead for such a small incentive t= o the users, and
>=C2=A0 =C2=A0 =C2=A0relying on the miners to give away blockspace below= market value
>=C2=A0 =C2=A0 =C2=A0feels a
>=C2=A0 =C2=A0 =C2=A0bit optimistic as well.
>
>=C2=A0 =C2=A0 =C2=A0Cheers,
>=C2=A0 =C2=A0 =C2=A0Murch
>
>=C2=A0 =C2=A0 =C2=A0On 2025-12-11 04:53, defenwycke wrote:
>=C2=A0 =C2=A0 =C2=A0 > Hello list,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I=E2=80=99ve been working on a small policy p= roposal that aims to address
>=C2=A0 =C2=A0 =C2=A0one
>=C2=A0 =C2=A0 =C2=A0 > very specific problem: the long-term accumula= tion of uneconomical
>=C2=A0 =C2=A0 =C2=A0dust
>=C2=A0 =C2=A0 =C2=A0 > in the UTXO set.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The idea is intentionally narrow. I=E2=80=99m= calling it DustSweep, and it
>=C2=A0 =C2=A0 =C2=A0 > defines a strict, non-abusable class of trans= actions that nodes may
>=C2=A0 =C2=A0 =C2=A0 > relay and miners may include only when the me= mpool and block
>=C2=A0 =C2=A0 =C2=A0space are
>=C2=A0 =C2=A0 =C2=A0 > underutilised. The goal is to give wallets a = predictable way to
>=C2=A0 =C2=A0 =C2=A0compact
>=C2=A0 =C2=A0 =C2=A0 > dust without introducing new spam vectors or = touching consensus.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > A DustSweep transaction has the following pro= perties:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > all inputs are =E2=80=9Cdust-class=E2=80=9D U= TXOs
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > only standard scripts (P2PKH / P2WPKH / P2TR)=
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > exactly one output
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > no metadata at all (no OP_RETURN, inscription= s, TLVs, etc.)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > minimum of 5 inputs (to ensure meaningful UTX= O reduction)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > size capped
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > *
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > it pays a flat 1 sat per input fee
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Nodes place these in a small, separate sub-me= mpool. They=E2=80=99re only
>=C2=A0 =C2=A0 =C2=A0 > accepted when the normal mempool is <50% f= ull, and they=E2=80=99re
>=C2=A0 =C2=A0 =C2=A0automatically
>=C2=A0 =C2=A0 =C2=A0 > evicted if normal mempool usage hits 95%. Min= ers can include them
>=C2=A0 =C2=A0 =C2=A0up to
>=C2=A0 =C2=A0 =C2=A0 > a small weight fraction (I suggest ~5%) but o= nly after filling
>=C2=A0 =C2=A0 =C2=A0the block
>=C2=A0 =C2=A0 =C2=A0 > with regular fee-paying transactions. The int= ention is that
>=C2=A0 =C2=A0 =C2=A0DustSweep
>=C2=A0 =C2=A0 =C2=A0 > never competes with the fee market and only u= ses blockspace that
>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0 > otherwise go unused.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > This is all policy-level. No consensus change= s, no new transaction
>=C2=A0 =C2=A0 =C2=A0 > format, nothing that affects validation. Node= s that don=E2=80=99t
>=C2=A0 =C2=A0 =C2=A0implement it
>=C2=A0 =C2=A0 =C2=A0 > simply treat these as low-fee transactions an= d drop them.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The motivation is straightforward: we don=E2= =80=99t currently have a safe,
>=C2=A0 =C2=A0 =C2=A0 > structured way to compact dust, and the UTXO = set continues to
>=C2=A0 =C2=A0 =C2=A0grow from
>=C2=A0 =C2=A0 =C2=A0 > outputs that are effectively unspendable unde= r normal fee
>=C2=A0 =C2=A0 =C2=A0conditions.
>=C2=A0 =C2=A0 =C2=A0 > DustSweep tries to offer a predictable, opt-i= n mechanism for
>=C2=A0 =C2=A0 =C2=A0wallets to
>=C2=A0 =C2=A0 =C2=A0 > clean that up without creating any new attack= surface.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Full draft BIP and supporting documents are h= ere:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > https://github.com/defenwy= cke/bip-dust-sweep <https://github.com/
>=C2=A0 =C2=A0 =C2=A0defenwycke/bip-dust-sweep>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I=E2=80=99d appreciate feedback on the policy= details, thresholds, and
>=C2=A0 =C2=A0 =C2=A0whether
>=C2=A0 =C2=A0 =C2=A0 > this fits within what node operators and wall= et developers would
>=C2=A0 =C2=A0 =C2=A0 > actually want to use. Happy to adjust paramet= ers if there=E2=80=99s a better
>=C2=A0 =C2=A0 =C2=A0 > balance point.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Kind regards,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Defenwycke
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > --
>=C2=A0 =C2=A0 =C2=A0 > You received this message because you are sub= scribed to the Google
>=C2=A0 =C2=A0 =C2=A0 > Groups "Bitcoin Development Mailing List= " group.
>=C2=A0 =C2=A0 =C2=A0 > To unsubscribe from this group and stop recei= ving emails from it,
>=C2=A0 =C2=A0 =C2=A0send
>=C2=A0 =C2=A0 =C2=A0 > an email to bitcoindev+...@googlegroups.com >=C2=A0 =C2=A0 =C2=A0 > <mailto:bitcoindev+...@googlegroups.com>= ;.
>=C2=A0 =C2=A0 =C2=A0 > To view this discussion visit https:= //groups.google.com/d/msgid/
>=C2=A0 =C2=A0 =C2=A0<https://groups.google.com/d/msgid/= >
>=C2=A0 =C2=A0 =C2=A0 > bitcoindev/b47aa182-bca7-44d7-bed1-
>=C2=A0 =C2=A0 =C2=A0f3cc2df30ef5n%40googlegroups.com <http://40g= ooglegroups.com>
>=C2=A0 =C2=A0 =C2=A0 > <ht= tps://groups.google.com/d/msgid/bitcoindev/b47aa182-bca7-44d7-
>=C2=A0 =C2=A0 =C2=A0bed1- <https://grou= ps.google.com/d/msgid/bitcoindev/b47aa182-
>=C2=A0 =C2=A0 =C2=A0bca7-44d7-bed1->
>=C2=A0 =C2=A0 =C2=A0 > f3cc2df30ef5n%40googlegroups.com?
>=C2=A0 =C2=A0 =C2=A0utm_medium=3Demail&utm_source=3Dfooter <http= ://40googlegroups.com?
>=C2=A0 =C2=A0 =C2=A0utm_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
> <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msg= id/
> bitcoindev/841d6882-9853-4d96-84e8-c4742e17e969n%40googlegroups.com
> <https://groups.google.= com/d/msgid/bitcoindev/841d6882-9853-4d96-84e8-
> c4742e17e969n%40googlegroup= s.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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/ms= gid/bitcoindev/CAOj3_X8cJLJChvv3-QSGA8j5MVwgYxn1BAUeugTTgiqUWzEK_Q%40mail.g= mail.com.
--0000000000006ed89206468f7f0a--