From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 30 Dec 2025 06:52:05 -0800 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vab4t-0006T3-2K for bitcoindev@gnusha.org; Tue, 30 Dec 2025 06:52:05 -0800 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-3f9ac407848sf16449177fac.2 for ; Tue, 30 Dec 2025 06:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1767106317; x=1767711117; 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=N6rU6nnOdRcTc4kxGQ3jjO1qLulS8smXOTls30Nd5/k=; b=t3/ZYy9ZvG3TnTIgYk8DPDlkhH52aAsbsyZt32JPN5zXn6oLRclmMfEnowTtxPqCgA jnkG+RA8x0QO2sZRiLyaof4thuIoZGxSHgw8oEkdvT9M+mkCGl8wsFF+UOsRWG4a/9mz cIiaZwNzGG/ifDeQ7w8OJVnWd2Qzp/kp21fQltQzi4O1HT+b06DLHMAnN/Q3I0ozQ7XT Au+nYPe+QvxWgJV8dQqYMvE0V203YIcwfeTdCXpb5zvkR3UKSvXp/SvXKhGoXZsgO2sp CmUBX00wn8X9iUkOJlgv8PmJ8U4vPZxpgUn30FiNec4Zzxm1d2eokzbB9ZPgFTNbzklH 3YQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767106317; x=1767711117; 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=N6rU6nnOdRcTc4kxGQ3jjO1qLulS8smXOTls30Nd5/k=; b=TfMYuvSItjm956PWFFkEQF+UTJdceKiqpKQvEoBe6J6G6p5MZoKgcGL7YGroLWJ4Z3 /c6W9kY/Npv5JBLQicwaDqobQnH0olAFDdwF3a3OJwXEvHioXBGKIr0UijPL8KvsEzv3 sTaq1DfpDPFwxmTRwK0dVgLHEV1UIhFM1xOHKwlRJFkGuJCazqm0vl7D+Vld5KN6jAo0 1bpUd0hdVxGSzoJ1Cqb/ECU3aoesw1Muc6if6JZigPcevtHuffbcOtRoGzMJSwRJIqHc 1lXQyqHI+zP5WGq/OZnnU06+KtUt1EVQnQT8OfPaHLwdV+peb14sufSc8UWMNk3ULZDi bXNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767106317; x=1767711117; 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=N6rU6nnOdRcTc4kxGQ3jjO1qLulS8smXOTls30Nd5/k=; b=u4raxQYIQDtZdyxp3QwI7iq8ZbmDdT6hxK0hzrXZa7Fo4Io6Q2Q7yuyDk44xkn1e4h ykT72QCzBsor3n6Xyb5GfwjQ2nBlHnigh0Qxfq1RPdM/O5C2jz9ODwxPYT5eHiHQYmAC qnwqlAIiqfNbHhuaOKlWUhVKfBPwXKiwQJZi5fTFlXbKfotdzJG6/5bD26AOUnQsYU43 GYPsf2Hp+ZrjnuluPt/ifaL4qSBsuDuD//7aofQZjfzcyZHbzkqQPG2L1W+zStQp2/1N tGrNpeT29K+WILahjZ94OFbLQJTSFOvQg+hx1hrSghyLfH3EQVPUW3/pJgDSMtBfzqPx G4uA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUfgwRdJtZtBDesZmlzaARlFReEZi3p6RtS83Rty/8UUI4omN8dUXRTMPWE9phEJSEhFzrQ4pGijkNj@gnusha.org X-Gm-Message-State: AOJu0Yx/oYOAi8Lk9QXPYX6WIZqjEiOC2Qf9gTO6UOsOcdq2PeLYkJMX WJFj51UI+pf6lvnc05NCy/uvEu96Ey7maqDN/dM8AooJzg4hRh2E4qN2 X-Google-Smtp-Source: AGHT+IGlSm3HLZZIrTHj0FlZjocX2oZ9NepMuE2N7bkoIuC4e5t2Ps7UjF1ZXRyHe5YsM6zEANnF+Q== X-Received: by 2002:a05:6870:fb8b:b0:3f5:4172:127 with SMTP id 586e51a60fabf-3fda5945cf7mr18312588fac.56.1767106316434; Tue, 30 Dec 2025 06:51:56 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWb424cHSLuVdmkT35f9uXXhdcRgnxkA8BSE/4JGMbO/6g==" Received: by 2002:a05:6870:548a:b0:3ec:401f:488b with SMTP id 586e51a60fabf-3fe95673051ls1606458fac.1.-pod-prod-03-us; Tue, 30 Dec 2025 06:51:51 -0800 (PST) X-Received: by 2002:a05:6808:6f8c:b0:455:7fe4:b215 with SMTP id 5614622812f47-457b21d3073mr16619157b6e.53.1767106311914; Tue, 30 Dec 2025 06:51:51 -0800 (PST) Received: by 2002:a05:690c:4a92:b0:786:6c46:840 with SMTP id 00721157ae682-78fb39c9e68ms7b3; Tue, 30 Dec 2025 06:36:27 -0800 (PST) X-Received: by 2002:a53:c94a:0:b0:646:5127:9ce2 with SMTP id 956f58d0204a3-6466a8abe7fmr22731838d50.46.1767105386999; Tue, 30 Dec 2025 06:36:26 -0800 (PST) Date: Tue, 30 Dec 2025 06:36:26 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <213ed021-c57e-40b6-8357-c797f52c7d34n@googlegroups.com> References: <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com> <4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n@googlegroups.com> <959c8b53-2055-4de2-8a93-1fd169f1a159n@googlegroups.com> <213ed021-c57e-40b6-8357-c797f52c7d34n@googlegroups.com> Subject: Re: [bitcoindev] Re: The Cat, BIP draft discussion. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1126864_169608595.1767105386646" X-Original-Sender: antoine.riard@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_1126864_169608595.1767105386646 Content-Type: multipart/alternative; boundary="----=_Part_1126865_516791390.1767105386646" ------=_Part_1126865_516791390.1767105386646 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list, > Which brings me to my disagreement, which I know is not shared by a=20 number of contributors here: just as it is hard to define spam on Bitcoin,= =20 it's also very hard to define it in a discussion forum like this one.=20 Making suggestions which *I* think are terrible, or detrimental, on a list= =20 like 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. I'm fully sharing waxwing reasonable opinion. While I can understand gmax's= =20 sentiment being fed up with poor coin confiscation proposals again and again on the mailing=20 list, the cure would be worst than the disease. Maybe, I'm very voltairean here, but you don't=20 fight ill-founded opinions. by persecuting their authors (--otherwise, down the road you take the risk= =20 of seeing the bastille popped up). Rather than you fight them back by doing the work to persuade= =20 and to convince those ideas you find stupid are indeed *objectively* stupid. To me, it's a sign of strength and confidence that Bitcoin and its=20 development process can withstand and endure the most "outrageous" controversies. For sure, I have= =20 been enough times in the shoes of someone who has to champion controversial changes (cf.=20 `mempoolfullrbf`) to not negate that the strength of the process is kinda traded on the back of the= =20 devs, but this is not altering my mind on what I think should be *ideally* the development=20 process in terms of openess and publicity. My humble opinion only, as we said. Best, Antoine OTS hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1ce Le mercredi 24 d=C3=A9cembre 2025 =C3=A0 17:23:48 UTC, waxwing/ AdamISZ a = =C3=A9crit : > 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 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 > > 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=20 > value to humanity - note I am not saying its financial value, but value a= s=20 > a project (and if we didn't see such value what the hell are we doing=20 > here). Of course those two types of value are very closely linked, but th= ey=20 > are still distinct. I hold that same belief even when we are talking abou= t=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 numbe= r=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 no= t=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 simpl= e=20 > matter. > > Cheers, > AdamISZ/waxwing > On Tuesday, December 23, 2025 at 10:26:16=E2=80=AFPM UTC-3 Greg Maxwell w= rote: > >> 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 particul= ar=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 does= n't=20 >> support it, NFT's being a one such example (although one I consider pret= ty=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 n= eed=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 spend= ing=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 ar= e=20 >> generally over the dust limit in any case (so the proposals failure to m= eet=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 go= ing=20 >> forward (after, of course, making the rule clear on the signup page). I= t'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 discu= ss=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 misguid= ed=20 >> proposals.=20 >> >> >> On Tue, Dec 23, 2025 at 6:27=E2=80=AFPM John wro= te: >> >>> 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 unspenda= ble.=20 >>> At each halving block, UTXOs that have remained below the dust threshol= d=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 incentiviz= es=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 problem= s: >>> >>> 1) External dependency: The Cat requires reference indexers (Ord,=20 >>> Stamps, etc.) to define which UTXOs qualify. This introduces=20 >>> consensus-level dependency on external, non-Bitcoin software that can= =20 >>> change, have bugs, or interpret protocols differently. >>> >>> 2) Protocol targeting: By specifically identifying inscription and stam= p=20 >>> outputs, the proposal makes subjective judgments about which Bitcoin us= es=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 crea= te=20 >>> dust that doesn't match the list criteria. >>> >>> 4) Static snapshot: A one-time list cleanup provides temporary relief= =20 >>> but 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 permane= nt=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 ou= tput=20 >>> is worth. These UTXOs are already "dead" in practice; this proposal sim= ply=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 address= es=20 >>> and ensure transferability across all address types. This "postage" amo= unt=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 o= f=20 >>> inscriptions depends on these dust-level UTXOs being spendable; Lynx br= eaks=20 >>> that model through neutral, threshold-based rules rather than list-base= d=20 >>> discrimination. >>> >>> Specification >>> >>> Definitions >>> >>> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats i= s=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=20 >>> (i.e., 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 we= re=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 w= ish=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 actio= n >>> - 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= =20 >>> but creates no ongoing pressure against dust accumulation. Periodic=20 >>> enforcement: >>> >>> - 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 outpoi= nts.=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 w= hy 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 log= ic. >>> >>> 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=20 >>> during 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=20 >>> adjust 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= =20 >>> the 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 networ= k;=20 >>> and the community could choose to lower or eliminate the threshold thro= ugh=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=20 >>>> your end-- since if you sent one I would normally have been directly= =20 >>>> 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 steganograph= y"=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 a= n=20 >>>> issue but with any change to consensus relevant code great care must b= e=20 >>>> taken to not introduce errors. Actually *making* a consensus change w= ould=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 abou= t=20 >>>> stamps put in the effort to define their exclusions in ways that are s= afe=20 >>>> than to burden everyone with a consensus change that doesn't care abou= t 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 coul= d=20 >>>>> cause one of those otherwise unspendable outputs to be spendable, thu= s=20 >>>>> causing a fork between those nodes that adopted the Stamp pruning met= hod=20 >>>>> and those that did not once one of those steganographic Stamps is spe= nt.=20 >>>>> Though this is unlikely, it is still technically possible, and I woul= d not=20 >>>>> put it past the denizens of the Internet to stir up trouble just for = its=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 = has=20 >>>>>> long done so for several types of unspendable outputs, e.g. outputs = over=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, sen= d=20 >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> >>>> To view this discussion visit=20 >>>>> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-= aa66ea0cfb79n%40googlegroups.com=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+...@googlegroups.com. >>> >> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1f= d169f1a159n%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/= c87a50a4-1a1b-4aee-bc1f-bd1c91d675d1n%40googlegroups.com. ------=_Part_1126865_516791390.1767105386646 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list,

> Which brings me to my disagreement, which I know i= s 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 discussion forum li= ke this one. Making suggestions which *I* think are terrible, or detrimenta= l, on a list like this, should never be disallowed here. Notions of motivat= ion of contributors (such as they are paid by such and such a company) shou= ld not be relevant. Everything should be open to discussion which is implem= entation-technical (so obviously not e.g. threats of violence or things tha= t bring legal liability to participants or have zero relevance to Bitcoin's= technical development) even if it's philosophy-motivated. And blocking sho= uld be reserved either as an anti-DOS measure if volume gets out of control= , or if it brings dangers as per the previous parenthetical.

I'm= fully sharing waxwing reasonable opinion. While I can understand gmax's se= ntiment being fed
up with poor coin confiscation proposals again and a= gain on the mailing list, the cure would be
worst than the disease. Ma= ybe, I'm very voltairean here, but you don't fight ill-founded opinions.by persecuting their authors (--otherwise, down the road you take the ri= sk of seeing the bastille
popped up). Rather than you fight them back = by doing the work to persuade and to convince those
ideas you find stu= pid are indeed *objectively* stupid.

To me, it's a sign of stren= gth and confidence that Bitcoin and its development process can
withst= and and endure the most "outrageous" controversies. For sure, I have been e= nough times
in the shoes of someone who has to champion controversial = changes (cf. `mempoolfullrbf`) to not
negate that the strength of the = process is kinda traded on the back of the devs, but this is not
alter= ing my mind on what I think should be *ideally* the development process in = terms of openess
and publicity.

My humble opinion only, as = we said.

Best,
Antoine
OTS hash: 5c1c19f589a61787dbf48= 3cd6814f094c3b24888d6d189c5f4d776bda558e1ce
Le mercredi 24 d=C3=A9cembre 2025 = =C3=A0 17:23:48 UTC, waxwing/ AdamISZ a =C3=A9crit=C2=A0:
Hi Greg, list:
=
>=C2=A0I think the list should adopt a 1 year ban on part= ies *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 under= mining 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 entitle= d to the time and the reputation of the participants here for offensively misguided proposals.=C2=A0

I'm a huge agree-e= r with the motivation of this comment and a huge disagree-er with the sugge= stion itself.

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

Which brings me to my disag= reement, 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 discussion forum like this one. Making suggestions which *I* think = are terrible, or detrimental, on a list like this, should never be disallow= ed here. Notions of motivation of contributors (such as they are paid by su= ch and such a company) should not be relevant. Everything should be open to= discussion which is implementation-technical (so obviously not e.g. threat= s of violence or things that bring legal liability to participants or have = zero relevance to Bitcoin's technical development) even if it's phi= losophy-motivated. And blocking should be reserved either as an anti-DOS me= asure if volume gets out of control, or if it brings dangers as per the pre= vious parenthetical.

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

<= div>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 co= nsensus parameter, it's just a number pulled out of the air that didn&#= 39;t seem unreasonable based on average fee behavior.=C2=A0 But in any part= icular block transactions may need no particular fee level at all, includin= g zero fees.=C2=A0 And in some cases it may be very economically advantageo= us=C2=A0to spend an output even if its face value doesn't support it, N= FT's being a one such example (although one I consider pretty dumb).
=C2=A0
This proposal also appears to have ignored the pri= or discussion particularly where it was pointed out that 'deleting'= outputs will not achieve the goal of deleting the tokens connected to them= (so won't eliminate the incentive), or that txouts=C2=A0which are pred= ictably not going to be accessed (as this proposal claims applies to the tx= outs it targets) don't have as significant performance implications (be= cause they don't need to be cached in ram).=C2=A0 It also appears to be= uninformed=C2=A0by advances like utxotree which makes the absolute size of= the txout set much less important, but would make mass removals such as th= at described here=C2=A0expensive.=C2=A0 Nor has it considered that given th= e level of fee spending on NFT traffic a requirement to keep it over some (= reasonable) threshold would not likely discourage it, or the fact that exis= tent=C2=A0NFT outputs are generally over the dust limit in any case (so the= proposals failure to meet the opcat proponents' delusional goals is al= ready clear).

I think the list should adopt a 1 ye= ar ban on parties *and their* employer(s) (if known) for any coin confiscat= ion=C2=A0proposal on the list going forward (after, of course, making the r= ule clear on the signup page).=C2=A0 It's tiresome and beyond being a w= aste of time risks undermining public confidence in Bitcoin to see the cons= tant trickle of these outrageous=C2=A0proposals in venues where they previo= usly understood that serious discussions were to be had. People are, of cou= rse, free to discuss whatever ill-founded concepts they want but they'r= e not entitled to the time and the reputation of the participants here for = offensively 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<= br>@matteopelleg



Lynx.
<= br>Abstract
This proposal introduces a periodic, consensus-enforced mech= anism for rendering UTXOs below the network's dust threshold permanentl= y unspendable. At each halving block, UTXOs that have remained below the du= st threshold since the previous halving become unspendable. These UTXOs bec= ome unspendable and may be pruned from the UTXO set entirely, reducing node= storage requirements and eliminating the economic model that incentivizes = their creation.

Motivation
The Bitcoin UTXO set has grown substan= tially due to various factors, including inscription protocols, spam attack= s, and general dust accumulation. Recent proposals such as "The Cat&qu= ot; (Non-monetary UTXO Cleanup) by @ostrom72158
=C2=A0 have attempted to= address this by creating lists of specific UTXOs to render unspendable, id= entified 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 depend= ency: The Cat requires reference indexers (Ord, Stamps, etc.) to define whi= ch UTXOs qualify. This introduces consensus-level dependency on external, n= on-Bitcoin software that can change, have bugs, or interpret protocols diff= erently.

2) Protocol targeting: By specifically identifying inscript= ion and stamp outputs, the proposal makes subjective judgments about which = Bitcoin uses are legitimate. This sets a precedent for protocol-level discr= imination.

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

4) Static = snapshot: A one-time list cleanup provides temporary relief but does nothin= g for future UTXO accumulation.

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

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

UTXOs below = the dust threshold are, by definition, economically irrational to spend und= er normal fee conditions. The dust limit exists precisely because spending = these outputs costs more in fees than the output is worth. These UTXOs are = already "dead" in practice; this proposal simply makes that reali= ty explicit at the consensus layer.

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

- Requires no external indexers
- Makes no judgmen= t about why a UTXO is small
- Applies equally to all participants
- P= rovides ongoing, predictable maintenance
- Removes political discretion = from the process

Impact on Inscription Protocols

The typical = Ordinals inscription is stored in a UTXO containing exactly 546 sats; the m= inimum required to meet the dust limit for P2PKH addresses and ensure trans= ferability across all address types. This "postage" amount is sta= ndard across inscription tooling and marketplaces.

A threshold of 99= 9 sats captures the vast majority of inscription UTXOs without requiring an= y protocol-specific targeting. The economic model of inscriptions depends o= n these dust-level UTXOs being spendable; Lynx breaks that model through ne= utral, threshold-based rules rather than list-based discrimination.

= Specification

Definitions

-=C2=A0 Dust threshold: 999 sats. A= ny UTXO with a value less than 999 sats is subject to Lynx enforcement.
=
- Halving block: A block at height N * 210,000 where N =E2=89=A5 1.
=
-=C2=A0 Snapshot block: A halving block at which the current dust thres= hold and qualifying UTXOs are recorded.

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

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

Consensus Rules
After activation, the following rul= es apply:

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

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

3) Pruning: After enforcement, nodes MAY prune Ly= nx UTXOs from their local UTXO set. Transactions referencing unknown outpoi= nts are already rejected as invalid; pruned Lynx UTXOs are simply treated a= s if they were already spent.

4) Grace period: The ~4 year window be= tween snapshot and enforcement provides ample time for holders to consolida= te sub-dust UTXOs if they wish to preserve the value.

Activation
=
Activation method: TBD (Speedy Trial, BIP8, or other mechanism as deter= mined by community consensus)

Recommended first snapshot: The halvin= g following activation lock-in

Rationale

Why a fixed threshol= d?

Using a fixed threshold of 999 sats rather than referencing the d= ynamic relay dust limit provides:

- Simplicity: One number, no scrip= t-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 halv= ing?

The halving is Bitcoin's most recognized Schelling point, u= sing it provides:

- Predictability: Everyone knows exactly when halv= ings occur
- Sufficient notice: ~4 years is generous warning for any cle= anup action
- Aligned incentives: As block rewards decrease, fee revenue= and UTXO efficiency become more critical to network sustainability
- Na= tural cadence: The halving already represents a moment of network-wide coor= dination

Why not a one-time cleanup?

A one-time cleanup (as p= roposed by The Cat) provides temporary relief but creates no ongoing pressu= re against dust accumulation. Periodic enforcement:

- Establishes a = permanent, predictable norm
- Removes any expectation that dust UTXOs ha= ve indefinite longevity
- Discourages business models built on dust crea= tion
- Provides continuous UTXO set maintenance

Why pruning works= without a list

A key insight enables pruning without maintaining a = separate list: Bitcoin nodes already reject transactions that reference unk= nown outpoints. When a node receives a transaction spending an outpoint not= in its UTXO set, it rejects it as invalid =E2=80=94 the node doesn't n= eed to know why the outpoint is missing (spent? never existed? pruned?).
After enforcement, a Lynx UTXO is functionally equivalent to a spent o= utput. Nodes can simply delete it from the UTXO set. Any future transaction= attempting to spend it will reference an outpoint the node doesn't rec= ognize, and will be rejected through existing validation logic.

This= means:

- No separate "Lynx list" is required
- No new = validation logic is needed
- Pruning is optional; nodes MAY keep Lynx UT= XOs 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 all sc= ript types (P2PKH: 546, P2TR: 330, etc.)
- Captures all standard inscrip= tions: Typical inscription UTXOs contain exactly 546 sats as "postage&= quot;; well under 999
- Simple and memorable: A clean number that's = easy to communicate and reason about

Backward Compatibility

T= his is a soft fork. Nodes that do not upgrade will:

- Continue to co= nsider all historical transactions valid
- Accept blocks that exclude sp= ends of Lynx UTXOs
- Eventually converge with upgraded nodes (as upgrade= d miners will not include invalid spends)

Wallets & Services sho= uld:

- 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 sub-threshold outputs appro= aching 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 u= nspendable OP_RETURN outputs
- Satoshi's untouched coinbase rewards<= br>
The bitcoin supply cap remains unchanged; the affected outputs simpl= y become irrecoverable. Holders receive ~4 years notice to consolidate if t= hey value the sats.

Lightning Network

Some Lightning implemen= tations create small HTLCs and dust outputs during channel operations. Anal= ysis is needed to determine:

- Whether current dust thresholds affec= t normal LN operations
- If LN implementations need adjustment before ac= tivation
- Whether channel close scenarios create sub-threshold outputs<= br>
Preliminary assessment: LN dust limits are already set conservativel= y above relay dust limits, so impact should be minimal. However, this requi= res verification from LN implementers.

Fixed threshold vs. future fe= e markets

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

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

If Bitcoin's fee market evolves such that 999 sats becom= es economically significant to spend, this would indicate broader success o= f the network; and the community could choose to lower or eliminate the thr= eshold through a subsequent proposal.

Acknowledgments
This propos= al builds on the problem identification in "The Cat" (Non-monetar= y UTXO Cleanup) while proposing a list-free alternative mechanism. The Cat = correctly identifies UTXO bloat as a problem worth solving; Lynx offers a m= ore neutral solution.


https://x.= com/matteopelleg/status/2000602318346334449
<= div dir=3D"auto" class=3D"gmail_attr">On Thursday, 18 December 2025 at 21:3= 6:14 UTC-6 Greg Maxwell wrote:
I received no prior response from you,= so I suspect the issue is on your end-- since if you sent one I would norm= ally 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 steganography" can cha= nge that.=C2=A0 =C2=A0If you're imagining that perhaps they are *presum= ed* to be unspendable but actually *are* spendable, then sure that would be= an issue but with any change to consensus relevant code great care must be= taken to not introduce errors.=C2=A0 Actually *making* a consensus change = would only increase the potential for mistakes.

Th= ese costs are just another reason why this hysteria over a non-issue is mis= placed.

But in any case it is better that (any) im= plementations that care about stamps put in the effort to define their excl= usions in ways that are safe than to burden everyone with a consensus chang= e that doesn't care about it.


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

=
The problem with dropping Bitcoin Stamps UTXOs from the UTXO set= without a consensus change is that a clever use of steganography could cau= se one of those otherwise unspendable outputs to be spendable, thus causing= a fork between those nodes that adopted the Stamp pruning 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 would not put it past= the denizens of the Internet to stir up trouble just for its own sake.
=
On Friday, December 12, 2025 at 6:49:41=E2=80=AFPM UTC-5 Greg Maxwell wrot= e:
On Fri, Dec 12, 2025 at 9:26=E2=80=AFPM Jonathan Voss = <k98...@gmail.com> wrote:
Since the Bitcoin Stamps outputs are already unspendable, it mak= es perfect sense to mark and drop them from the UTXO set.
=
Ther= e is no consensus change involved in not storing a provably unspendable out= put, it's just an implementation detail with no interoperability implic= ations and doesn't need a BIP.=C2=A0 Bitcoin core has long done so for = several types of unspendable outputs, e.g. outputs over 10kb and ones start= ing 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+...@googlegroups.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/c87a50a4-1a1b-4aee-bc1f-bd1c91d675d1n%40googlegroups.com.
------=_Part_1126865_516791390.1767105386646-- ------=_Part_1126864_169608595.1767105386646--