From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 24 Dec 2025 09:23:57 -0800 Received: from mail-ot1-f63.google.com ([209.85.210.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 1vYSaZ-0002ZC-5d for bitcoindev@gnusha.org; Wed, 24 Dec 2025 09:23:57 -0800 Received: by mail-ot1-f63.google.com with SMTP id 46e09a7af769-7cad1393ec8sf12479002a34.0 for ; Wed, 24 Dec 2025 09:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1766597029; x=1767201829; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=NR/nIm5RA3w8zxorYfsPaK4WObreSRjEidP5D0I65eY=; b=Qcs1fwWMpKvsmmf5Zfk/1RzYypkiWywkELwkh1DHGpszMyWEaYZpVCnskZp3dQBrjO AOf7cN1vm9mclHugNYrE3qX63tfXNuqy0jar7Rw9XAN/l+Y0HnMqXDdspat0xdbxHtgt rBgNHxunAiI8TkZTuYOCV+3JDebMjwCeTBbdh+SYn7IRVZnx7DU+hUDyMOxRECn4BVFp 58+UlLnMvhRvqEix7lM8ocg+izqODRvXx/d9IngWTS5zMd69Hvwfx7kVW1aSGXYFfAfm V/o6Ow9NRFw7v+E1y5uDQ+58JdKs6r4QoY2iSNp0mcM1ZbN3eyr9zKcqP8urd+8aaQU0 ba1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766597029; x=1767201829; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=NR/nIm5RA3w8zxorYfsPaK4WObreSRjEidP5D0I65eY=; b=bkplUHFrjbgjcTOA4xTcRC6qDoS2XC+yhZk+Y9eXNeGUqY8fFxHfpzsBV/jkgrcShH iogCQ8xp5yF+pX70RKCFN8etL6V2qF0fdEQzI1C3JIen+QcEMSfpsr3KSoliAR02lvqO h7VbgpSn9eXbzi1V2dkUE0bxG7RpGX6DPbYUCx/ycpGTcZX7sKYLyhCAWafJ8jNO+ziU wlEcoAKdJ5L7OAhlsI0RYIihTG4F53uTafkNrYp1MTKN/yYzwnHT8JXwh994K7IMJmyU 8FtY+R5XmtXp4e+VOOyhCmPUvSnMCLe4QNZ3/hO4ncjLyeP9dl3FRvHnbfm6ASFFcOnR rjtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766597029; x=1767201829; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=NR/nIm5RA3w8zxorYfsPaK4WObreSRjEidP5D0I65eY=; b=S3jJCBYK1lnU2RkMm6zDiDBpQyUaSgFg/mfsa4V4z4NQG0T1zXqBPo5CCKre6WnGXR XJEGKDVFsPijWhmOUdDxHS5eECypVMK6y+UQbBKLlmSkpZgBzTKEz886zGW+eujOID31 yDRvZft+NTOxeAjxVnNl75XHJKbPCcRxs8x5c/7FJ05YbPv+ib8h3W4IzdlZa7fhdt4Q 0UERM5bS2cXEvGyNUvowNKwwlEuma9MaXhrvbBcuOOg7sLLsOZkKuQqLLtS0lNDT6pl5 pslMICBNS++C0lZgq0J1fgX4Eiiaph+WCmBl01JuBkKzjNzUKgJU+Y1Gw5PxCOiC2xyh bkRQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXgsAdVFusg2rJrhOYwZ6GT9iKiJHo8zSxAZYMF06r25d1zazuM8I88ZO6SUAgRDs2ITsAHaLpJJFQk@gnusha.org X-Gm-Message-State: AOJu0Ywd8Nyghv0pFYuNR9RbPRptWnnI0TPr8yPwkW3nCkWayNfGVq0P ua5uf7DQ94linPhyrh13iXQ9pfA2ZZvYF5kZTYOIlHvuJivL9MXBpaJF X-Google-Smtp-Source: AGHT+IFwrtjsE+NmWIFkyHtbOrWNpxPATLu7QVSM++COJPAzyHo86WgSat5cW+s/6U5DJfxpYoByLA== X-Received: by 2002:a05:6820:162a:b0:659:9a49:8f70 with SMTP id 006d021491bc7-65d0ea99305mr8298489eaf.53.1766597028632; Wed, 24 Dec 2025 09:23:48 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbGZ5ows/7NoIWEbrGJ0nDbGpEjZUIIRXugwmHeU1HIHA==" Received: by 2002:a05:6870:1704:b0:35a:ce0a:d0a3 with SMTP id 586e51a60fabf-3f5f83b784fls7909854fac.0.-pod-prod-08-us; Wed, 24 Dec 2025 09:23:43 -0800 (PST) X-Received: by 2002:a05:6808:190e:b0:450:d09a:8ce7 with SMTP id 5614622812f47-457b1e8d610mr9485805b6e.20.1766597023188; Wed, 24 Dec 2025 09:23:43 -0800 (PST) Received: by 2002:a05:690c:a60b:b0:78f:e48e:4bc9 with SMTP id 00721157ae682-78fe48e7e34ms7b3; Wed, 24 Dec 2025 09:19:56 -0800 (PST) X-Received: by 2002:a05:690c:d1b:b0:788:161c:7117 with SMTP id 00721157ae682-78fb3f05395mr321040477b3.8.1766596795549; Wed, 24 Dec 2025 09:19:55 -0800 (PST) Date: Wed, 24 Dec 2025 09:19:55 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <213ed021-c57e-40b6-8357-c797f52c7d34n@googlegroups.com> In-Reply-To: References: <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com> <4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n@googlegroups.com> <959c8b53-2055-4de2-8a93-1fd169f1a159n@googlegroups.com> Subject: Re: [bitcoindev] Re: The Cat, BIP draft discussion. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_420696_735680536.1766596795128" X-Original-Sender: ekaggata@gmail.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 (/) ------=_Part_420696_735680536.1766596795128 Content-Type: multipart/alternative; boundary="----=_Part_420697_536142934.1766596795128" ------=_Part_420697_536142934.1766596795128 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, list: > I think the list should adopt a 1 year ban on parties *and their*=20 employer(s) (if known) for any coin confiscation proposal on the list going= =20 forward (after, of course, making the rule clear on the signup page). It's= =20 tiresome and beyond being a waste of time risks undermining public=20 confidence in Bitcoin to see the constant trickle of these=20 outrageous proposals in venues where they previously understood that=20 serious discussions were to be had. People are, of course, free to discuss= =20 whatever ill-founded concepts they want but they're not entitled to the=20 time and the reputation of the participants here for offensively misguided= =20 proposals.=20 I'm a huge agree-er with the motivation of this comment and a huge=20 disagree-er with the suggestion itself. Actual confiscation, whatever the reason, hugely undermines Bitcoin's value= =20 to humanity - note I am not saying its financial value, but value as a=20 project (and if we didn't see such value what the hell are we doing here).= =20 Of course those two types of value are very closely linked, but they are=20 still distinct. I hold that same belief even when we are talking about=20 other suggestions of confiscation, such as to address a quantum threat -=20 something that has recently been discussed here, extensively. Which brings me to my disagreement, which I know is not shared by a number= =20 of contributors here: just as it is hard to define spam on Bitcoin, it's=20 also very hard to define it in a discussion forum like this one. Making=20 suggestions which *I* think are terrible, or detrimental, on a list like=20 this, should never be disallowed here. Notions of motivation of=20 contributors (such as they are paid by such and such a company) should not= =20 be relevant. Everything should be open to discussion which is=20 implementation-technical (so obviously not e.g. threats of violence or=20 things that bring legal liability to participants or have zero relevance to= =20 Bitcoin's technical development) even if it's philosophy-motivated. And=20 blocking should be reserved either as an anti-DOS measure if volume gets=20 out of control, or if it brings dangers as per the previous parenthetical. Just my opinion of course, I know that moderation of lists is not a simple= =20 matter. Cheers, AdamISZ/waxwing On Tuesday, December 23, 2025 at 10:26:16=E2=80=AFPM UTC-3 Greg Maxwell wro= te: > The 'dust threshold' isn't a consensus parameter, it's just a number=20 > pulled out of the air that didn't seem unreasonable based on average fee= =20 > behavior. But in any particular block transactions may need no particula= r=20 > fee level at all, including zero fees. And in some cases it may be very= =20 > economically advantageous to spend an output even if its face value doesn= 't=20 > support it, NFT's being a one such example (although one I consider prett= y=20 > dumb). > =20 > This proposal also appears to have ignored the prior discussion=20 > particularly where it was pointed out that 'deleting' outputs will not=20 > achieve the goal of deleting the tokens connected to them (so won't=20 > eliminate the incentive), or that txouts which are predictably not going = to=20 > be accessed (as this proposal claims applies to the txouts it targets)=20 > don't have as significant performance implications (because they don't ne= ed=20 > to be cached in ram). It also appears to be uninformed by advances like= =20 > utxotree which makes the absolute size of the txout set much less=20 > important, but would make mass removals such as that described=20 > here expensive. Nor has it considered that given the level of fee spendi= ng=20 > on NFT traffic a requirement to keep it over some (reasonable) threshold= =20 > would not likely discourage it, or the fact that existent NFT outputs are= =20 > generally over the dust limit in any case (so the proposals failure to me= et=20 > the opcat proponents' delusional goals is already clear). > > I think the list should adopt a 1 year ban on parties *and their*=20 > employer(s) (if known) for any coin confiscation proposal on the list goi= ng=20 > forward (after, of course, making the rule clear on the signup page). It= 's=20 > tiresome and beyond being a waste of time risks undermining public=20 > confidence in Bitcoin to see the constant trickle of these=20 > outrageous proposals in venues where they previously understood that=20 > serious discussions were to be had. People are, of course, free to discus= s=20 > whatever ill-founded concepts they want but they're not entitled to the= =20 > time and the reputation of the participants here for offensively misguide= d=20 > proposals.=20 > > > On Tue, Dec 23, 2025 at 6:27=E2=80=AFPM John wrot= e: > >> Good evening all, >> >> Here is a related proposal by Matteo Pellegrini >> @matteopelleg >> >> >> >> Lynx. >> >> Abstract >> This proposal introduces a periodic, consensus-enforced mechanism for=20 >> rendering UTXOs below the network's dust threshold permanently unspendab= le.=20 >> At each halving block, UTXOs that have remained below the dust threshold= =20 >> since the previous halving become unspendable. These UTXOs become=20 >> unspendable and may be pruned from the UTXO set entirely, reducing node= =20 >> storage requirements and eliminating the economic model that incentivize= s=20 >> their creation. >> >> Motivation >> The Bitcoin UTXO set has grown substantially due to various factors,=20 >> including inscription protocols, spam attacks, and general dust=20 >> accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO=20 >> Cleanup) by @ostrom72158 >> have attempted to address this by creating lists of specific UTXOs to= =20 >> render unspendable, identified by external protocol indexers. >> >> The Cat's approach has a fatal flaw: it relies on a list. >> >> Using a curated list of "non-monetary UTXOs" introduces several problems= : >> >> 1) External dependency: The Cat requires reference indexers (Ord, Stamps= ,=20 >> etc.) to define which UTXOs qualify. This introduces consensus-level=20 >> dependency on external, non-Bitcoin software that can change, have bugs,= or=20 >> interpret protocols differently. >> >> 2) Protocol targeting: By specifically identifying inscription and stamp= =20 >> outputs, the proposal makes subjective judgments about which Bitcoin use= s=20 >> are legitimate. This sets a precedent for protocol-level discrimination. >> >> 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes=20 >> workarounds. If Ordinals dust is targeted, protocols will adapt to creat= e=20 >> dust that doesn't match the list criteria. >> >> 4) Static snapshot: A one-time list cleanup provides temporary relief bu= t=20 >> does nothing for future UTXO accumulation. >> >> 5) Political vulnerability: Any list-based approach requires ongoing=20 >> governance decisions about what belongs on the list, creating a permanen= t=20 >> political attack surface. >> >> A better approach targets the economic reality, not the use case. >> >> UTXOs below the dust threshold are, by definition, economically=20 >> irrational to spend under normal fee conditions. The dust limit exists= =20 >> precisely because spending these outputs costs more in fees than the out= put=20 >> is worth. These UTXOs are already "dead" in practice; this proposal simp= ly=20 >> makes that reality explicit at the consensus layer. >> >> By using a threshold rather than a list, Lynx: >> >> - Requires no external indexers >> - Makes no judgment about why a UTXO is small >> - Applies equally to all participants >> - Provides ongoing, predictable maintenance >> - Removes political discretion from the process >> >> Impact on Inscription Protocols >> >> The typical Ordinals inscription is stored in a UTXO containing exactly= =20 >> 546 sats; the minimum required to meet the dust limit for P2PKH addresse= s=20 >> and ensure transferability across all address types. This "postage" amou= nt=20 >> is standard across inscription tooling and marketplaces. >> >> A threshold of 999 sats captures the vast majority of inscription UTXOs= =20 >> without requiring any protocol-specific targeting. The economic model of= =20 >> inscriptions depends on these dust-level UTXOs being spendable; Lynx bre= aks=20 >> that model through neutral, threshold-based rules rather than list-based= =20 >> discrimination. >> >> Specification >> >> Definitions >> >> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is= =20 >> subject to Lynx enforcement. >> >> - Halving block: A block at height N * 210,000 where N =E2=89=A5 1. >> >> - Snapshot block: A halving block at which the current dust threshold= =20 >> and qualifying UTXOs are recorded. >> >> - Enforcement block: The halving block following a snapshot block (i.e.= ,=20 >> snapshot block + 210,000 blocks). >> >> Lynx UTXOs: >> - Existed at the snapshot block >> - Had a value less than 999 sats >> - Remained unspent through the enforcement period (~4 years) >> >> Consensus Rules >> After activation, the following rules apply: >> >> 1) Snapshot: At each halving block H, record the set of all UTXOs with= =20 >> value < 999 sats. >> >> 2) Enforcement: At halving block H + 210,000: >> - Any UTXO that was in the snapshot set and remains unspent becomes=20 >> permanently unspendable >> - Transactions attempting to spend these UTXOs are invalid >> >> 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their=20 >> local UTXO set. Transactions referencing unknown outpoints are already= =20 >> rejected as invalid; pruned Lynx UTXOs are simply treated as if they wer= e=20 >> already spent. >> >> 4) Grace period: The ~4 year window between snapshot and enforcement=20 >> provides ample time for holders to consolidate sub-dust UTXOs if they wi= sh=20 >> to preserve the value. >> >> Activation >> >> Activation method: TBD (Speedy Trial, BIP8, or other mechanism as=20 >> determined by community consensus) >> >> Recommended first snapshot: The halving following activation lock-in >> >> Rationale >> >> Why a fixed threshold? >> >> Using a fixed threshold of 999 sats rather than referencing the dynamic= =20 >> relay dust limit provides: >> >> - Simplicity: One number, no script-type variations, no need to query=20 >> policy settings >> >> - Predictability: Everyone knows exactly what qualifies, forever >> >> - Consensus clarity: No ambiguity about which outputs are affected. >> >> Why tie to the halving? >> >> The halving is Bitcoin's most recognized Schelling point, using it=20 >> provides: >> >> - Predictability: Everyone knows exactly when halvings occur >> - Sufficient notice: ~4 years is generous warning for any cleanup action >> - Aligned incentives: As block rewards decrease, fee revenue and UTXO=20 >> efficiency become more critical to network sustainability >> - Natural cadence: The halving already represents a moment of=20 >> network-wide coordination >> >> Why not a one-time cleanup? >> >> A one-time cleanup (as proposed by The Cat) provides temporary relief bu= t=20 >> creates no ongoing pressure against dust accumulation. Periodic enforcem= ent: >> >> - Establishes a permanent, predictable norm >> - Removes any expectation that dust UTXOs have indefinite longevity >> - Discourages business models built on dust creation >> - Provides continuous UTXO set maintenance >> >> Why pruning works without a list >> >> A key insight enables pruning without maintaining a separate list:=20 >> Bitcoin nodes already reject transactions that reference unknown outpoin= ts.=20 >> When a node receives a transaction spending an outpoint not in its UTXO= =20 >> set, it rejects it as invalid =E2=80=94 the node doesn't need to know wh= y the=20 >> outpoint is missing (spent? never existed? pruned?). >> >> After enforcement, a Lynx UTXO is functionally equivalent to a spent=20 >> output. Nodes can simply delete it from the UTXO set. Any future=20 >> transaction attempting to spend it will reference an outpoint the node= =20 >> doesn't recognize, and will be rejected through existing validation logi= c. >> >> This means: >> >> - No separate "Lynx list" is required >> - No new validation logic is needed >> - Pruning is optional; nodes MAY keep Lynx UTXOs if they wish >> - The UTXO set shrinks naturally as nodes prune >> >> Why 999 sats? >> >> The threshold of 999 sats is chosen because: >> >> - Above all dust limits: Captures UTXOs at or below the dust limit for= =20 >> all script types (P2PKH: 546, P2TR: 330, etc.) >> - Captures all standard inscriptions: Typical inscription UTXOs contain= =20 >> exactly 546 sats as "postage"; well under 999 >> - Simple and memorable: A clean number that's easy to communicate and=20 >> reason about >> >> Backward Compatibility >> >> This is a soft fork. Nodes that do not upgrade will: >> >> - Continue to consider all historical transactions valid >> - Accept blocks that exclude spends of Lynx UTXOs >> - Eventually converge with upgraded nodes (as upgraded miners will not= =20 >> include invalid spends) >> >> Wallets & Services should: >> >> - Warn users holding sub-threshold UTXOs after a snapshot block >> - Provide consolidation tools during the grace period >> - Update UTXO selection algorithms to deprioritize or exclude=20 >> sub-threshold outputs approaching a snapshot >> >> Security Considerations >> >> No confiscation >> >> This proposal does not transfer value to any party. Sub-threshold UTXOs= =20 >> become unspendable, similar to: >> >> - Lost private keys >> - Provably unspendable OP_RETURN outputs >> - Satoshi's untouched coinbase rewards >> >> The bitcoin supply cap remains unchanged; the affected outputs simply=20 >> become irrecoverable. Holders receive ~4 years notice to consolidate if= =20 >> they value the sats. >> >> Lightning Network >> >> Some Lightning implementations create small HTLCs and dust outputs durin= g=20 >> channel operations. Analysis is needed to determine: >> >> - Whether current dust thresholds affect normal LN operations >> - If LN implementations need adjustment before activation >> - Whether channel close scenarios create sub-threshold outputs >> >> Preliminary assessment: LN dust limits are already set conservatively=20 >> above relay dust limits, so impact should be minimal. However, this=20 >> requires verification from LN implementers. >> >> Fixed threshold vs. future fee markets >> >> The 999 satoshi threshold is fixed in consensus rules and does not adjus= t=20 >> based on fee market conditions.=20 >> This is intentional: >> >> - A fixed threshold provides certainty for users and developers >> - If fee markets change dramatically, a future soft fork could adjust th= e=20 >> threshold >> - The ~4 year grace period allows the community to observe and adapt >> >> If Bitcoin's fee market evolves such that 999 sats becomes economically= =20 >> significant to spend, this would indicate broader success of the network= ;=20 >> and the community could choose to lower or eliminate the threshold throu= gh=20 >> a subsequent proposal. >> >> Acknowledgments >> This proposal builds on the problem identification in "The Cat"=20 >> (Non-monetary UTXO Cleanup) while proposing a list-free alternative=20 >> mechanism. The Cat correctly identifies UTXO bloat as a problem worth=20 >> solving; Lynx offers a more neutral solution. >> >> >> https://x.com/matteopelleg/status/2000602318346334449 >> On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote: >> >>> I received no prior response from you, so I suspect the issue is on you= r=20 >>> end-- since if you sent one I would normally have been directly copied.= =20 >>> >>> In any case, your message makes no sense. If an output is provably=20 >>> unspendable then it is unspendable. No amount of "clever steganography= "=20 >>> can change that. If you're imagining that perhaps they are *presumed*= to=20 >>> be unspendable but actually *are* spendable, then sure that would be an= =20 >>> issue but with any change to consensus relevant code great care must be= =20 >>> taken to not introduce errors. Actually *making* a consensus change wo= uld=20 >>> only increase the potential for mistakes. >>> >>> These costs are just another reason why this hysteria over a non-issue= =20 >>> is misplaced. >>> >>> But in any case it is better that (any) implementations that care about= =20 >>> stamps put in the effort to define their exclusions in ways that are sa= fe=20 >>> than to burden everyone with a consensus change that doesn't care about= it. >>> >>> >>> On Fri, Dec 19, 2025 at 1:49=E2=80=AFAM Jonathan Voss wrote: >>> >>>> This is my third attempt to respond to this. Idk what is going wrong= =20 >>>> here. >>>> >>>> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set=20 >>>> without a consensus change is that a clever use of steganography could= =20 >>>> cause one of those otherwise unspendable outputs to be spendable, thus= =20 >>>> causing a fork between those nodes that adopted the Stamp pruning meth= od=20 >>>> and those that did not once one of those steganographic Stamps is spen= t.=20 >>>> Though this is unlikely, it is still technically possible, and I would= not=20 >>>> put it past the denizens of the Internet to stir up trouble just for i= ts=20 >>>> own sake. >>>> >>>> On Friday, December 12, 2025 at 6:49:41=E2=80=AFPM UTC-5 Greg Maxwell = wrote: >>>> >>>>> On Fri, Dec 12, 2025 at 9:26=E2=80=AFPM Jonathan Voss =20 >>>>> wrote: >>>>> >>>>>> Since the Bitcoin Stamps outputs are already unspendable, it makes= =20 >>>>>> perfect sense to mark and drop them from the UTXO set. >>>>> >>>>> >>>>> There is no consensus change involved in not storing a provably=20 >>>>> unspendable output, it's just an implementation detail with no=20 >>>>> interoperability implications and doesn't need a BIP. Bitcoin core h= as=20 >>>>> long done so for several types of unspendable outputs, e.g. outputs o= ver=20 >>>>> 10kb and ones starting with OP_RETURN. >>>>> >>>>> --=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+...@googlegroups.com. >>>> >>> To view this discussion visit=20 >>>> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-a= a66ea0cfb79n%40googlegroups.com=20 >>>> >>>> . >>>> >>> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd= 169f1a159n%40googlegroups.com=20 >> >> . >> > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 213ed021-c57e-40b6-8357-c797f52c7d34n%40googlegroups.com. ------=_Part_420697_536142934.1766596795128 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg, list:

>=C2=A0I think the list s= hould adopt a 1 year ban on parties *and their*=20 employer(s) (if known) for any coin confiscation=C2=A0proposal on the list= =20 going forward (after, of course, making the rule clear on the signup=20 page).=C2=A0 It's tiresome and beyond being a waste of time risks undermini= ng public confidence in Bitcoin to see the constant trickle of these=20 outrageous=C2=A0proposals in venues where they previously understood that= =20 serious discussions were to be had. People are, of course, free to=20 discuss whatever ill-founded concepts they want but they're not entitled to the time and the reputation of the participants here for offensively misguided proposals.=C2=A0

I'm a huge agree-er = with the motivation of this comment and a huge disagree-er with the suggest= ion itself.

Actual confiscation, whatever the re= ason, hugely undermines Bitcoin's value to humanity - note I am not saying = its financial value, but value as a project (and if we didn't see such valu= e what the hell are we doing here). Of course those two types of value are = very closely linked, but they are still distinct. I hold that same belief e= ven when we are talking about other suggestions of confiscation, such as to= address a quantum threat - something that has recently been discussed here= , extensively.

Which brings me to my disagreemen= t, which I know is not shared by a number of contributors here: just as it = is hard to define spam on Bitcoin, it's also very hard to define it in a di= scussion forum like this one. Making suggestions which *I* think are terrib= le, or detrimental, on a list like this, should never be disallowed here. N= otions of motivation of contributors (such as they are paid by such and suc= h a company) should not be relevant. Everything should be open to discussio= n which is implementation-technical (so obviously not e.g. threats of viole= nce or things that bring legal liability to participants or have zero relev= ance to Bitcoin's technical development) even if it's philosophy-motivated.= And blocking should be reserved either as an anti-DOS measure if volume ge= ts out of control, or if it brings dangers as per the previous parenthetica= l.

Just my opinion of course, I know that modera= tion of lists is not a simple matter.

Cheers,AdamISZ/waxwing
On Tuesday, December 23, 2025 at 10:26:16=E2=80=AFPM UTC-3 = Greg Maxwell wrote:
The 'dust threshold' isn't a conse= nsus parameter, it's just a number pulled out of the air that didn'= t seem unreasonable based on average fee behavior.=C2=A0 But in any particu= lar block transactions may need no particular fee level at all, including z= ero fees.=C2=A0 And in some cases it may be very economically advantageous= =C2=A0to spend an output even if its face value doesn't support it, NFT= 's being a one such example (although one I consider pretty dumb).
=C2=A0
This proposal also appears to have ignored the prior= discussion particularly where it was pointed out that 'deleting' o= utputs will not achieve the goal of deleting the tokens connected to them (= so won't eliminate the incentive), or that txouts=C2=A0which are predic= tably not going to be accessed (as this proposal claims applies to the txou= ts it targets) don't have as significant performance implications (beca= use they don't need to be cached in ram).=C2=A0 It also appears to be u= ninformed=C2=A0by advances like utxotree which makes the absolute size of t= he txout set much less important, but would make mass removals such as that= described here=C2=A0expensive.=C2=A0 Nor has it considered that given the = level of fee spending on NFT traffic a requirement to keep it over some (re= asonable) threshold would not likely discourage it, or the fact that existe= nt=C2=A0NFT outputs are generally over the dust limit in any case (so the p= roposals failure to meet the opcat proponents' delusional goals is alre= ady clear).

I think the list should adopt a 1 year= ban on parties *and their* employer(s) (if known) for any coin confiscatio= n=C2=A0proposal on the list going forward (after, of course, making the rul= e clear on the signup page).=C2=A0 It's tiresome and beyond being a was= te of time risks undermining public confidence in Bitcoin to see the consta= nt trickle of these outrageous=C2=A0proposals in venues where they previous= ly understood that serious discussions were to be had. People are, of cours= e, free to discuss whatever ill-founded concepts they want but they're = not entitled to the time and the reputation of the participants here for of= fensively misguided proposals.=C2=A0


On Tue, Dec 23, 2025 at 6:27=E2=80=AFPM John <johnpenn...@gmail.com> wrote:
=
Good evening all,

Here is a related proposal = by Matteo Pellegrini
@matteopelleg



=
Lynx.

Abstract
This proposal introduces a periodic, co= nsensus-enforced mechanism for rendering UTXOs below the network's dust= threshold permanently unspendable. At each halving block, UTXOs that have = remained below the dust threshold since the previous halving become unspend= able. These UTXOs become unspendable and may be pruned from the UTXO set en= tirely, reducing node storage requirements and eliminating the economic mod= el that incentivizes their creation.

Motivation
The Bitcoin UTXO = set has grown substantially due to various factors, including inscription p= rotocols, spam attacks, and general dust accumulation. Recent proposals suc= h as "The Cat" (Non-monetary UTXO Cleanup) by @ostrom72158
=C2= =A0 have attempted to address this by creating lists of specific UTXOs to r= ender unspendable, identified by external protocol indexers.

The Cat= 's approach has a fatal flaw: it relies on a list.

Using a curat= ed list of "non-monetary UTXOs" introduces several problems:
<= br>1) External dependency: The Cat requires reference indexers (Ord, Stamps= , etc.) to define which UTXOs qualify. This introduces consensus-level depe= ndency on external, non-Bitcoin software that can change, have bugs, or int= erpret protocols differently.

2) Protocol targeting: By specifically= identifying inscription and stamp outputs, the proposal makes subjective j= udgments about which Bitcoin uses are legitimate. This sets a precedent for= protocol-level discrimination.

3) Cat-and-mouse dynamics: Targeting= specific protocols incentivizes workarounds. If Ordinals dust is targeted,= protocols will adapt to create dust that doesn't match the list criter= ia.

4) Static snapshot: A one-time list cleanup provides temporary r= elief but does nothing for future UTXO accumulation.

5) Political vu= lnerability: Any list-based approach requires ongoing governance decisions = about what belongs on the list, creating a permanent political attack surfa= ce.

A better approach targets the economic reality, not the use case= .

UTXOs below the dust threshold are, by definition, economically ir= rational to spend under normal fee conditions. The dust limit exists precis= ely because spending these outputs costs more in fees than the output is wo= rth. These UTXOs are already "dead" in practice; this proposal si= mply makes that reality explicit at the consensus layer.

By using a = threshold rather than a list, Lynx:

- Requires no external indexers<= br>- Makes no judgment about why a UTXO is small
- Applies equally to al= l participants
- Provides ongoing, predictable maintenance
- Removes = political discretion from the process

Impact on Inscription Protocol= s

The typical Ordinals inscription is stored in a UTXO containing ex= actly 546 sats; the minimum required to meet the dust limit for P2PKH addre= sses and ensure transferability across all address types. This "postag= e" amount is standard across inscription tooling and marketplaces.
=
A threshold of 999 sats captures the vast majority of inscription UTXOs= without requiring any protocol-specific targeting. The economic model of i= nscriptions depends on these dust-level UTXOs being spendable; Lynx breaks = that model through neutral, threshold-based rules rather than list-based di= scrimination.

Specification

Definitions

-=C2=A0 Dust t= hreshold: 999 sats. Any UTXO with a value less than 999 sats is subject to = Lynx enforcement.

- Halving block: A block at height N * 210,000 whe= re N =E2=89=A5 1.

-=C2=A0 Snapshot block: A halving block at which t= he current dust threshold and qualifying UTXOs are recorded.

-=C2=A0= Enforcement block: The halving block following a snapshot block (i.e., sna= pshot block + 210,000 blocks).

Lynx UTXOs:
- Existed at the snaps= hot block
- Had a value less than 999 sats
- Remained unspent through= the enforcement period (~4 years)

Consensus Rules
After activati= on, the following rules apply:

1) Snapshot: At each halving block H,= record the set of all UTXOs with value < 999 sats.

2) Enforcemen= t: At halving block H + 210,000:
- Any UTXO that was in the snapshot set= and remains unspent becomes permanently unspendable
- Transactions atte= mpting to spend these UTXOs are invalid

3) Pruning: After enforcemen= t, nodes MAY prune Lynx UTXOs from their local UTXO set. Transactions refer= encing unknown outpoints are already rejected as invalid; pruned Lynx UTXOs= are simply treated as if they were already spent.

4) Grace period: = The ~4 year window between snapshot and enforcement provides ample time for= holders to consolidate sub-dust UTXOs if they wish to preserve the value.<= br>
Activation

Activation method: TBD (Speedy Trial, BIP8, or oth= er mechanism as determined by community consensus)

Recommended first= snapshot: The halving following activation lock-in

Rationale
Why a fixed threshold?

Using a fixed threshold of 999 sats rather t= han referencing the dynamic relay dust limit provides:

- Simplicity:= One number, no script-type variations, no need to query policy settings
- Predictability: Everyone knows exactly what qualifies, forever
- Consensus clarity: No ambiguity about which outputs are affected.
Why tie to the halving?

The halving is Bitcoin's most recogniz= ed Schelling point, using it provides:

- Predictability: Everyone kn= ows exactly when halvings occur
- Sufficient notice: ~4 years is generou= s warning for any cleanup action
- Aligned incentives: As block rewards = decrease, fee revenue and UTXO efficiency become more critical to network s= ustainability
- Natural cadence: The halving already represents a moment= of network-wide coordination

Why not a one-time cleanup?

A o= ne-time cleanup (as proposed by The Cat) provides temporary relief but crea= tes no ongoing pressure against dust accumulation. Periodic enforcement:
- Establishes a permanent, predictable norm
- Removes any expectati= on that dust UTXOs have indefinite longevity
- Discourages business mode= ls built on dust creation
- Provides continuous UTXO set maintenance
=
Why pruning works without a list

A key insight enables pruning w= ithout maintaining a separate list: Bitcoin nodes already reject transactio= ns that reference unknown outpoints. When a node receives a transaction spe= nding an outpoint not in its UTXO set, it rejects it as invalid =E2=80=94 t= he node doesn't need to know why the outpoint is missing (spent? never = existed? pruned?).

After enforcement, a Lynx UTXO is functionally eq= uivalent to a spent output. Nodes can simply delete it from the UTXO set. A= ny future transaction attempting to spend it will reference an outpoint the= node doesn't recognize, and will be rejected through existing validati= on logic.

This means:

- No separate "Lynx list" is = required
- No new validation logic is needed
- Pruning is optional; n= odes MAY keep Lynx UTXOs if they wish
- The UTXO set shrinks naturally a= s nodes prune

Why 999 sats?

The threshold of 999 sats is chos= en because:

- Above all dust limits: Captures UTXOs at or below the = dust limit for all script types (P2PKH: 546, P2TR: 330, etc.)
- Captures= all standard inscriptions: Typical inscription UTXOs contain exactly 546 s= ats as "postage"; well under 999
- Simple and memorable: A cle= an number that's easy to communicate and reason about

Backward C= ompatibility

This is a soft fork. Nodes that do not upgrade will:
- Continue to consider all historical transactions valid
- Accept b= locks that exclude spends of Lynx UTXOs
- Eventually converge with upgra= ded nodes (as upgraded miners will not include invalid spends)

Walle= ts & Services should:

- Warn users holding sub-threshold UTXOs a= fter a snapshot block
- Provide consolidation tools during the grace per= iod
- Update UTXO selection algorithms to deprioritize or exclude sub-th= reshold outputs approaching a snapshot

Security Considerations
No confiscation

This proposal does not transfer value to any party= . Sub-threshold UTXOs become unspendable, similar to:

- Lost private= keys
- Provably unspendable OP_RETURN outputs
- Satoshi's untouc= hed coinbase rewards

The bitcoin supply cap remains unchanged; the a= ffected outputs simply become irrecoverable. Holders receive ~4 years notic= e to consolidate if they value the sats.

Lightning Network

So= me Lightning implementations create small HTLCs and dust outputs during cha= nnel operations. Analysis is needed to determine:

- Whether current = dust thresholds affect normal LN operations
- If LN implementations need= adjustment before activation
- Whether channel close scenarios create s= ub-threshold outputs

Preliminary assessment: LN dust limits are alre= ady set conservatively above relay dust limits, so impact should be minimal= . However, this requires verification from LN implementers.

Fixed th= reshold vs. future fee markets

The 999 satoshi threshold is fixed in= consensus rules and does not adjust based on fee market conditions.=C2=A0<= br>This is intentional:

- A fixed threshold provides certainty for u= sers and developers
- If fee markets change dramatically, a future soft = fork could adjust the threshold
- The ~4 year grace period allows the co= mmunity to observe and adapt

If Bitcoin's fee market evolves suc= h that 999 sats becomes economically significant to spend, this would indic= ate broader success of the network; and the community could choose to lower= or eliminate the threshold through a subsequent proposal.

Acknowled= gments
This proposal builds on the problem identification in "The C= at" (Non-monetary UTXO Cleanup) while proposing a list-free alternativ= e mechanism. The Cat correctly identifies UTXO bloat as a problem worth sol= ving; Lynx offers a more neutral solution.


https://x.com/matteopelleg/status/2000602318346334449
On Thursday, 18 = December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
I received no pri= or response from you, so I suspect the issue is on your end-- since if you = sent one I would normally have been directly copied.=C2=A0

In any case, your message makes no sense. If an output is provably= unspendable then it is unspendable.=C2=A0 No amount of "clever stegan= ography" can change that.=C2=A0 =C2=A0If you're imagining that per= haps they are *presumed* to be unspendable but actually *are* spendable, th= en sure that would be an issue but with any change to consensus relevant co= de great care must be taken to not introduce errors.=C2=A0 Actually *making= * a consensus change would only increase the potential for mistakes.
<= div>
These costs are just another reason why this hysteria ov= er a non-issue is misplaced.

But in any case it is= better that (any) implementations that care about stamps put in the effort= to define their exclusions in ways that are safe than to burden everyone w= ith a consensus change that doesn't care about it.

=

On Fri, Dec 19, 2025 at 1:49=E2=80=AFAM Jo= nathan Voss <k98...@gmail.com> wrote:
This is my third attempt to respond to this. Idk what is going w= rong here.

The problem with dropping Bitcoin Stamps UTXO= s from the UTXO set without a consensus change is that a clever use of steg= anography could cause one of those otherwise unspendable outputs to be spen= dable, thus causing a fork between those nodes that adopted the Stamp pruni= ng method and those that did not once one of those steganographic Stamps is= spent. Though this is unlikely, it is still technically possible, and I wo= uld not put it past the denizens of the Internet to stir up trouble just fo= r its own sake.

On Friday, December 12, 2025 at 6:49:41=E2=80=AFPM UTC-= 5 Greg Maxwell wrote:
On Fri, Dec 12, 2025 at 9:26=E2=80= =AFPM Jonathan Voss <k98...@gmail.com> wrote:=
Since the Bitcoin Stamps outputs are alrea= dy unspendable, it makes perfect sense to mark and drop them from the UTXO = set.

There is no consensus change involved in not storing a pr= ovably unspendable output, it's just an implementation detail with no i= nteroperability implications and doesn't need a BIP.=C2=A0 Bitcoin core= has long done so for several types of unspendable outputs, e.g. outputs ov= er 10kb and ones starting with OP_RETURN.

--
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+...@googlegroups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb7= 9n%40googlegroups.com.

--
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+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a15= 9n%40googlegroups.com.

--
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/msgid/bitcoind= ev/213ed021-c57e-40b6-8357-c797f52c7d34n%40googlegroups.com.
------=_Part_420697_536142934.1766596795128-- ------=_Part_420696_735680536.1766596795128--