From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 21 Jan 2026 18:06:57 -0800 Received: from mail-yx1-f58.google.com ([74.125.224.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vik62-0002cv-8w for bitcoindev@gnusha.org; Wed, 21 Jan 2026 18:06:57 -0800 Received: by mail-yx1-f58.google.com with SMTP id 956f58d0204a3-64949d79903sf1164191d50.1 for ; Wed, 21 Jan 2026 18:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1769047608; x=1769652408; 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=ZTcoKR15GGrD+yHoyJLEuAPcne2g3DzruPiqJFq61BA=; b=B44TiiHVnmz0I5a+bEv+X45W1UW6UWRcmlyRV1ai3d3r2tDPyPYkclp3ClBFNJaS69 Q7osyg0/JpoVwMpc1DE82aVVwXh59Qa64YrMan66UqPUKBYLkgP5xRVNRIsmUlFw4oA8 RyWhWQo5XvKii4nkK6+ApiJh9kIQjJtEHy7jlVwC+P6m7iGg1nA9aGsL+YoHtWC9cRMo PUnE37ksxkcGVi4nuWSK2LwzI0qzaGwXgQ9l7Cc5nfrRRF8e4ZZLK8FlHd9r7zphVFa+ aLNmHvK+G8ppgzP2hp1OlJKg7wze80W4oxAHKkT6h7QWcohO4jLiVzhN06E72OrYQ8Ve yT/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769047608; x=1769652408; 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=ZTcoKR15GGrD+yHoyJLEuAPcne2g3DzruPiqJFq61BA=; b=Sht8TRzIEqL9NI3lChtpDMiOoxcFvUwqF1RMfCvX5DY/iXBZz2REtPh/Ziqmbd/q7n eDH78EJvkPbUbx730qHDL8lsiPSpeW27ezw5St3mWPBPpAjtloh5HfLj5DuB7LH4Z/x5 VUS8/ocX5I1XnzwHIy2Y6U+NzWOkciatlKRAjplOWXFZLNHqemHqPkLVJpMjQlzf3O9g CIasC76asN12Lyt7ujzNskBLf5Hxry8+VOLMQBz3i0jC+LciuLy0GGPigppUWvytaFvC mW3FROecl/7oTWi678OOnhGyvu5vPp5hrKbrZebBQ0JsMmfjgAYXIZKlv02QWDl3MrpB YH9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769047608; x=1769652408; 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=ZTcoKR15GGrD+yHoyJLEuAPcne2g3DzruPiqJFq61BA=; b=W7vSditds9p/bbFB6J8DqeWABO91YDngqgqT9tPyqMgmh8brlfuJkXzBFzbhC0xG2n Dkm3FDiv7+Zivj7CRbRTwHG+UJjYpvGTmQIxL1KlUY1Ip/X49xzrh42DZXhHP6xxoG2U xXqrpYAVgEMU001fOQ2oEQNUnVtAKNuQy9y0+BWaAvqvHaVDPq+kRipXC1UEybiq4ikf zuPjPbzT6MnjpzwHDda7SP+MqF8SO8fO6QyTMOS7P5TvAJdmz8+RUF38ayu79cYoW/as Aj8CmUa2sfsa0QZh7Lt2gHz9jM2HqMJ2+4GA/dybJEDC4w3V4j8tMVKLp5I5XPsGubzb GC1A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVXEbgPds5kWmdLbHRzKZbOKdsm83mq1MtRM6MgLWW6WfiIYo1jEx5mhUWjrZeOOAyb5g0ghiXOEWcR@gnusha.org X-Gm-Message-State: AOJu0YyTbPVfTnmDaCyXAkbr4grVX9ap93xiGWtUtv/r6RE3OdwsH2rq a947bYhCN+XF6TehMe3nvg6SvYuspmV9C8CHY+nmOuybmXbvEWFbURK7 X-Received: by 2002:a05:690e:1c07:b0:644:50c7:a50a with SMTP id 956f58d0204a3-649513693e4mr1221718d50.32.1769047607519; Wed, 21 Jan 2026 18:06:47 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+FltRpVzMbihucpl+dt5XDUNSJiNh88BKQixsvIzgI9Gg==" Received: by 2002:a53:cb0a:0:b0:644:368f:fd30 with SMTP id 956f58d0204a3-64944ca1e2als886579d50.2.-pod-prod-00-us-canary; Wed, 21 Jan 2026 18:06:41 -0800 (PST) X-Received: by 2002:a05:690c:6a03:b0:792:7745:72fc with SMTP id 00721157ae682-7942a82271emr12274717b3.21.1769047601618; Wed, 21 Jan 2026 18:06:41 -0800 (PST) Received: by 2002:a05:690c:2f01:b0:794:2788:2ae4 with SMTP id 00721157ae682-79427882e65ms7b3; Wed, 21 Jan 2026 17:15:01 -0800 (PST) X-Received: by 2002:a05:690c:fd2:b0:794:a55:f6f6 with SMTP id 00721157ae682-7942a863869mr11253837b3.28.1769044499168; Wed, 21 Jan 2026 17:14:59 -0800 (PST) Date: Wed, 21 Jan 2026 17:14:58 -0800 (PST) From: Claire Ostrom To: Bitcoin Development Mailing List Message-Id: <521249b0-a9a8-4fc1-b975-c6c80b8ddb01n@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> <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_28494_1959645434.1769044498735" X-Original-Sender: ostromclairehome@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_28494_1959645434.1769044498735 Content-Type: multipart/alternative; boundary="----=_Part_28495_1298731202.1769044498735" ------=_Part_28495_1298731202.1769044498735 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list, I=E2=80=99m reposting the reply below that I wrote on Dec 11. I later disco= vered I=20 had accidentally emailed it directly to Greg instead of sending it to the= =20 list, and I wrongly inferred that it was being blocked. I then made public= =20 comments implying censorship, an embarrassing mistake that was entirely my= =20 own. My apologies to the moderators, Greg, and anyone misled by that. I=E2=80=99= m=20 participating in good faith and want to keep the focus on the technical=20 merits. Here is the message as originally sent: Hi Greg,=20 When you say I misunderstood your quote, are you referring to the notion=20 that you thought we should try to shape behavior? You also said your reason= =20 for caring about motivation in the first place was because you didn't want= =20 to give the wrong impression about what was "kosher". Both you and Sipa=20 (who also stated in that thread "The problem is that people may see this as= =20 a legitimation of the storage in the first place, and encourage doing so=20 even more.") seemed to be primarily motivated by the social signals that=20 would be sent by allowing even a small amount of data to be used=20 arbitrarily in the protocol, but felt (from my reading) that it may be=20 worth the trade-off for, as you said, shaping users to more conservative=20 needs. I certainly appreciate your larger point here, where you state that current= =20 use has nullified previously effective means of curbing this behavior, and= =20 as you say, sometimes even further increasing it. This is precisely why my= =20 proposal exists as it does. It acknowledges that these attempts to "stop"= =20 the behavior are not effective against strong financial incentives to=20 overcome them. They would also eventually lead to more harmful abuse;=20 typically this filter discussion lands at the threat of fake pubkey use,=20 which has generally been seen as the most harmful way to include data in=20 the system. My proposal attempts to destroy trust in those markets, to reduce the=20 desire to spam in the first place.=20 *"Were such a proposal seriously advanced it would likely cause a new flood= =20 of transactions both to move to evade it directly and as a result of NFT=20 indexer changes to just "wormhole" the tokens to new outputs after the fact= =20 (and a new marketing opportunity for the NFT gifters). NFTs are just an=20 imaginary parallel world that don't depend on the network to validate their= =20 activity, so they don't really care about the network's rules, and as such= =20 the network's rules have pretty limited effect. "* I understand why you feel that way, but this is not the only way to look at= =20 it, and I'm glad we're able to have this discussion. I am not so naive=20 about the behavior of these communities and have some experience with them= =20 in the past. You're right: every crypto asset is essentially a narrative. Where I feel you don't give me enough credit is when you dismiss that the= =20 buyers of those narratives are apathetic towards them. One of the largest= =20 debates in the ordinal world was the value that the actual numbering system= =20 should have at all. The entire point of ordinal theory is that they number= =20 and value specific satoshi as non-fungible assets themselves. To suggest=20 that they would be content to assign a new satoshi with their key, I think,= =20 underestimates how sentimental they are about their rules. It may seem like= =20 a silly delusion, but they obviously value them or they wouldn't spend so= =20 much on them.=20 I think this would be a very effective measure against the types of trends= =20 we are seeing today, and materially reduce the UTXO set either way. *"The proposed gain is some negligible one time reduction in utxo disk=20 space. You motivated it by claiming this is a 'memory usage' reduction, but= =20 it's not-- it's just full node storage in particular as the txouts in=20 question are normally sized and largely quiescent already-- so the savings= =20 is pretty insignificant. "* I have a lot to learn, because reading this is a significant challenge to= =20 my worldview. I have been under the impression that bloat to the live state= =20 (chainstate) is one of the most harmful aspects of things like the=20 fakepubkey threat. This becomes more nuanced when we think of future=20 implementations that don't have a separate chainstate at all, but ignoring= =20 those, one of the central reasons stated for removing the recent OP_RETURN= =20 limits was to reduce potential UTXO bloat from applications like Citrea.=20 There are several proposals now to address this bloat, and this is the=20 first time I'm hearing someone consider 40% of the current state to be a=20 *negligible *amount. *"And moreover the proposal would intentionally and knowingly confiscate=20 millions of dollars in funds. This is outright theft, and I believe it=20 makes the idea a total non-starter."* Millions of dollars certainly seems like a lot of money, but these UTXOs=20 are less than $1 on average. It is only due to the massive size of the=20 stated problem that they collectively represent such a significant amount= =20 of funds. It's my contention that the users of these satoshi are not=20 intending to use them for their satoshi value whatsoever. They are simply= =20 using these as data points tracked in a database to facilitate a gambling= =20 trend. I don't say that to judge the behavior for moral reasons, but to highlight= =20 an abuse of the incentives in the Bitcoin network. The defense against dust= =20 spam in Bitcoin is the use of a fee market. This is a very effective=20 incentive that makes it expensive and usually pointless to create a lot of= =20 smaller UTXOs rather than a few large ones. The problem with the abuse we= =20 see from schemes like ord is that they ignore this dynamic by adding an=20 external incentive that pays much more than the satoshi themselves are=20 worth, sidestepping the filter and creating a dynamic that was never=20 imagined by the design. As an open system, this kind of abuse is hard to stop once it starts. My=20 proposal stands as a way to address it and add new dynamics that aim to=20 reduce the demand for such behavior by understanding it and addressing it= =20 in a way specific to its creation, which is to destroy trust in the markets= =20 that cause them. I presume you would not even be okay with the potential=20 burning of a single satoshi even if it meant clearing up something people= =20 felt was a material problem to the network, so of course you'll certainly= =20 take issue with this. It is thanks in part to your uncompromising culture= =20 that protects what Bitcoin is in the first place.=20 *"As an aside, since the idea fails so easily on basic principled grounds= =20 it's a disrespectful waste of participants time to advance a proposal at=20 such length and *technobabbly* depth which could have been floated with a= =20 single sentence "How would people feel about a proposal to discourage NFTs= =20 by identifying a snapshot of existing dust-value NFT outputs and making=20 spending them consensus invalid?" or similar. Much of the opposition to= =20 LLM use in the field of BIP discussion has been due to widespread misuse of= =20 LLMs to create thickets of dense language and obscure non-starter, trivial,= =20 or ill considered proposals making them much more costly to deal with and= =20 discouraging serious and thoughtful review of *all* ongoing discussion."* This is a very fair point; in hindsight I feel my proposal was much too=20 detailed for this stage of discussion. To be honest, I felt intimidated=20 proposing to this list and wanted to be sure that I had put in enough work= =20 to demonstrate the seriousness of my idea. I think I could have done it=20 with a summary that linked to additional details instead. I did not use an LLM to create my proposal, though I do use LLMs as a tool= =20 for research and occasional formatting. I do not think LLMs should be used= =20 in place of human ideas. My proposal was written by me (and the friends who= =20 helped me) in every part, and only edited for style or grammar by a machine= . On Tuesday, December 30, 2025 at 9:51:56=E2=80=AFAM UTC-5 Antoine Riard wro= te: > 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 lis= t=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 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= . > > I'm fully sharing waxwing reasonable opinion. While I can understand=20 > gmax's 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 ris= k=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 hav= e=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 th= e=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: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1c= e > 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 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 >> >> 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 = as=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 t= hey=20 >> are still distinct. I hold that same belief even when we are talking abo= ut=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=20 >> number of contributors here: just as it is hard to define spam on Bitcoi= n,=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 li= st=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 n= ot=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 parenthetica= l. >> >> Just my opinion of course, I know that moderation of lists is not a=20 >> 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 consensus parameter, it's just a number=20 >>> pulled out of the air that didn't seem unreasonable based on average fe= e=20 >>> behavior. But in any particular block transactions may need no particu= lar=20 >>> fee level at all, including zero fees. And in some cases it may be ver= y=20 >>> economically advantageous to spend an output even if its face value doe= sn't=20 >>> support it, NFT's being a one such example (although one I consider pre= tty=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 goin= g 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 = need=20 >>> to be cached in ram). It also appears to be uninformed by advances lik= e=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 spen= ding=20 >>> on NFT traffic a requirement to keep it over some (reasonable) threshol= d=20 >>> would not likely discourage it, or the fact that existent NFT outputs a= re=20 >>> generally over the dust limit in any case (so the proposals failure to = meet=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 g= oing=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 disc= uss=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 misgui= ded=20 >>> proposals.=20 >>> >>> >>> On Tue, Dec 23, 2025 at 6:27=E2=80=AFPM John wr= ote: >>> >>>> 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 unspend= able.=20 >>>> At each halving block, UTXOs that have remained below the dust thresho= ld=20 >>>> since the previous halving become unspendable. These UTXOs become=20 >>>> unspendable and may be pruned from the UTXO set entirely, reducing nod= e=20 >>>> storage requirements and eliminating the economic model that incentivi= zes=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 t= o=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=20 >>>> problems: >>>> >>>> 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=20 >>>> stamp outputs, the proposal makes subjective judgments about which Bit= coin=20 >>>> uses are legitimate. This sets a precedent for protocol-level=20 >>>> discrimination. >>>> >>>> 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes= =20 >>>> workarounds. If Ordinals dust is targeted, protocols will adapt to cre= ate=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 perman= ent=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 o= utput=20 >>>> is worth. These UTXOs are already "dead" in practice; this proposal si= mply=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 exactl= y=20 >>>> 546 sats; the minimum required to meet the dust limit for P2PKH addres= ses=20 >>>> and ensure transferability across all address types. This "postage" am= ount=20 >>>> is standard across inscription tooling and marketplaces. >>>> >>>> A threshold of 999 sats captures the vast majority of inscription UTXO= s=20 >>>> without requiring any protocol-specific targeting. The economic model = of=20 >>>> inscriptions depends on these dust-level UTXOs being spendable; Lynx b= reaks=20 >>>> that model through neutral, threshold-based rules rather than list-bas= ed=20 >>>> discrimination. >>>> >>>> Specification >>>> >>>> Definitions >>>> >>>> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats= =20 >>>> is 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 w= ere=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 = wish=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 dynami= c=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 acti= on >>>> - 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 outpo= ints.=20 >>>> When a node receives a transaction spending an outpoint not in its UTX= O=20 >>>> set, it rejects it as invalid =E2=80=94 the node doesn't need to know = why 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 lo= gic. >>>> >>>> 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 contai= n=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 UTXO= s=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 i= f=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 economicall= y=20 >>>> significant to spend, this would indicate broader success of the netwo= rk;=20 >>>> and the community could choose to lower or eliminate the threshold thr= ough=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 steganograp= hy"=20 >>>>> can change that. If you're imagining that perhaps they are *presume= d* 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 = would=20 >>>>> only increase the potential for mistakes. >>>>> >>>>> These costs are just another reason why this hysteria over a non-issu= e=20 >>>>> is misplaced. >>>>> >>>>> But in any case it is better that (any) implementations that care=20 >>>>> about stamps put in the effort to define their exclusions in ways tha= t are=20 >>>>> safe than to burden everyone with a consensus change that doesn't car= e=20 >>>>> about it. >>>>> >>>>> >>>>> On Fri, Dec 19, 2025 at 1:49=E2=80=AFAM Jonathan Voss =20 >>>>> 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 cou= ld=20 >>>>>> cause one of those otherwise unspendable outputs to be spendable, th= us=20 >>>>>> causing a fork between those nodes that adopted the Stamp pruning me= thod=20 >>>>>> and those that did not once one of those steganographic Stamps is sp= ent.=20 >>>>>> Though this is unlikely, it is still technically possible, and I wou= ld 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 Maxwel= l 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,=20 >>>>>> send 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-1= fd169f1a159n%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/= 521249b0-a9a8-4fc1-b975-c6c80b8ddb01n%40googlegroups.com. ------=_Part_28495_1298731202.1769044498735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list,

I=E2=80=99m reposting the reply below that I wrote on D= ec 11. I later discovered I had accidentally emailed it directly to Greg in= stead of sending it to the list, and I wrongly inferred that it was being b= locked. I then made public comments implying censorship, an embarrassing mi= stake that was entirely my own.

My apologies to the moderators, = Greg, and anyone misled by that. I=E2=80=99m participating in good faith an= d want to keep the focus on the technical merits.

Here is the me= ssage as originally sent:

Hi Greg,
When you say I misunderstood your quote, are you referring to the notion= that you thought we should try to shape behavior? You also said your reaso= n for caring about motivation in the first place was because you didn't wan= t to give the wrong impression about what was "kosher". Both you and Sipa (= who also stated in that thread "The problem is that people may see this as = a legitimation of the storage in the first place, and encourage doing so ev= en more.") seemed to be primarily motivated by the social signals that woul= d be sent by allowing even a small amount of data to be used arbitrarily in= the protocol, but felt (from my reading) that it may be worth the trade-of= f for, as you said, shaping users to more conservative needs.

I = certainly appreciate your larger point here, where you state that current u= se has nullified previously effective means of curbing this behavior, and a= s you say, sometimes even further increasing it. This is precisely why my p= roposal exists as it does. It acknowledges that these attempts to "stop" th= e behavior are not effective against strong financial incentives to overcom= e them. They would also eventually lead to more harmful abuse; typically th= is filter discussion lands at the threat of fake pubkey use, which has gene= rally been seen as the most harmful way to include data in the system.

My proposal attempts to destroy trust in those markets, to reduce th= e desire to spam in the first place.=C2=A0

"Were such a proposal se= riously advanced it would likely cause a new flood of transactions both to = move to evade it directly and as a result of NFT indexer changes to just "w= ormhole" the tokens to new outputs after the fact (and a new marketing oppo= rtunity=C2=A0for the NFT gifters).=C2=A0 NFTs are just an imaginary paralle= l world that don't depend on the network to validate their activity, so the= y don't really care about the network's rules, and as such the network's ru= les have pretty limited effect.=C2=A0 "

I understand = why you feel that way, but this is not the only way to look at it, and I'm = glad we're able to have this discussion. I am not so naive about the behavi= or of these communities and have some experience with them in the past. You= 're right: every crypto asset is essentially a narrative.

Where = I feel you don't give me enough credit is when you dismiss that the buyers = of those narratives are apathetic towards them. One of the largest debates = in the ordinal world was the value that the actual numbering system should = have at all. The entire point of ordinal theory is that they number and val= ue specific satoshi as non-fungible assets themselves. To suggest that they= would be content to assign a new satoshi with their key, I think, underest= imates how sentimental they are about their rules. It may seem like a silly= delusion, but they obviously value them or they wouldn't spend so much on = them.

I think this would be a very effective measure against th= e types of trends we are seeing today, and materially reduce the UTXO set e= ither way.

"The proposed gain is some negligible one time redu= ction in utxo disk space. You motivated it by claiming this is a 'memory us= age' reduction, but it's not-- it's just full node storage in particular as= the txouts in question are normally sized and largely quiescent=C2=A0alrea= dy-- so the savings is pretty insignificant. "

<= /div>
I have a lot to learn, because reading this is a significa= nt challenge to my worldview. I have been under the impression that bloat t= o the live state (chainstate) is one of the most harmful aspects of things = like the fakepubkey threat. This becomes more nuanced when we think of futu= re implementations that don't have a separate chainstate at all, but ignori= ng those, one of the central reasons stated for removing the recent OP_RETU= RN limits was to reduce potential UTXO bloat from applications like Citrea.= There are several proposals now to address this bloat, and this is the fir= st time I'm hearing someone consider 40% of the current state to be a=C2=A0= negligible=C2=A0amount.

"And moreover the proposal would intentionally and= knowingly confiscate millions of dollars in funds.=C2=A0 This is outright = theft, and I believe it makes the idea a total non-starter."
=
Millions of dollars certainly seems like a l= ot of money, but these UTXOs are less than $1 on average. It is only due to= the massive size of the stated problem that they collectively represent su= ch a significant amount of funds. It's my contention that the users of thes= e satoshi are not intending to use them for their satoshi value whatsoever.= They are simply using these as data points tracked in a database to facili= tate a gambling trend.

I don't say that to judge the behavior fo= r moral reasons, but to highlight an abuse of the incentives in the Bitcoin= network. The defense against dust spam in Bitcoin is the use of a fee mark= et. This is a very effective incentive that makes it expensive and usually = pointless to create a lot of smaller UTXOs rather than a few large ones. Th= e problem with the abuse we see from schemes like ord is that they ignore t= his dynamic by adding an external incentive that pays much more than the sa= toshi themselves are worth, sidestepping the filter and creating a dynamic = that was never imagined by the design.

As an ope= n system, this kind of abuse is hard to stop once it starts. My proposal st= ands as a way to address it and add new dynamics that aim to reduce the dem= and for such behavior by understanding it and addressing it in a way specif= ic to its creation, which is to destroy trust in the markets that cause the= m. I presume you would not even be okay with the potential burning of a sin= gle satoshi even if it meant clearing up something people felt was a materi= al problem to the network, so of course you'll certainly take issue with th= is. It is thanks in part to your uncompromising culture that protects what = Bitcoin is in the first place.=C2=A0

"As an aside, since the idea fails so easily on bas= ic principled grounds it's a disrespectful waste of participants time to ad= vance a proposal at such length and=C2=A0technobabbly=C2=A0depth whi= ch could have been floated with a single sentence "How would people feel ab= out a proposal to discourage NFTs by identifying a snapshot of existing dus= t-value NFT outputs and making spending them consensus invalid?"=C2=A0 or s= imilar.=C2=A0 =C2=A0Much of the opposition to LLM use in the field of BIP d= iscussion has been due to widespread misuse of LLMs to create thickets of d= ense language and obscure non-starter, trivial, or ill considered proposals= making them much more costly to deal with and discouraging serious and tho= ughtful review of *all* ongoing discussion."

This is = a very fair point; in hindsight I feel my proposal was much too detailed fo= r this stage of discussion. To be honest, I felt intimidated proposing to t= his list and wanted to be sure that I had put in enough work to demonstrate= the seriousness of my idea. I think I could have done it with a summary th= at linked to additional details instead.

I did not use an LLM to= create my proposal, though I do use LLMs as a tool for research and occasi= onal formatting. I do not think LLMs should be used in place of human ideas= . My proposal was written by me (and the friends who helped me) in every pa= rt, and only edited for style or grammar by a machine.

On Tuesday, = December 30, 2025 at 9:51:56=E2=80=AFAM UTC-5 Antoine Riard wrote:
Hi list,

> = Which brings me to my disagreement, 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 s= uggestions which *I* think are terrible, or detrimental, on a list like thi= s, should never be disallowed here. Notions of motivation of contributors (= such as they are paid by such and such a company) should not be relevant. E= verything should be open to discussion which is implementation-technical (s= o obviously not e.g. threats of violence or things that bring legal liabili= ty to participants or have zero relevance to Bitcoin's technical develo= pment) even if it's philosophy-motivated. And blocking should be reserv= ed either as an anti-DOS measure if volume gets out of control, or if it br= ings dangers as per the previous parenthetical.

I'm fully sharin= g waxwing reasonable opinion. While I can understand gmax's sentiment b= eing fed
up with poor coin confiscation proposals again and again on the= mailing list, the cure would be
worst than the disease. Maybe, I'm = very voltairean here, but you don't fight ill-founded opinions.
by p= ersecuting their authors (--otherwise, down the road you take the risk of s= eeing the bastille
popped up). Rather than you fight them back by doing = the work to persuade and to convince those
ideas you find stupid are ind= eed *objectively* stupid.

To me, it's a sign of strength and con= fidence that Bitcoin and its development process can
withstand and endur= e the most "outrageous" controversies. For sure, I have been enou= gh times
in the shoes of someone who has to champion controversial chang= es (cf. `mempoolfullrbf`) to not
negate that the strength of the process= is kinda traded on the back of the devs, but this is not
altering my mi= nd 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: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d1= 89c5f4d776bda558e1ce
Le mercredi 24 d=C3=A9cembre 2025 =C3=A0 17:23:48 UTC, waxw= ing/ AdamISZ a =C3=A9crit=C2=A0:
Hi Greg, list:

>=C2=A0I think t= he list should 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 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/521249b0-a9a8-4fc1-b975-c6c80b8ddb01n%40googlegroups.com.
------=_Part_28495_1298731202.1769044498735-- ------=_Part_28494_1959645434.1769044498735--