From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 22 Dec 2025 11:48:42 -0800 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vXltZ-0001Oc-LM for bitcoindev@gnusha.org; Mon, 22 Dec 2025 11:48:42 -0800 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-3ec76da7aaesf3672667fac.0 for ; Mon, 22 Dec 2025 11:48:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1766432915; cv=pass; d=google.com; s=arc-20240605; b=DNvEzaWsqxRylMhZ2NmoeR2HXVGhmsigf+7oili5EF8VBGPcT9YqBnCmVm0qVx7qey mJyOYo7Oq8TqTPDUjjr/8kW9abk/yQTYJgxk2J+Oaz+gLvtqDq0c8nezFtSF1wI1pZXc va4fJegA+0iyM4GCXLBsu8ManfqDWfd8eKAeb0ggilJ8aPrjv70TVMKdoDjSzlLN1SoM /y87DaiJpOB3oLSW5MkWI41X16QH7MiH2cYQtLLS+SrulD9WSRBNJVVJqQweYFdcry9a vEWdLXAhWLLqm3MVqScGN9IOwPd1fLcFtL2gv938n2A2BZ6J+WvBGt0UEwi2xancfjcL FGrA== 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:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:dkim-signature; bh=AWVJ2kbXsaq2KL5Ic30NYDlaVnwj69PCzxyHmpqAJL4=; fh=M8SMeRxMCgNs9EsFqbB7fwvlXBXljo2Bj+GweVWcMko=; b=AsKRWy9iOT4t5nJECEfTStTmfVM2kK0xGRqIwsiYepWCvn/rZ0FGBtD6/4sEwrSCN2 H3lDj3C5TlqDxf6bg5XOgdk5rZ8hcl0HJrrVRyiPbOMEEB9bJ6TTja/qt/fz6/4ngOIP xVZBRTfeCbJSkMPYvTCy3f4ykxqp7tOxQSrLs6txgjIfbD+igMZHzmZ/cUnwUnxCv6Lh MqyPmyHi/TUYGp2l9XCVVsYUnsdujF8Yymp078kHeZks5GYMeZh0SfqOKUahwuvaLze8 KsmVkhynm2SINmiGPOjOfpzJ3Gqd369XgaXNImu+cfMSzS/X8UHY7H9Xc6LfvSerqHkV 8POg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=MArPjERQ; spf=pass (google.com: domain of murch@murch.one designates 2001:1a50:11:0:c83f:a8ff:fea6:c8da as permitted sender) smtp.mailfrom=murch@murch.one DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1766432915; x=1767037715; 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:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=AWVJ2kbXsaq2KL5Ic30NYDlaVnwj69PCzxyHmpqAJL4=; b=ZlpCVx2rro9v0mUMRDfvyaHxvLChu8ii/RM2HHX09oSk9sl4oM92hI/kneOH5MdRsP klJHdoAiFd8NcGtADQzJqYZZNpLpSuhSZCrbouwuarWIerohW5jScEkq4w/A9gMxfoJO wDYOl6MMYNgf4DFCnGi1WwZntFtP0uo1hKTaidI3MZjeoFpiCsgbxDJvhruCR0d3ST92 AhexVfVgVFVvR/9osooxmTOMF+nTtplt0V7HuwcoN1iSawx90YVkfXx302bxG0gN2Jxe KHn4vIlGlDgVnLmAbMJ9ABFikoxP3RHAz0O+wOReeLQSm6oGKmJjpGLXOvml2t8y3rGW m9gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766432915; x=1767037715; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=AWVJ2kbXsaq2KL5Ic30NYDlaVnwj69PCzxyHmpqAJL4=; b=BHcbWI4BRqZoL1VXnkGsqmO6qkKykV/6VQjFifx7GfHitBeg2lmS0LftIYuKw+Paob 9eJl4GmKsRwjzjOfyfweeysGc5DGMQvAR+IaxLqW8sLC/vcGGF63wQLGlWQ/vCSTS8fl xsMxrRvoERhOa6qHyqOiys1YhcWC62Yyc3MsChwJu0WN9UWfcW183MbT1OhoiIM9nw/k rBtDUytsVDWnsdzqd+jzH1R56y5+8lkxgQFs4i1PJiDQ1Ne/KsEqfaKF4gsJYiDdFknu tQA3GXFhgHO3yIURCrKuTzExRIRA0rMHP8Ku/FfKGuP4rEDdSQKjgeyBLkE7vRsr24QM c2vw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUruDUN4Z0UFgDE1ihDskMXtPHmuN0jjWV8485UVvjkIi6QvbisOFlrpB0GyPz6UocSBJdkhYZB4Zz0@gnusha.org X-Gm-Message-State: AOJu0YxEF0jpJ2pALweL+iT0TrnDlMvH6BOtrIUSMSB80Ic1en34rfo8 ihsKXiDjgbf2kPf1idHUTNu/WmlY8SygRpfeR62RVgUI9cXHNxtupEHU X-Google-Smtp-Source: AGHT+IHsU8gFetzcq63ZY418dTV8zLI0mqKly+XaRHsx60+AaRQo/zSmPb4kqqhb6SUY93YTw61Pgg== X-Received: by 2002:a05:6870:14d6:b0:3ec:4067:c684 with SMTP id 586e51a60fabf-3fda51eb4bamr6221609fac.3.1766432915081; Mon, 22 Dec 2025 11:48:35 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWaL6gJEyApcF99JMPcdatJ5u7z+nGhbmb1TmzWd+ePwEw==" Received: by 2002:a05:6870:a494:b0:3fd:e7af:6a2 with SMTP id 586e51a60fabf-3fde7af0737ls535312fac.1.-pod-prod-00-us-canary; Mon, 22 Dec 2025 11:48:28 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCVR5qcBfdbbYfMD2bn9ZWkFjfJ+bNc7y84mq0C+NUDNPfKfwJ1LKW8v86bJIfoWJf8nANfAeuEYBt99@googlegroups.com X-Received: by 2002:a05:6808:1205:b0:450:b249:71bb with SMTP id 5614622812f47-457a292c5bdmr6818166b6e.19.1766432908176; Mon, 22 Dec 2025 11:48:28 -0800 (PST) Received: by 2002:a05:600c:4897:b0:477:99f7:45de with SMTP id 5b1f17b1804b1-47d192ab396ms5e9; Mon, 22 Dec 2025 11:06:32 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCU3Xtql//6lTdyv/E+0yP6Sv/arS2OOZh3Y/H4aus3aqe/BV3anBZvpHYMzUyzxI4FvgXGaqd8uwETr@googlegroups.com X-Received: by 2002:a05:600c:6388:b0:477:639d:bca2 with SMTP id 5b1f17b1804b1-47d1956ec01mr110296875e9.4.1766430389907; Mon, 22 Dec 2025 11:06:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1766430389; cv=none; d=google.com; s=arc-20240605; b=eNLUptG72RLk/qrzTcVXAvKsRCDN5QBszMzJS6XrVdMBZfYYex4tdIFrYch3c33fvj 39MR0XdtwMICXKN6dSd2F06A/ynpfvJxC+PqKWeEq04NVMSfQWU2lcKWV2KHATBeE6qB EgR67mhmYqJF0eE53E7lHNqk4Rj2w2b/O77UYA23AO6v8wZZRe0rntgyfnYQtEIHgrcg +tnME9zm5/AwGiwg6jy0d19HYQ9eICL8Z8M/hJEOFXlyxaPLJzOMxm2ikFnNnNKZQUpj cHlRGLM8tnpypbTIs6d6XNwxzm30mrkPsBSQJ1S89X82XMfDBVHUXmUdPb5aRK2bYbF1 izyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=dkim-signature:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id; bh=KnwVcn3kBz5KfjtClWFE/X3WECq6U4H+t38WW56nA/I=; fh=JExXc2tO5ZA40KkucoIFF5jfnWZIKd3KxLSk4xaWdVg=; b=drf292PiisnXDmbLv/4zwxgo2QWZhB0LFQtFLX4CzwYzMdfnM91RXtwWx+7abyf7FI kUslgDnBvQaHasW/N9eRmvjp84JbOf1onNBJjBgV8NKLRraA2TUiUH5BcscziSYKoGFv zByMza3Fk7qiVb72hXvmVhn4gODYLu9iwAf1kbTAUl5AERopPXXTRWUP5HeuywKzy5pq acf0EjoVQ29op4hjZLGP+xetU/Ry4IVUFtFnI+2MNa89Q2V6mwlevtnNzB92BQGzhM/2 UiYPc71UB10vZstwtKuv3oNwgtjDBhtXCv+i2WdsI0bg5MwoIcEVxvSVCnjVr48yF4Ta yICg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=MArPjERQ; spf=pass (google.com: domain of murch@murch.one designates 2001:1a50:11:0:c83f:a8ff:fea6:c8da as permitted sender) smtp.mailfrom=murch@murch.one Received: from mailgate01.uberspace.is (mailgate01.uberspace.is. [2001:1a50:11:0:c83f:a8ff:fea6:c8da]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-47d192e925esi1106475e9.0.2025.12.22.11.06.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Dec 2025 11:06:29 -0800 (PST) Received-SPF: pass (google.com: domain of murch@murch.one designates 2001:1a50:11:0:c83f:a8ff:fea6:c8da as permitted sender) client-ip=2001:1a50:11:0:c83f:a8ff:fea6:c8da; Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235]) by mailgate01.uberspace.is (Postfix) with ESMTPS id 9B14E615F0 for ; Mon, 22 Dec 2025 20:06:29 +0100 (CET) Received: (qmail 19313 invoked by uid 989); 22 Dec 2025 19:06:29 -0000 Received: from unknown (HELO unkown) (::1) by farbauti.uberspace.de (Haraka/3.0.1) with ESMTPSA; Mon, 22 Dec 2025 20:06:29 +0100 Message-ID: <3344ee13-ccd9-4f72-baa8-f420f74199b3@murch.one> Date: Mon, 22 Dec 2025 11:06:26 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird 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: defenwycke , Bitcoin Development Mailing List References: <02d7368e-95d3-4185-b70f-3aa9b5df1e1d@murch.one> <841d6882-9853-4d96-84e8-c4742e17e969n@googlegroups.com> Content-Language: en-US From: Murch In-Reply-To: <841d6882-9853-4d96-84e8-c4742e17e969n@googlegroups.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: --- X-Rspamd-Report: BAYES_HAM(-2.978302) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) X-Rspamd-Score: -3.068302 X-Original-Sender: murch@murch.one X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=MArPjERQ; spf=pass (google.com: domain of murch@murch.one designates 2001:1a50:11:0:c83f:a8ff:fea6:c8da as permitted sender) smtp.mailfrom=murch@murch.one 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.8 (/) 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=20 input costs 15=E2=80=AFsats, a 68 vB P2WPKH input costs 7 sats, and a 57.5 = vB=20 P2TR input costs 6 sats. Your proposal prescribes an entire new class of transactions that are=20 managed by separate rules in a separate data structure. You propose to=20 charge 5=E2=80=AFsats per input for those transactions, and prescribe that= =20 miners should include such transactions even when they lose money by=20 doing so: at elevated feerates. Especially at high feerates, it is=20 irrational for miners to follow your proposal of selling blockspace=20 below value. This idea is made completely obsolete by the recent lowering of the new=20 minimum feerate. The most common inputs (P2WPKH) only cost <7=E2=80=AFsats = at=20 the new minimum feerate, and the ones that make up the biggest portion=20 of the UTXO set only costs <6=E2=80=AFsats at the new minimum feerate. At l= ow=20 feerates, your proposal provides negligible benefits to senders compared=20 to the status quo. Defenwycke wrote: > Using current standard input sizes (=E2=89=8868 vB for P2WPKH, =E2=89=88= 57.5 vB for=20 P2TR keypath, =E2=89=88148 vB for P2PKH), the break-even spend cost quickly= =20 rises into the hundreds of sats once fee rates exceed a few sat/vB. At=20 more common feerates (=E2=89=885=E2=80=9310 sat/vB), outputs below roughly = 500=E2=80=931500 sats=20 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=20 months. Inputs spending low amount P2TR UTXOs of =E2=80=9C500=E2=80=931500 = sats=E2=80=9D cost=20 0.8=E2=80=932.4% of their value at such feerates. I don=E2=80=99t see how g= etting back=20 ~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=20 see much benefit. If you want to incentivize people to consolidate their=20 UTXOs, you have to design something where the incentives work out for=20 both the producers and the consumers of blockspace. FWIW, it seems to me=20 that people would already have a financial incentive to do so right now,=20 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, >=20 > Thanks for the thoughtful response. Please find my response below. >=20 > > What does =E2=80=9Cdust-class=E2=80=9D mean? Are you using the Bitcoin= Core dust=20 > limit or talking about small amounts in general? I don=E2=80=99t have fig= ures=20 > off the top of my head, but I would assume that there are relatively few= =20 > UTXOs smaller than BitcoinCore=E2=80=99s dust limit. >=20 > I=E2=80=99m not referring to Bitcoin Core=E2=80=99s relay dust limits her= e. By =E2=80=9Cdust-=20 > class=E2=80=9D I mean outputs that are economically irrational to spend u= nder=20 > typical fee conditions, even though they remain technically valid. Using= =20 > current standard input sizes (=E2=89=8868 vB for P2WPKH, =E2=89=8857.5 vB= for P2TR=20 > keypath, =E2=89=88148 vB for P2PKH), the break-even spend cost quickly ri= ses=20 > into the hundreds of sats once fee rates exceed a few sat/vB. At more=20 > common feerates (=E2=89=885=E2=80=9310 sat/vB), outputs below roughly 500= =E2=80=931500 sats are=20 > rationally abandoned depending on script type. So this is an economic=20 > classification, not a relay-policy one. >=20 > > You might want to clarify that you mean only P2TR KP inputs. Or would= =20 > P2TR SP be permitted? >=20 > Yes =E2=80=94 only P2TR key-path spends would be permitted. Script-path s= pends=20 > would be excluded. I=E2=80=99ll make that explicit. >=20 > > It would be a lot of work to have a separate pool for this, and I=20 > don=E2=80=99t see a reason why they couldn=E2=80=99t just go in the regul= ar mempool. >=20 > Agreed. A physically separate mempool is not required. The intent is=20 > simply that these transactions sit at the very bottom of the normal=20 > mempool=E2=80=99s priority ordering and are treated as lowest priority fo= r=20 > eviction and inclusion >=20 > > That said, at 50% full, there are still around ~30 blocks worth of=20 > transactions waiting in the mempool that pay fees, =E2=80=A6 >=20 > Right - and DustSweep is not intended to provide any liveness guarantees= =20 > in that situation. These transactions are explicitly opportunistic and=20 > are expected to idle or expire during sustained congestion. That=20 > behaviour is acceptable and consistent with the goal of ensuring they=20 > never compete with fee-paying transactions. The 50% figure was meant as= =20 > an illustrative policy threshold, not a claim that blockspace is=20 > otherwise unused. >=20 > > =E2=80=A6the only ones I have seen lately are miners using a minimum f= eerate=20 > of 1 s/vB for their block templates. >=20 > That aligns with the intent. DustSweep transactions would only ever be=20 > eligible after normal block assembly, and only in templates that already= =20 > include all available fee-paying transactions. >=20 > > I assume the intention is to only relay these transactions when there= =20 > are blocks that aren=E2=80=99t full, to limit the bandwidth-wasting vecto= r this=20 > feature introduces, but overall it seems to me that it would be most=20 > likely for such transactions to sit in nodes=E2=80=99 memory until they e= xpire. >=20 > That=E2=80=99s a fair characterization, and it matches the design goals. = To=20 > further limit policy complexity and relay churn, DustSweep transactions= =20 > would also be constrained to: >=20 > - Confirmed inputs only (no unconfirmed ancestors >=20 > - RBF disabled (no replacement or package churn) >=20 > - No CPFP assumptions >=20 > This keeps them cheap to reason about for node operators, and expiry=20 > without confirmation is an expected outcome rather than a failure mode.= =20 > Importantly, these constraints mean DustSweep transactions require no=20 > additional mempool state tracking, package evaluation, or replacement=20 > logic beyond what nodes already implement today. >=20 > > It doesn=E2=80=99t seem obvious to me that saving a few dozen sats wou= ld=20 > greatly foster the users=E2=80=99 urge to consolidate. It feels like a lo= t of=20 > overhead for such a small incentive to the users, and relying on the=20 > miners to give away blockspace below market value feels a bit optimistic= =20 > as well. >=20 > I agree that the incentive is not primarily about recovering value.=20 > Empirically, outputs in this range represent a large number of UTXOs but= =20 > very little aggregate bitcoin value. Even aggressive consolidation would= =20 > recover well under a single BTC in total. The motivation is instead=20 > about long-term UTXO set hygiene: providing a narrow, predictable=20 > mechanism for compacting outputs that are otherwise rationally=20 > abandoned, without displacing market transactions or altering fee=20 > dynamics. Because the economic value involved is small, the mechanism is= =20 > intentionally constrained to avoid creating meaningful incentives for=20 > either users or miners=C2=A0to game block construction or relay policy. T= he=20 > benefit is therefore not measured in recovered bitcoin value, but in=20 > avoided long-term UTXO growth and reduced steady-state resource costs=20 > for nodes. >=20 > Separately (and not a dependency of this proposal), public analysis of=20 > inscription-related activity shows that a significant share of UTXO=20 > growth is tied to metadata-heavy patterns. Future work on segregated=20 > data lanes could allow voluntary compaction of those UTXOs while=20 > preserving metadata, but that=E2=80=99s orthogonal to DustSweep itself. >=20 > Kind regards, >=20 > Defenwycke >=20 >=20 > On Friday, December 12, 2025 at 11:19:17=E2=80=AFPM UTC Murch wrote: >=20 > Hey Defenwycke, >=20 > > all inputs are =E2=80=9Cdust-class=E2=80=9D UTXOs >=20 > What does =E2=80=9Cdust-class=E2=80=9D mean? Are you using the Bitcoi= n Core dust limit > or talking about small amounts in general? I don=E2=80=99t have figur= es off the > top of my head, but I would assume that there are relatively few UTXO= s > smaller than Bitcoin Core=E2=80=99s dust limit. >=20 > > only standard scripts (P2PKH / P2WPKH / P2TR) >=20 > You might want to clarify that you mean only P2TR KP inputs. Or would > P2TR SP be permitted? >=20 > > Nodes place these in a small, separate sub-mempool. They=E2=80=99r= e only > > accepted when the normal mempool is <50% full, and they=E2=80=99re > > automatically evicted if normal mempool usage hits 95%. >=20 > 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 mempool= . 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 ~30 > blocks worth of transactions waiting in the mempool that pay fees, = =E2=80=A6 >=20 > > Miners can include them up to a small weight fraction (I suggest > ~5%) > but only after filling the block with regular fee-paying transactions= . >=20 > =E2=80=A6 so if they are only considered in blocks that aren=E2=80=99= t 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 site= s, > in the past 32 months, there would have only been organically non-ful= l > blocks between April and August this year. >=20 > 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 v= ector 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 th= ey expire. >=20 > 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. It doesn=E2=80=99t seem obvious to me that s= aving a > few > dozen sats would greatly foster the users=E2=80=99 urge to consolidat= e. 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. >=20 > Cheers, > Murch >=20 > On 2025-12-11 04:53, defenwycke wrote: > > Hello list, > > > > I=E2=80=99ve been working on a small policy proposal that aims to = address > one > > very specific problem: the long-term accumulation of uneconomical > dust > > in the UTXO set. > > > > The idea is intentionally narrow. I=E2=80=99m calling it DustSweep= , and it > > defines a strict, non-abusable class of transactions that nodes ma= y > > 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=99r= e only > > accepted when the normal mempool is <50% full, and they=E2=80=99re > automatically > > evicted if normal mempool usage hits 95%. Miners can include them > 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 transaction > > format, nothing that affects validation. Nodes that don=E2=80=99t > implement it > > simply treat these as low-fee transactions and drop them. > > > > The motivation is straightforward: we don=E2=80=99t currently have= 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, thresholds,= and > whether > > this fits within what node operators and wallet developers would > > actually want to use. Happy to adjust parameters if there=E2=80=99= s a better > > balance point. > > > > Kind regards, > > > > Defenwycke > > > > -- > > 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+...@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>>. >=20 > --=20 > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send=20 > an email to bitcoindev+unsubscribe@googlegroups.com=20 > . > To view this discussion visit https://groups.google.com/d/msgid/=20 > bitcoindev/841d6882-9853-4d96-84e8-c4742e17e969n%40googlegroups.com=20 > 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/= 3344ee13-ccd9-4f72-baa8-f420f74199b3%40murch.one.