From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Dec 2025 02:05:42 -0800 Received: from mail-qt1-f186.google.com ([209.85.160.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUMVN-0005qn-6C for bitcoindev@gnusha.org; Sat, 13 Dec 2025 02:05:42 -0800 Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-4edb6a94873sf34922241cf.0 for ; Sat, 13 Dec 2025 02:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765620331; x=1766225131; 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=Ew4YJnVzkMVgCixJ6X+WPethi9iq5MLFcbSAugpZ7Mo=; b=paWkMghDji4Yzu4lle85uaI5Tm0hzPoOEqIOKqJSCeQVB6LqQxHfeEDKjKu/DZc35B VQC1xbN0LoMt8XHWGHWC9d1/Xv8H55JRixhaedl2mLwESg4xdaibIaO6NG0tF2jLFCWo k/aiQPgLZ9FaQ7LuQ3thA0n5bWK48Oa9pkav81imJhT118mXPbD5L9/079x5FGK/83BS MIB2mMiMUpacYYOdGHrCvHl7Ml58RWlASM94mg80PWX/YFX2UXzI9OH2/MN4rBp74j4Y rZekAelVijTdBTuLIrL1Y3ffUKFbrKjdRjsKxR23cWIIV6MQxApVPsh51ph6jNDFEjgg /EGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups-com.20230601.gappssmtp.com; s=20230601; t=1765620331; x=1766225131; 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=Ew4YJnVzkMVgCixJ6X+WPethi9iq5MLFcbSAugpZ7Mo=; b=lyCAMK1UsKdJOQzTMxAx3r3HYNEyVVaxAB/Y/C2pQ4NejwMA/y1mLrHUCxgNxDhGNf TvfQ/qN3hd/UibDuVkHhPf44r5i96ZpDGsxRJNwUkCVEBWpWGM11fcn2ahcZpansoC+v 2RqbRv+y5bfZX1I7IHUAyNTzmMSAQtf8wqvKEcDPabBH1QgmuZkaofl+l0PoqA6Gf0OQ TyCDqlaaIcONobiokjegX9TRgtT3pUmVk6zjPbhmVzHSsRz5KRxnNTuIxWVaOU3/w8/6 35XKOfnoN2POsGhvrH04v1Zn0xg598gcNm8LHdLfzpwPQyuDUmjpTwGlWFVyeCJ+7Vt1 wYkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765620331; x=1766225131; 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=Ew4YJnVzkMVgCixJ6X+WPethi9iq5MLFcbSAugpZ7Mo=; b=pU84sx7SXoZ1+mAvm4X74d/bzWuQ8A6FNXXRwb+NR3TUHwV4syfqhyXvHlvlhbId+n FSdS8ShGabcvy14nHfcnsquThn+Ws3MiXa9+zdclrf/4H1Qx9NWl6k1ue54mk8K/gazi 0YhrEMC9i+0shL3qt2jBu/yBCqNu08Zr7auefdHbakHnG+Q1Lq8Oy14DpPvT4sHDng/h Vo7xMAjm2whUI5LSt4ZfI4XU3c9Cq0g8Eq2cGwU/6GGpienb3VJZJv7lnt21Q7GmZD1r SMTVRAApVPvVcCJaaxVwHU3hZuJx/RDKvgWFHD53wJdLmdrnZaq0bcqX6DDvE6rp4ur6 DE9g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUYTRcMIkxQ89yoYjDO372rdUSz7YxTj3cVxCn3GyVyvyzpV5h86mDASVvf6VxvajWiR+NZ/ntbifO0@gnusha.org X-Gm-Message-State: AOJu0YwRfOCodE36usM3DMdnj4f934uAHRSSWUA1sOYbahF9T5CzpQlI DyuUdBuRW0CFU6iDoJrBzYbN667qFLPjPtgunqI8oFqRTccZCrBAov1a X-Google-Smtp-Source: AGHT+IHypzN0J45r94B7FNxVq7Q04jm+rnoz5vMqDcA2BeUzrwOwDvHC26pTfmEOfh56yRM5BXEUyQ== X-Received: by 2002:a05:622a:5c92:b0:4ee:ce1:ed8a with SMTP id d75a77b69052e-4f1d0467092mr77914671cf.16.1765620330592; Sat, 13 Dec 2025 02:05:30 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbGCn3ModSA7yspF/NNAu/nAdcrzlAsg89wkznAENwnww==" Received: by 2002:a05:622a:4d3:b0:4ec:f039:2eda with SMTP id d75a77b69052e-4f1ced614a2ls30888641cf.2.-pod-prod-09-us; Sat, 13 Dec 2025 02:05:24 -0800 (PST) X-Received: by 2002:a05:620a:700a:b0:8b2:e990:5114 with SMTP id af79cd13be357-8bb3a210da0mr677385285a.42.1765620324161; Sat, 13 Dec 2025 02:05:24 -0800 (PST) Received: by 2002:a05:690c:48c1:b0:786:6c46:840 with SMTP id 00721157ae682-78e642e9732ms7b3; Thu, 11 Dec 2025 12:54:23 -0800 (PST) X-Received: by 2002:a05:690e:1885:b0:644:7398:6683 with SMTP id 956f58d0204a3-64473986890mr5536856d50.4.1765486462355; Thu, 11 Dec 2025 12:54:22 -0800 (PST) Date: Thu, 11 Dec 2025 12:54:21 -0800 (PST) From: Bitcoin Mechanic To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com> Subject: Re: [bitcoindev] The Cat, BIP draft discussion. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18428_2109494127.1765486461944" X-Original-Sender: bitcoinmechanic@ocean.xyz 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.7 (/) ------=_Part_18428_2109494127.1765486461944 Content-Type: multipart/alternative; boundary="----=_Part_18429_159114535.1765486461944" ------=_Part_18429_159114535.1765486461944 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, (for response to Claire, list, please scroll down) >The situation today is entirely different: Techniques to minimize usage=20 are well understood, widely deployed, and the cost of storing data that way= =20 is very high so none happens except by those who are very motivated and=20 financially capable (and that motivation and means results in speed bumps= =20 having little effect... This isn't true. It's the classic "survivorship bias" mistake that gets=20 made constantly throughout the general discussion about arbitrary data.=20 You're trying to count road traffic accidents that didn't occur due to the= =20 existence of said speed bumps which can only be done through indirect=20 analysis for obvious reasons. Every time this comes up, people can point to= =20 things as minimal as a tweet from someone influential with the Bitcoin=20 space saying something to the tune of "I don't like spam" that results in= =20 some scam built on top of Bitcoin tanking to zero and its ecosystem dying.= =20 The easiest example is always Vitalik explaining his decision to make ETH= =20 elsewhere and not on Bitcoin due - in part - to spam filters which today=20 you all decided "don't work" despite having demonstrably helped in keeping= =20 Bitcoin separate from that dumpster fire -=20 https://x.com/VitalikButerin/status/929805462052229120 tldr: It doesn't matter if anti-spam mechanisms are not water-tight. You=20 acknowledging that "they have little effect" is an admission of the fact=20 that they have *some* effect which is fine - assuming the tradeoffs are=20 acceptable. I am certainly happy to work within those confines - and indeed= =20 have been for this entire discussion. Spam mitigation cannot come at too=20 great of a detriment to other aspects of Bitcoin and "The Cat" is certainly= =20 reasonable to consider over the line (though I'm not sure where I stand yet= =20 - so I appreciate any further discussion on the topic.) Philosophically UTXO deletion is counter to Bitcoin's ethos, no one would= =20 deny it. Practically speaking however, we all know that's it's perfectly=20 reasonable to dismiss a large % of the UTXO set as junk (regardless of if= =20 The Cat or similar were to activate). >>negligible one time reduction in utxo disk space I would never have considered The Cat if such a large % wasn't garbage. But= =20 at present, it looks to be somewhere between 40-50% of it - and deleting=20 that would not be negligible. For a maximally pruned node that's a 50%=20 reduction in disk space and when people run vast arrays of nodes in the=20 cloud (large miners do this for obvious reasons) the savings quickly become= =20 non-negligible. >NFTs are just an imaginary parallel world that don't depend on the network= =20 to validate their activity, so they don't really care about the network's= =20 rules, and as such the network's rules have pretty limited effect. =20 "Stamps" are unspendable anyway by design and thus, we'd just be saving=20 some disk space for ourselves - true. It would have no effect on what=20 they're doing, we're just cleaning up their essentially abandoned trash. For other spam however, they do in fact need their outputs to remain=20 spendable. Making their "art" unspendable would massively disrupt that=20 activity. For any serious protocol that wants to trick Bitcoin nodes into= =20 storing useless data (from the perspective of monetary users of Bitcoin)=20 they can always be pushed to asking themselves "why don't we do this on=20 another network that isn't going to delete our ability to spend our 'art'?" Again, it doesn't matter how dissuasive an effect this conversation - or=20 even activation of The Cat or any other spam-mitigation - has. If it has=20 *some* effect then it's just a question of making sure the tradeoffs are=20 worth it. That is all you can ever hope for in reducing spam on any=20 protocol. I don't think it's at all reasonable to say that making an eight figure=20 amount of NFTs/Inscriptions etc unspendable would have more than a "pretty= =20 limited effect". >This is outright theft No it isn't. It's more akin to "destruction of property". No one acquires= =20 this "stolen property" as it ceases to exist. >AI It really isn't relevant. This is sadly becoming a trope, to just complain= =20 that proposals people don't like are "written by AI". I did suggest that=20 people should declare to what extent AI was/wasn't used in an effort to=20 update etiquette to current circumstances. I don't find the proposal=20 ridiculous, though also not prepared to fully endorse it either as I'll go= =20 into below. I replied with my stance on The Cat below if you're interested. --- Hi Claire, list, I don't wish for this to be taken as strong support or advocacy as I=20 genuinely am not that "Crossing the Rubicon" with UTXO deletion is worth=20 it, though I also find concerns that I have encountered on social media=20 about precedent to be overblown. Mechanisms for UTXO deletion exist within= =20 Bitcoin regardless of if The Cat were to activate or not. The motivation to= =20 employ them does not necessarily extend to government blacklisting simply= =20 by virtue of them having been utilized to delete the UTXOs that this=20 specific proposal would target. I think anyone of capable of the slightest discernment can tell the=20 difference between what this proposal dubs "NMUs" versus genuine UTXOs, and= =20 that it would succeed in its goal of making it far more difficult to=20 convince suckers to buy some future Bitcoin-using-NFT given the network's= =20 exercised ability and willingness to throw what they're doing in the=20 garbage. I have been aware of this proposal for a couple of weeks, and it started=20 getting discussed on social media prior to here. Not once in this time have I had the sinking feeling that if this were to= =20 succeed, that it'd call my UTXOs into question as I just do not for a=20 minute believe people running Bitcoin nodes would ever activate a fork that= =20 targeted anything more than what "The Cat" seeks to eliminate, *or similar*= . Many are aware of my position on spam filtration. Spam filters reject=20 "valid transactions" as is happily pointed out by supposed ideologues who= =20 have no understanding of how nodes typically function or indeed how they=20 must continue to operate. I am, for the record, in favour of nodes=20 rejecting abusive activity, regardless of their protocol validity and=20 consider this trivially moral for those who believe in property rights. The Cat calls property rights into question by deleting UTXOs. I don't=20 consider it unreasonable for Bitcoin users to do this if they see fit as=20 the UTXO set is something that they must contribute resources to=20 maintaining in perpetuity, as opposed to simply leaving unmolested and=20 ignored. (And interestingly, the "property" the spammers claim to be=20 concerned with is the data itself, not the ability to move it, and that's= =20 maintained even post "The Cat" save for, though I don't want to=20 misrepresent what their intention is - the only reason they're interested= =20 in owning this "art" is so that they can sell it and The Cat would make=20 them unable to sell it without having to route around Bitcoin rug-pulling= =20 their ability to do so.) Therefore I see no relevant philosophical difference between filtering=20 "valid transactions" and deleting "valid UTXOs" if the discernment required= =20 in separating egregious abuse of the network from intended usage is minimal= =20 - which it certainly is with regard to the current spam. It's almost all=20 sitting conveniently at the various dust limits with glaringly obvious=20 footprints, necessarily publicly indexed on websites/explorers with well=20 known software made for the purposes of interacting with those ecosystems= =20 that can be recreated for the purposes of slating their associated UTXOs=20 for deletion. (Philosophical tidbit: both filtration and UTXO-deletion get characterized= =20 as 'censorship', which of course is false in both cases: Bitcoin users are= =20 not acting on behalf of a government and instead simply doing what's in=20 their best interest.) In practice, and far more importantly, the difference between spam=20 filtration and deleting NMUS is the fact that a bad spam filter is no big= =20 deal. It can be routed around and simply fixed if necessary and there's no= =20 getting rid of them from nodes anyway. Mistaken UTXO deletion on the other hand would be disastrous. Recovery from= =20 that would be a mess to say the least. So the snapshot taken by "The Cat" would need to be extremely well vetted= =20 which I believe the proposal actually covers extremely well as my natural= =20 concern would be a too small a % of the Bitcoin community verifying its=20 contents and thus trusting third parties to have indexed all these junk=20 UTXOs accurately. I cannot believe people would be so sloppy in that regard= =20 given that their UTXOs could be what end up in that list so hopefully - as= =20 the proposal itself states - that should become a motivation for a huge=20 number of people verifying the contents of the list. So in summary, my concerns with The Cat are too few independently indexing= =20 and attesting to the NMU list which again, the proposal addresses=20 satisfactorily in my opinion. I remain unwilling to advocate for this proposal any more strongly than I= =20 have done here, but would appreciate more substantial push back from others= =20 who dislike it because as it stands currently, I would not be unhappy if=20 this ended up successfully activating. Kind regards, Bitcoin Mechanic On Thursday, December 11, 2025 at 7:30:56=E2=80=AFAM UTC-8 Greg Maxwell wro= te: > You misunderstood my message that you've quoted-- understandable because= =20 > today Bitcoin usage today is very different than back then. In September= =20 > 2013 the average bitcoin blocksize was 120 kbytes and, as a result, there= =20 > was no meaningful market competition for block space at the time. As a= =20 > result there was essentially no incentive to minimize data usage in=20 > transactions and there was fairly little awareness of the potential means= =20 > to do so, beyond simple limits like things not relaying. The situation= =20 > today is entirely different: Techniques to minimize usage are well=20 > understood, widely deployed, and the cost of storing data that way is ver= y=20 > high so none happens except by those who are very motivated and financial= ly=20 > capable (and that motivation and means results in speed bumps having litt= le=20 > effect, -- or even positive effect, as the remaining abuses appear to fin= d=20 > bitcoin's costs/restrictions highly desirable to create scarcity for thei= r=20 > tokens). > > On your proposal, > > 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, b= ut=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 saving= s=20 > is pretty insignificant. Were such a proposal seriously advanced it woul= d=20 > likely cause a new flood of transactions both to move to evade it directl= y=20 > and as a result of NFT indexer changes to just "wormhole" the tokens to n= ew=20 > outputs after the fact (and a new marketing opportunity for the NFT=20 > gifters). NFTs are just an imaginary parallel world that don't depend on= =20 > the network to validate their activity, so they don't really care about t= he=20 > network's rules, and as such the network's rules have pretty limited=20 > effect. =20 > > 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. > > 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 NFT= s=20 > by identifying a snapshot of existing dust-value NFT outputs and making= =20 > spending them consensus invalid?" or similar. Much of the opposition t= o=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, trivia= l,=20 > or ill considered proposals making them much more costly to deal with and= =20 > discouraging serious and thoughtful review of *all* ongoing discussion. > > > > > On Wed, Dec 10, 2025 at 6:12=E2=80=AFPM Claire Ostrom =20 > wrote: > >> Dear Bitcoin-dev, >> >> Given recent discussions surrounding the malincentives of spam and the= =20 >> perceived futility in addressing these issues, I felt it necessary to=20 >> propose a working solution. For those interested, I have written a brief= =20 >> history of the problem; please skip to =E2=80=9CThe BIP=E2=80=9D below i= f you are only=20 >> interested in the proposal. >> >> Bitcoin is a peer to peer open source monetary network created to=20 >> facilitate online payments between individuals without trust in a third= =20 >> party. By its nature as an open protocol, and its censorship-resistant= =20 >> design with no single authority maintaining its operation, we have to re= ly=20 >> on incentives and culture for network stewardship. Historically, we saw= =20 >> many trends emerge which threatened Bitcoin=E2=80=99s primary use as a m= onetary=20 >> network. They were successfully dealt with by introducing OP_Return with= a=20 >> small limit as a more efficient and limited way of directing non-monetar= y=20 >> data to a provably non-spendable space that could more easily be pruned= =20 >> from nodes and, importantly, not pollute the UTXO set. >> >> Legendary Bitcoin developer Gregory Maxwell said at the time, =E2=80=9CP= art of=20 >> the idea here is shaping behavior towards conservative needs.=E2=80=9D= =20 >> >> >> This was enforced through standardness filters, which are a way of=20 >> discouraging certain types of transactions that, while technically=20 >> consensus valid, we have agreed as a community are usually not used in= =20 >> standard practice and are potentially harmful. >> >> In recent years, these trends have come back into focus with the creatio= n=20 >> of schemes like Ordinal theory and its associated inscriptions, and Bitc= oin=20 >> Stamps, which are techniques for embedding non-monetary data (like image= s=20 >> or tokens) into Bitcoin transactions. Ordinals typically hide data in th= e=20 >> Taproot witness field (benefiting from a weight =E2=80=9Cdiscount=E2=80= =9D), while Stamps=20 >> encode data in unspendable outputs (e.g., fake bare multisig addresses).= =20 >> These practices turn the blockchain into a data storage system rather th= an=20 >> purely a payments network. As anyone familiar with basic economics knows= ,=20 >> what you subsidize, you get more of. >> >> Critically, many Ordinal inscription and Stamp transactions create dust= =20 >> outputs (tiny UTXOs of only a few hundred sats) that remain unspent=20 >> indefinitely, bloating the UTXO set. Because Stamp outputs are expected = to=20 >> remain unspent indefinitely, they persist in the UTXO set forever. >> >> Veteran Bitcoin developer Mark =E2=80=9CMurch=E2=80=9D Erhardt has descr= ibed the stamps=20 >> UTXO issue as =E2=80=9Cprobably, from a technical perspective, one of th= e more=20 >> egregious uses of blockchain."=20 >> >> >> [image: Screenshot 2025-12-01 212654.png] >> >> Over roughly 14 years (2009-early 2023), Bitcoin=E2=80=99s UTXO set grew= =20 >> gradually to around 80-90 million entries. Then, in less than a year, it= =20 >> doubled to more than 160 million by late 2023, a historic anomaly driven= =20 >> largely by the Ordinals and Stamps craze. Analyses suggest that by=20 >> mid-2025, over 30% of all UTXOs were tied to Ordinal inscriptions. Nearl= y=20 >> half of all UTXOs (around 49%) now contain less than 1,000 satoshis,=20 >> strongly indicating they are spammy dust outputs used for data embedding= =20 >> rather than normal economic activity. Many of these are Taproot outputs = or=20 >> outputs sitting exactly at the standard dust threshold, consistent with= =20 >> algorithmic spam creation. In short, UTXO spam now accounts for tens of= =20 >> millions of entries and represents an unprecedented explosion of UTXO bl= oat. >> >> The UTXO database (chainstate) has ballooned alongside this spam. Before= =20 >> 2023, the chainstate was on the order of 4-5 GB; by early 2024 it exceed= ed=20 >> 11 GB, meaning the disk footprint required to hold the unspent set rough= ly=20 >> doubled in about a year, in line with Ordinals and BRC-20 mania. Over th= e=20 >> same period, the full blockchain grew by about 93 GB in 2023 alone, vers= us=20 >> roughly 55 GB per year previously, largely due to inscription data filli= ng=20 >> blocks. While pruned nodes can discard old block data, they cannot disca= rd=20 >> UTXOs: every unspent output, even spam, must remain in the chainstate un= til=20 >> it is spent or explicitly removed by a protocol change. This makes UTXO= =20 >> spam a permanent, compounding burden on full nodes. As Bitcoin developer= s=20 >> have noted, techniques that deliberately embed data in UTXOs are among t= he=20 >> most egregious abuses of the system, precisely because they clutter the= =20 >> UTXO set with junk that cannot be pruned away under current rules. >> >> Bitcoin=E2=80=99s design includes some anti-spam measures, but spammers = have=20 >> continually evolved =E2=80=9Ccat-and-mouse=E2=80=9D tactics to bypass th= em. >> >> This is where our proposal comes in. >> >> THE BIP: The Cat. >> >> >> Recent attempts to reduce spam have focused on the supply side, trying t= o=20 >> stop spam through policy and standardness rules. These efforts have had= =20 >> limited success. The Cat instead looks to economics, removing or reducin= g=20 >> the financial incentive for creating spam outputs in the first place. It= =20 >> targets the demand side by making designated Non-Monetary UTXOs (NMUs)= =20 >> permanently unspendable, which in turn reduces market demand for those= =20 >> assets. >> >> >> The Cat defines a fixed, reproducible set of =E2=80=9CNMUs=E2=80=9D usin= g established=20 >> external indexers, and makes them permanently unspendable by consensus, = so=20 >> that such data cannot be monetized or transacted, only archived. Once=20 >> rendered unspendable, we will be removing these UTXOs made unspendable b= y=20 >> consensus under this proposal, from the UTXO set, materially reducing th= e=20 >> current resource requirement for nodes (likely on the order of tens of= =20 >> millions of UTXOs, roughly ~30% of the set, subject to measurement). The= =20 >> NMU classification itself is encoded in a compact membership structure (= a=20 >> Binary Fuse Filter plus a false-positive exclusion list) that ships with= =20 >> the binary and does not require any node to reindex or re-download the= =20 >> chain. >> >> >> >> Draft Specification >> >> >> Status: Discussion draft. A formal BIP, compliant with BIP 0003 and the= =20 >> usual BIP process, will be prepared if there is interest in pursuing thi= s=20 >> direction. >> >> >> 1. Definitions >> >> >> Non-Monetary UTXO (NMU): >> >> >> A UTXO that is classified as containing inscription-style or stamp-style= =20 >> data according to the procedure in =C2=A72 and that satisfies the value = and=20 >> creation-height constraints below. >> >> >> NMU bit: >> >> >> A single Boolean flag (0 or 1) stored alongside each UTXO in the node=E2= =80=99s=20 >> UTXO database: >> >> >> >> -=20 >> =20 >> NMU =3D 1 -> UTXO is non-monetary and may not be spent. >> =20 >> >> >> -=20 >> =20 >> NMU =3D 0 -> UTXO is monetary (normal behavior). >> =20 >> >> Conceptually, NMU =3D 1 means =E2=80=9Cthis outpoint is in NMUSet_snap a= s defined=20 >> by this BIP.=E2=80=9D Implementations MAY choose to compute this bit on = the fly=20 >> from the membership structure rather than store it explicitly; see =C2= =A73. >> >> >> NMU value threshold: >> >> >> A consensus constant VALUE_MAX_NMU =3D 1000 satoshis. Only UTXOs with va= lue=20 >> strictly less than VALUE_MAX_NMU are eligible to be classified as NMU.= =20 >> UTXOs with value greater than or equal to VALUE_MAX_NMU MUST be treated = as=20 >> monetary (NMU =3D 0) for all time under this BIP, even if external tools= =20 >> associate inscriptions or stamps with some of their satoshis. >> >> >> NMU creation-height window: >> >> >> This proposal intentionally restricts NMU classification to UTXOs create= d=20 >> between: >> >> >> H_min_NMU: the earliest block height at which the reference indexers (Or= d=20 >> 0.24.0 and the specified Stamps version) first recognize any=20 >> inscription-style or stamp-style NMU, and >> >> >> H_snap: the snapshot height defined in =C2=A72.4. >> >> >> Both H_min_NMU and H_snap are consensus constants fixed before=20 >> activation. Any UTXO created at height < H_min_NMU or > H_snap MUST be= =20 >> treated as monetary (NMU =3D 0) regardless of filter results. >> >> >> NMU membership structure (NMU_DATA): >> >> >> A static, exact membership structure that encodes NMUSet_snap using: >> >> >> >> -=20 >> =20 >> A Binary Fuse Filter (BFF-8) constructed from all eligible NMU=20 >> outpoints; and >> =20 >> >> >> -=20 >> =20 >> A false positive exclusion list (FP_EXCLUDE) that contains all=20 >> non-NMU outpoints at H_snap that would otherwise match the filter. >> =20 >> >> NMU_DATA is distributed as a single binary blob, together with a=20 >> consensus constant NMU_DATA_HASH =3D SHA256d(NMU_DATA) which all complia= nt=20 >> implementations MUST verify before using it for consensus validation (se= e=20 >> =C2=A73.3). >> >> >> Activation height (H_cat): >> >> >> A consensus constant H_cat, the block height at which the NMU spending= =20 >> rule in =C2=A74 first becomes eligible for enforcement. The exact value = and=20 >> deployment mechanism for H_cat are out of scope for this draft and would= be=20 >> specified in a formal BIP. >> >> >> 2. NMU classification (reproducible list) >> >> >> The normative consensus object introduced by this BIP is the set=20 >> NMUSet_snap: a fixed set of outpoints classified as non-monetary at=20 >> snapshot height H_snap on the best chain, after applying the value and= =20 >> height restrictions in =C2=A71 and =C2=A72.3. >> >> >> Consensus enforcement of The Cat only depends on whether an outpoint is= =20 >> in NMUSet_snap or not; it does not depend on how any particular node=20 >> obtained that set. >> >> >> To define NMUSet_snap in a precise and reproducible way, this BIP=20 >> specifies two reference classification rule sets that operate purely on= =20 >> Bitcoin chain data, as implemented in: >> >> >> >> -=20 >> =20 >> Ord 0.24.0 at commit 5d2fbbe64b362cd6c30d6901e50cbe80084761f8 >> =20 >> >> >> -=20 >> =20 >> Stamps - [exact version/commit to be pinned before any activation] >> =20 >> >> These reference implementations define the inscription-style and=20 >> stamp-style classification rules in terms of Bitcoin chain data. They ar= e=20 >> cited here as normative descriptions of how to decide whether a given=20 >> outpoint carries an inscription or a stamp at height H_snap. >> >> >> Implementations that wish to independently derive or verify NMUSet_snap= =20 >> MAY: >> >> >> >> -=20 >> =20 >> Execute these reference implementations from genesis up to H_snap, or >> =20 >> >> >> -=20 >> =20 >> Independently re-implement the same classification rules and confirm= =20 >> that the resulting set of outpoints matches the NMU set implied by NM= U_DATA. >> =20 >> >> Running Ord or Stamps is not required for ordinary full-node operation= =20 >> under this BIP; they are simply the canonical specification of the=20 >> classification logic. >> >> >> This section uses the consensus constants H_cat, H_snap, and H_min_NMU a= s=20 >> defined in =C2=A71. >> >> >> 2.1 Ord NMU set >> >> >> According to the classification rules implemented in Ord 0.24.0 at commi= t=20 >> 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is parsed for=20 >> =E2=80=9Cinscription envelopes=E2=80=9D and each recognized inscription = is associated with=20 >> a particular outpoint (txid, vout) on the best chain at height H_snap. >> >> >> Define OrdNMUSet as the set of all outpoints that, when those Ord 0.24.0= =20 >> rules are applied to the best chain up to H_snap, are classified as=20 >> carrying inscriptions at H_snap. Concretely, for each inscription that O= rd=20 >> 0.24.0 would associate with a specific outpoint (txid, vout) on that cha= in,=20 >> that outpoint is included in OrdNMUSet. >> >> >> This includes, for example, inscription UTXOs used by protocols such as= =20 >> BRC-20, but the BIP makes no protocol-level distinction; they are all=20 >> treated as =E2=80=9CNMU=E2=80=9D if they meet the value and height thres= holds in =C2=A72.3. >> >> >> An implementation may obtain OrdNMUSet by actually running Ord 0.24.0, o= r=20 >> by re-implementing its published classification rules and applying them = to=20 >> the chain. >> >> >> 2.2 Stamps NMU set >> >> >> According to the classification rules implemented in the specified BTC= =20 >> Stamps indexer (version/commit TBD), Counterparty metadata and Bitcoin= =20 >> transactions are parsed to identify =E2=80=9Cstamp-style=E2=80=9D embedd= ed assets and=20 >> associate them with one or more bare multisig outputs on the best chain = at=20 >> height H_snap. >> >> >> Define StampsNMUSet as the set of all outpoints that, when those Stamps= =20 >> rules are applied to the best chain up to H_snap, are classified as=20 >> containing a stamp at H_snap. For each stamp that the reference Stamps= =20 >> implementation would associate with a specific outpoint (txid, vout) on= =20 >> that chain, that outpoint is included in StampsNMUSet. >> >> >> As with Ord, an implementation may obtain StampsNMUSet either by running= =20 >> the reference Stamps indexer or by independently implementing the same= =20 >> classification rules and applying them to the chain. >> >> >> 2.3 Combined NMU set + value & height thresholds >> >> >> The initial raw NMU set at snapshot height is: >> >> >> NMUSet_raw =3D OrdNMUSet =E2=88=AA StampsNMUSet >> >> >> Apply both the NMU value threshold and the creation-height window: >> >> >> NMUSet_snap =3D { u =E2=88=88 NMUSet_raw | value(u) < VALUE_MAX_NMU and = H_min_NMU =E2=89=A4=20 >> height(u) =E2=89=A4 H_snap } >> >> >> where value(u) is the number of satoshis in UTXO u, and height(u) is the= =20 >> height of the block that created that UTXO. >> >> >> Every UTXO in NMUSet_snap MUST be treated as having NMU =3D 1 under the = new=20 >> consensus rule (see =C2=A74). Nodes MAY realize this either by pre-seedi= ng an=20 >> NMU bit in their UTXO database or by computing it dynamically via the=20 >> membership query in =C2=A73.3. >> >> >> Notes: >> >> >> Running Ord or Stamps is only required for those who wish to=20 >> independently derive and verify NMUSet_snap; it is not a requirement for= =20 >> ordinary full node operation under The Cat. >> >> >> The value threshold is intended to avoid classifying large, mixed-use=20 >> UTXOs as NMUs when a small number of inscribed satoshis have been combin= ed=20 >> with otherwise monetary funds. >> >> >> Restricting to height(u) =E2=89=A5 H_min_NMU reflects the historical fac= t that=20 >> these protocols appeared only after a certain point, and it trivially=20 >> avoids misclassification of very old UTXOs. >> >> >> This proposal intentionally does not specify any new in-client=20 >> classification rule for discovering future NMU formats. It explicitly=20 >> targets non-monetary UTXOs identifiable via Ord 0.24.0 and Stamps at the= =20 >> time of snapshot. >> >> >> 2.4 Snapshot block commitment and reorg behaviour >> >> >> This BIP commits to a specific chain history at the snapshot height=20 >> H_snap by introducing a new consensus constant: >> >> >> SNAP_BLOCK_HASH: a 32-byte value equal to the block hash at height H_sna= p=20 >> on the chain from which NMUSet_snap was originally derived. >> >> >> A node MUST only enforce the NMU consensus rule from =C2=A74 if, for its= =20 >> current best chain: >> >> >> There exists a block at height H_snap, and >> >> >> The hash of that block is exactly equal to SNAP_BLOCK_HASH. >> >> >> If, for the node=E2=80=99s current best chain, the block at height H_sna= p has a=20 >> different hash, the node MUST treat all UTXOs as monetary (NMU =3D 0) fo= r the=20 >> purposes of consensus validation, and MUST NOT reject any transaction or= =20 >> block on the basis of the NMU rule. >> >> >> In particular, if a reorganization occurs that replaces the block at=20 >> height H_snap with a different block (i.e., a reorg deeper than H_snap),= =20 >> enforcement of The Cat is automatically disabled until and unless the be= st=20 >> chain once again has SNAP_BLOCK_HASH at height H_snap. Any desire to app= ly=20 >> NMU classification to a different chain history would require a new=20 >> consensus commitment (for example, a new SNAP_BLOCK_HASH defined by a=20 >> subsequent BIP and activation process). >> >> >> 3. NMU bit storage, membership structure, and activation >> >> >> 3.1 NMU bit storage model >> >> >> Consensus only cares about which UTXOs are NMU, not how the bit is store= d=20 >> or computed. Implementations MAY: >> >> >> >> -=20 >> =20 >> Store the NMU bit as an extra bit in the UTXO database (e.g., in the= =20 >> Coin structure). >> =20 >> >> >> -=20 >> =20 >> Store NMUs in a separate structure keyed by outpoint. >> =20 >> >> >> -=20 >> =20 >> Compute NMU on the fly at validation time using the NMU_DATA=20 >> membership structure from =C2=A73.3, optionally caching results. >> =20 >> >> The only consensus requirement is: given the same chain, compliant=20 >> implementations must converge on the same NMU classification for all UTX= Os.=20 >> Conceptually, for a UTXO u with value(u) and height(u), NMU(u) is define= d=20 >> as: >> >> >> >> -=20 >> =20 >> 1 if: >> =20 >> >> >> -=20 >> =20 >> H_min_NMU =E2=89=A4 height(u) =E2=89=A4 H_snap, and >> =20 >> >> >> -=20 >> =20 >> value(u) < VALUE_MAX_NMU, and >> =20 >> >> >> -=20 >> =20 >> u =E2=88=88 NMUSet_snap (as tested via =C2=A73.3), >> =20 >> >> >> -=20 >> =20 >> 0 otherwise. >> =20 >> >> 3.2 Activation >> >> >> At activation height H_cat: >> >> >> Nodes must have: >> >> >> >> -=20 >> =20 >> Fully validated the chain up to at least H_snap. >> =20 >> >> >> -=20 >> =20 >> Loaded and verified NMU_DATA (see =C2=A73.3). >> =20 >> >> From the first block at or after H_cat for which the snapshot block=20 >> commitment condition in =C2=A72.4 holds, nodes MUST enforce the consensu= s rule=20 >> in =C2=A74, using the NMU classification defined above. No reindex or UT= XO=20 >> rewrite is required for activation; NMU classification can be applied as= an=20 >> overlay on top of the existing UTXO database. >> >> >> Implementations MAY, as an optimization, perform a one-time pass over=20 >> their UTXO set after activation to: >> >> >> >> -=20 >> =20 >> Set Coin.NMU =3D 1 for all UTXOs that satisfy the NMU predicate; and/= or >> =20 >> >> >> -=20 >> =20 >> Physically delete such UTXOs from the UTXO database (see =C2=A75). >> =20 >> >> Such a pass is a local optimization and not required for consensus,=20 >> provided the on-the-fly NMU classification via NMU_DATA would yield the= =20 >> same results. >> >> >> 3.3 NMU membership structure: Binary Fuse Filter + exclusion list >> >> >> This BIP does not require nodes to redo initial block download or reinde= x=20 >> the chain in order to enforce NMU classification. Instead, it commits to= a=20 >> canonical membership structure NMU_DATA which encodes NMUSet_snap in a= =20 >> compact form. >> >> >> 3.3.1 Canonical outpoint encoding >> >> >> For all purposes related to NMU_DATA (filter construction, querying, and= =20 >> the exclusion list), an outpoint (txid, vout) is encoded as a fixed 36-b= yte=20 >> key. >> >> >> txid_le (bytes 0=E2=80=9331): the 32-byte transaction ID in little-endia= n order,=20 >> matching the internal uint256 representation used by Bitcoin Core and=20 >> similar implementations. >> >> vout_le (bytes 32=E2=80=9335): the 4-byte output index, serialized as a= =20 >> little-endian unsigned 32-bit integer (e.g. 0 -> 00 00 00 00, 1 -> 01 00= 00=20 >> 00, 256 -> 00 01 00 00). >> >> >> This encoding is normative for NMU_DATA. All compliant implementations= =20 >> MUST use exactly this encoding when querying the filter or the exclusion= =20 >> list. >> >> >> 3.3.2 NMU_DATA serialization >> >> >> NMU_DATA is a single binary blob. All integer fields are little-endian= =20 >> and appear in the following order: >> >> >> >> -=20 >> =20 >> MAGIC (4 bytes): ASCII string "NMU1". >> -=20 >> =20 >> VERSION (1 byte): format version (initially 0x01). >> -=20 >> =20 >> SNAP_HEIGHT (4 bytes): block height H_snap. >> -=20 >> =20 >> SNAP_HASH (32 bytes): block hash at H_snap (must match=20 >> SNAP_BLOCK_HASH from section =C2=A72.4). >> -=20 >> =20 >> FILTER_SEED (8 bytes): 64-bit seed used by the Binary Fuse Filter=20 >> hash functions. >> -=20 >> =20 >> FILTER_LEN (4 bytes): length in bytes of FILTER_DATA. >> -=20 >> =20 >> FILTER_DATA (FILTER_LEN bytes): raw Binary Fuse Filter data. >> -=20 >> =20 >> FP_COUNT (4 bytes): number of false-positive entries. >> -=20 >> =20 >> FP_ENTRIES (FP_COUNT =C3=97 36 bytes): lexicographically sorted array= of=20 >> canonical 36-byte outpoint encodings that are not in NMUSet_snap but = would=20 >> otherwise match the filter. >> -=20 >> =20 >> CHECKSUM (32 bytes): SHA256d of all preceding bytes from MAGIC=20 >> through the last FP_ENTRY. >> =20 >> >> The SHA256d of the entire NMU_DATA blob is called NMU_DATA_HASH and is= =20 >> treated as a consensus constant compiled into node software. >> >> >> A node MUST NOT enforce the NMU consensus rule unless NMU_DATA passes it= s=20 >> internal CHECKSUM validation and SHA256d(NMU_DATA) equals NMU_DATA_HASH. >> >> >> 3.3.3 Binary Fuse Filter query >> >> >> The filter is a static Binary Fuse Filter over 36-byte keys with 8-bit= =20 >> fingerprints, giving an approximate false-positive rate of about 1/256. >> >> >> For a given key, a deterministic hash function derived from FILTER_SEED= =20 >> maps the 36-byte key to three byte positions inside FILTER_DATA and to a= n=20 >> 8-bit fingerprint. A membership query reads the three bytes at those=20 >> positions, XORs them, and compares the result to the fingerprint. If the= y=20 >> match, the filter reports the key as =E2=80=9Cprobably present=E2=80=9D. >> >> >> The exact mapping from a 36-byte key to three positions and an 8-bit=20 >> fingerprint, and the interpretation of FILTER_DATA, MUST follow a single= ,=20 >> fully specified algorithm (for example, a pinned =E2=80=9Cbinary fuse fi= lter=E2=80=9D=20 >> reference implementation). How FILTER_DATA was constructed is not=20 >> consensus-critical; only the query algorithm and the fixed contents of= =20 >> NMU_DATA are consensus-critical. >> >> >> 3.3.4 False positive exclusion list >> >> >> Because the Binary Fuse Filter is probabilistic, some UTXOs that are not= =20 >> in NMUSet_snap will still be reported as present at H_snap. During snaps= hot=20 >> construction, the false positive exclusion list FP_EXCLUDE is computed b= y=20 >> enumerating all UTXOs at H_snap that are not in NMUSet_snap, testing eac= h=20 >> with the filter, collecting those that match, and sorting their 36-byte= =20 >> keys lexicographically to form FP_ENTRIES. >> >> >> At runtime, FP_EXCLUDE is treated as an override: if an outpoint=E2=80= =99s=20 >> canonical key appears in FP_EXCLUDE, that outpoint MUST be treated as=20 >> non-NMU, regardless of the filter result. >> >> >> 3.3.5 Membership query (is_nmu) >> >> >> Given a UTXO u at outpoint (txid, vout), with value(u) and height(u),=20 >> nodes evaluate the NMU membership predicate is_nmu(u) as follows. >> >> >> First, UTXOs outside the NMU window are never NMUs. If height(u) is less= =20 >> than H_min_NMU or greater than H_snap, is_nmu(u) is false. >> >> >> Second, very large UTXOs are always treated as monetary. If value(u) is= =20 >> greater than or equal to VALUE_MAX_NMU, is_nmu(u) is false. >> >> >> For the remaining UTXOs, the node computes key =3D canonical_encode(txid= ,=20 >> vout) using the 36-byte encoding defined in section 3.3.1. If key appear= s=20 >> in FP_EXCLUDE (using binary search over the sorted FP_ENTRIES array),=20 >> is_nmu(u) is false. Otherwise, the node queries the Binary Fuse Filter w= ith=20 >> key. If and only if the filter reports the key as present, is_nmu(u) is= =20 >> true. >> >> >> Within the domain H_min_NMU =E2=89=A4 height(u) =E2=89=A4 H_snap and val= ue(u) <=20 >> VALUE_MAX_NMU, this predicate exactly matches membership in NMUSet_snap:= =20 >> every UTXO in NMUSet_snap is reported as NMU, and every UTXO outside=20 >> NMUSet_snap is reported as non-NMU, with no false positives and no false= =20 >> negatives. >> >> >> 4. New consensus rule >> >> >> The rule in this section is enforced only when the snapshot block=20 >> commitment condition from =C2=A72.4 holds and NMU_DATA has been successf= ully=20 >> verified. >> >> >> From the first block at or after H_cat that follows activation: >> >> >> Rule: Forbidden spending of NMUs >> >> >> A transaction is invalid if any of its inputs refers to an outpoint=20 >> (txid, vout) such that the corresponding UTXO u satisfies is_nmu(u) =3D = true=20 >> as defined in =C2=A73.3.5 (equivalently, has NMU =3D 1). >> >> >> Formally, when validating a transaction input: >> >> >> >> -=20 >> =20 >> Let (txid, vout) be the input outpoint. >> =20 >> >> >> -=20 >> =20 >> Let u =3D Coin(txid, vout) be the referenced UTXO as seen by the node= =20 >> at the time of validation. >> =20 >> >> >> -=20 >> =20 >> If u does not exist: reject as usual (unchanged behavior). >> =20 >> >> >> -=20 >> =20 >> Otherwise, if is_nmu(u) =3D true, then the transaction MUST be reject= ed=20 >> as invalid. >> =20 >> >> This rule applies: >> >> >> >> -=20 >> =20 >> To mempool acceptance. >> =20 >> >> >> -=20 >> =20 >> To block validation. >> =20 >> >> >> -=20 >> =20 >> To all future reorg scenarios, provided the snapshot commitment in=20 >> =C2=A72.4 remains satisfied. >> =20 >> >> 5. UTXO set removal and pruning >> >> >> Because NMUs are permanently unspendable after activation, they can be= =20 >> dropped from the spendable UTXO set. >> >> >> 5.1 Logical removal >> >> >> Implementations MUST treat UTXOs with is_nmu(u) =3D true (or NMU =3D 1) = as=20 >> non-existent for the purpose of: >> >> >> >> -=20 >> =20 >> Satisfying transaction inputs (they can never be used). >> =20 >> >> >> -=20 >> =20 >> Fee calculations, coin selection, wallet balances, etc. >> =20 >> >> 5.2 Physical pruning (optional) >> >> >> Nodes that operate with -prune=3D1 (or similar backwards-compatible prun= ing=20 >> configuration) MAY: >> >> >> >> -=20 >> =20 >> Omit NMUs from the on-disk UTXO set. >> =20 >> >> >> -=20 >> =20 >> Remove any previously persisted NMUs during a compaction / cleanup=20 >> pass by running is_nmu(u) on each UTXO and deleting those that return= true. >> =20 >> >> This proposal does not require pruned nodes to discard raw historical=20 >> blocks. It only authorizes pruning of UTXO entries that are permanently= =20 >> unspendable due to the NMU rule. >> >> >> Non-pruned nodes (full archival nodes) MAY continue to store historical= =20 >> blocks and full transaction data as usual. This preserves archival acces= s=20 >> to inscription / stamp data while still neutralizing it economically. >> >> >> Rationale >> >> >> This BIP makes minimal changes to the consensus surface. It adds no new= =20 >> opcodes and does not expand Bitcoin=E2=80=99s scripting language or=20 >> programmability. Instead, it introduces a single new consensus concept: = a=20 >> binary classification that marks some existing UTXOs as permanently=20 >> unspendable Non-Monetary UTXOs (NMUs). In that sense, it is closer to a= =20 >> one-time reclassification of a subset of UTXOs than an ongoing change to= =20 >> Bitcoin=E2=80=99s programming model. >> >> >> External indexers, determinism, and reproducibility >> >> >> Instead of re-implementing complex inscription and stamp classification= =20 >> rules in Bitcoin clients, this BIP relies on mature tools that are alrea= dy=20 >> used by the non-monetary data community, specifically Ord and Stamps. Ex= act=20 >> versions of these indexers are specified and pinned by commit so that th= eir=20 >> behavior is deterministic. The NMU set is defined in terms of chain data= as=20 >> seen through these specified indexers, rather than as an arbitrary=20 >> hard-coded list of UTXOs. This keeps the consensus rule grounded in=20 >> chain-derived information while avoiding the need to embed inscription= =20 >> logic directly in Bitcoin client software. >> >> >> Fixed snapshot vs future formats >> >> >> By scoping the NMU classification to what Ord 0.24.0 and Stamps (at a=20 >> pinned commit) can see at the snapshot height H_snap, this proposal=20 >> neutralizes the existing inscription and stamp economy on day one withou= t=20 >> importing evolving, open-ended classification rules into consensus. It= =20 >> treats the snapshot as a fixed historical boundary and leaves future NMU= =20 >> formats and mitigation strategies as a separate question for policy or f= or=20 >> future BIPs. If further action is desired on post-snapshot NMU formats, = the=20 >> community can consider additional updates or separate proposals without= =20 >> expanding the scope of this one. >> >> >> UTXO set size and overhead >> >> >> Because all NMUs become permanently unspendable under this proposal, the= y=20 >> can be removed from the UTXO set, which reduces its size. The new storag= e=20 >> overhead introduced by The Cat is dominated by the global membership=20 >> structure NMU_DATA, which consists of a Binary Fuse Filter over NMUSet_s= nap=20 >> plus a correction list of false positives. For a plausible NMU count on = the=20 >> order of 50 million, the filter occupies roughly 9 bits per element (=E2= =89=88 56=20 >> MB), and the exclusion list adds around 15=E2=80=9320 MB before compress= ion, for an=20 >> uncompressed size on the order of 70=E2=80=9380 MB and an expected compr= essed size=20 >> of roughly 40=E2=80=9350 MB. >> >> >> This is small relative to typical UTXO set sizes and to the on-disk=20 >> savings from pruning tens of millions of dust-sized NMUs. Per-UTXO stora= ge=20 >> overhead remains a single NMU bit if implementations choose to materiali= ze=20 >> it in the database; the rest of the classification data is stored once p= er=20 >> node. >> >> >> Censorship resistance and scope >> >> >> Bitcoin=E2=80=99s censorship resistance is primarily concerned with the = ability=20 >> to move monetary value without trusted intermediaries. This proposal=20 >> intentionally targets non-monetary uses of the chain (inscriptions, stam= ps,=20 >> and similar schemes) and leaves ordinary monetary transfers untouched.= =20 >> Reasonable people may still describe permanently disabling some UTXOs as= a=20 >> form of censorship; the distinction this BIP draws is between money and= =20 >> arbitrary data storage. >> >> >> The same type of mechanism could in principle be abused to target=20 >> arbitrary UTXOs, which is why this proposal deliberately scopes itself t= o a=20 >> one-time, transparently derived set of dust-sized non-monetary outputs. = Any=20 >> attempt to apply similar techniques to ordinary monetary UTXOs would be= =20 >> highly contentious and would require explicit social consensus from user= s,=20 >> miners, and economic nodes. In other words, this mechanism does not lowe= r=20 >> the technical or social barriers to censoring ordinary monetary activity= ;=20 >> any such censorship would still require its own explicit, contentious=20 >> change in consensus rules. >> >> >> The classification rules on which The Cat relies are deliberately narrow= =20 >> and mechanical. An output is marked as an NMU only if it is (a) identifi= ed=20 >> by the pinned Ord/Stamps rules as carrying a non-monetary artifact at=20 >> H_snap, (b) dust-sized, below the VALUE_MAX_NMU threshold, and (c) withi= n=20 >> the defined height window. The intent is that no ordinary monetary UTXOs= =20 >> fall into NMUSet_snap; any such inclusion would be treated as an error i= n=20 >> the snapshot construction and grounds to regenerate NMU_DATA before=20 >> activation, not as an acceptable trade-off. The 1,000-sat value limit=20 >> serves as an additional hard guardrail against accidentally classifying= =20 >> normally-sized wallet outputs. >> >> >> Centralization and trust model for NMU generation >> >> >> Anyone can independently generate the list of NMUs. It is incumbent on= =20 >> people to do so if they wish to minimize the trust required to run a ful= ly=20 >> validating node. The criteria for which outputs are designated as NMUs a= re=20 >> necessarily known and established by virtue of how prevalent and open th= e=20 >> targeted data protocols are. >> >> >> It is valid to worry that fewer than 100% of node runners will regenerat= e=20 >> the NMU list themselves, somewhat increasing the overall trust placed in= =20 >> third parties compared to today. However, this concern applies specifica= lly=20 >> to a =E2=80=9Cblacklist of UTXOs,=E2=80=9D which is precisely the area w= here scrutiny is=20 >> highest. That scrutiny should help ensure that enough independent partie= s=20 >> index and attest to the contents of NMUSet_snap to exceed any reasonable= =20 >> threshold of credulity. >> >> >> A useful analogy is the GUIX-based reproducible build process. Bitcoiner= s=20 >> accept that many users will only run node binaries they download, rather= =20 >> than compiling from source and independently verifying the code. Compile= d=20 >> binaries must exist for Bitcoin to maintain decentralization in practice= .=20 >> This is an aspect of trust inherent in Bitcoin: we accept some technical= =20 >> limitations of users and employ a practical, trust-minimized workaround= =20 >> that, while not perfect, is better than the alternative. >> >> >> If there were to be an issue with widely used binaries, it would become= =20 >> ubiquitously known very quickly. Similarly, if The Cat were flawed and= =20 >> began targeting monetary UTXOs, this would be detected well before=20 >> activation, and the necessary fixes applied, with any distortion of its= =20 >> motivation exposed and corrected. >> >> >> Backward compatibility >> >> >> This proposal is a consensus-changing soft fork. Legacy nodes that do no= t=20 >> implement The Cat will continue to accept blocks that spend NMUs as vali= d,=20 >> while nodes that do implement The Cat will reject such blocks as invalid= .=20 >> As with any soft fork, activation requires clear opt-in from miners and= =20 >> from economic nodes. After activation, miners and other block proposers= =20 >> must avoid including transactions that spend NMUs, because such blocks w= ill=20 >> be rejected by upgraded nodes. Wallets and applications that track=20 >> inscriptions, BRC-20 assets, and related schemes will observe that NMUs= =20 >> become permanently unspendable under The Cat and that balances associate= d=20 >> with those UTXOs are no longer movable under the activated ruleset. >> >> >> FAQ >> >> >> Do node operators need to run Ord or Stamps? >> >> >> No. The Cat does not require ordinary node operators to run Ord or=20 >> Stamps, or to understand their rules in detail. Those indexers are cited= as=20 >> normative references for the inscription and stamp classification logic= =20 >> used to derive NMUSet_snap. In practice, nodes only need the canonical= =20 >> NMU_DATA blob and its hash NMU_DATA_HASH to enforce the consensus rule. >> >> >> Anyone who wishes to independently verify NMUSet_snap can: >> >> >> inspect the open-source Ord and Stamps code, >> >> >> or re-implement equivalent classification rules, >> >> >> and confirm that the derived set of NMU outpoints matches the set encode= d=20 >> in NMU_DATA (i.e., the blob whose hash is NMU_DATA_HASH). >> >> >> What rules do the reference indexers actually use to decide which UTXOs= =20 >> are NMUs? >> >> >> This BIP does not re-specify the full Ord and Stamps protocols, but in= =20 >> broad terms: >> >> >> Ord 0.24.0 (inscriptions). >> >> According to the classification rules implemented in Ord 0.24.0 at commi= t=20 >> 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is scanned for=20 >> =E2=80=9Cinscription envelopes=E2=80=9D in Taproot script paths. An insc= ription envelope is=20 >> an OP_FALSE OP_IF =E2=80=A6 OP_ENDIF block containing data pushes that s= tart with=20 >> the ASCII tag ord and encode a content type and body. When those rules a= re=20 >> applied to the best chain up to height H_snap, each recognized inscripti= on=20 >> is associated with a particular outpoint (txid, vout) (typically the fir= st=20 >> satoshi of a reveal transaction input, or as directed by the pointer fie= ld=20 >> in the protocol). OrdNMUSet is defined as the set of outpoints that Ord= =20 >> 0.24.0 would classify as carrying inscriptions at H_snap under these rul= es. >> >> >> Stamps (BTC Stamps). >> >> According to the classification rules implemented in the pinned BTC=20 >> Stamps indexer, Counterparty transactions are inspected for a=20 >> STAMP:-prefixed base64 string in the description field, which encodes im= age=20 >> data. The Stamps rules then map this metadata to specific dust-sized bar= e=20 >> multisig outputs in the underlying Bitcoin transactions. When those rule= s=20 >> are applied to the best chain up to height H_snap, each recognized stamp= is=20 >> associated with one or more outpoints (txid, vout). StampsNMUSet is defi= ned=20 >> as the set of outpoints that this reference Stamps implementation would= =20 >> classify as containing such stamp-style embedded assets at H_snap. >> >> >> Won=E2=80=99t spammers just make workarounds and spam anyway? >> >> >> The Cat targets the financial incentive to create spam. It is almost=20 >> impossible to stop a determined user from adding data to Bitcoin. The mo= re=20 >> realistic mitigation is to remove the ability to reliably trade these=20 >> embedded assets as if they were durable, on-chain economic objects. Once= =20 >> the existing inscription and stamp economies are neutralized and their= =20 >> dust-sized carrier UTXOs are fenced off, the motivation to spam the chai= n=20 >> in the same way is greatly reduced. >> >> >> Can=E2=80=99t users just spend their NMUs after the snapshot, removing t= hem from=20 >> the list? >> >> >> Yes, a user can attempt to evade The Cat by spending an NMU after the=20 >> snapshot. However, there are tens of millions of such outputs. It would = be=20 >> extremely costly, in aggregate fees, to move them all. If large-scale=20 >> evasion occurs before activation, it is straightforward to take a new=20 >> snapshot, forcing evaders to pay again if they want to continue. This is= =20 >> the nature of the cat-and-mouse game: attempts to pre-empt the snapshot = by=20 >> moving large numbers of NMUs impose substantial costs on those outputs,= =20 >> while the network can respond by choosing an appropriate snapshot height= if=20 >> necessary. >> >> >> What if some of my UTXOs contain =E2=80=9Crare sats=E2=80=9D? Won=E2=80= =99t those get =E2=80=9CCatted=E2=80=9D? >> >> >> In this BIP, =E2=80=9Crare sats=E2=80=9D can be understood as satoshis t= hat Ord and=20 >> similar indexers are treating as non-monetary artifacts. The Cat does no= t=20 >> look at individual sat numbers or =E2=80=9Crarity=E2=80=9D directly; it = only classifies=20 >> whole UTXOs via the is_nmu(u) predicate, using NMUSet_snap and a simple= =20 >> value/height guardrail. >> >> >> A UTXO can only be classified as an NMU if all of the following are true= : >> >> >> >> -=20 >> =20 >> it falls inside the NMU height window, >> =20 >> >> >> -=20 >> =20 >> its value is strictly below VALUE_MAX_NMU (currently 1,000 sats), and >> =20 >> >> >> -=20 >> =20 >> its outpoint appears in NMUSet_snap as identified by Ord/Stamps at=20 >> the snapshot. >> =20 >> >> Anything at or above VALUE_MAX_NMU is always treated as a normal monetar= y=20 >> output, regardless of what Ord says about the sats inside it. >> >> >> In practice, if you once interacted with Ord and those =E2=80=9Crare sat= s=E2=80=9D now=20 >> live inside a normal-sized wallet UTXO (1,000 sats or more), this propos= al=20 >> does not touch that UTXO at all. It remains fully spendable under the=20 >> ordinary rules. The only =E2=80=9Crare sats=E2=80=9D that get Catted are= those deliberately=20 >> parked in tiny dust outputs below the VALUE_MAX_NMU threshold, and that = Ord=20 >> (or Stamps) is already treating as non-monetary artifacts at H_snap. Tho= se=20 >> dust UTXOs are precisely the objects this proposal is targeting to fence= =20 >> off from the monetary UTXO set. >> >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/32f8c689-314d-4a5e-9af6-2e3= e704582e6n%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/= c541315d-a3d1-4416-9bf4-77f1f7d8f12en%40googlegroups.com. ------=_Part_18429_159114535.1765486461944 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, (for response to Claire, list, please scroll down)

>The situation today is entirely different: Techniques to minimize= usage are well understood, widely deployed, and the cost of storing data t= hat way is very high so none happens except by those who are very motivated= and financially capable (and that motivation and means results in speed bu= mps having little effect...

This isn't true. It'= s the classic "survivorship bias" mistake that gets made constantly through= out the general discussion about arbitrary data. You're trying to count roa= d traffic accidents that didn't occur due to the existence of said speed bu= mps which can only be done through indirect analysis for obvious reasons. E= very time this comes up, people can point to things as minimal as a tweet f= rom someone influential with the Bitcoin space saying something to the tune= of "I don't like spam" that results in some scam built on top of Bitcoin t= anking to zero and its ecosystem dying. The easiest example is always Vital= ik explaining his decision to make ETH elsewhere and not on Bitcoin due - i= n part - to spam filters which today you all decided "don't work" despite h= aving demonstrably helped in keeping Bitcoin separate from that dumpster fi= re - https://x.com/VitalikButerin/status/929805462052229120

tldr: It doesn't matter if anti-spam mechanisms are not water-t= ight. You acknowledging that "they have little effect" is an admission of t= he fact that they have *some* effect which is fine - assuming the tradeoffs= are acceptable. I am certainly happy to work within those confines - and i= ndeed have been for this entire discussion. Spam mitigation cannot come at = too great of a detriment to other aspects of Bitcoin and "The Cat" is certa= inly reasonable to consider over the line (though I'm not sure where I stan= d yet - so I appreciate any further discussion on the topic.)
Philosophically UTXO deletion is counter to Bitcoin's ethos, = no one would deny it. Practically speaking however, we all know that's it's= perfectly reasonable to dismiss a large % of the UTXO set as junk (regardl= ess of if The Cat or similar were to activate).

= >>negligible one time reduction in utxo disk space

I would never have considered The Cat if such a large % wasn't gar= bage. But at present, it looks to be somewhere between 40-50% of it - and d= eleting that would not be negligible. For a maximally pruned node that's a = 50% reduction in disk space and when people run vast arrays of nodes in the= cloud (large miners do this for obvious reasons) the savings quickly becom= e non-negligible.

>NFTs are just an imaginary= parallel world that don't depend on the network to validate their activity= , so they don't really care about the network's rules, and as such the netw= ork's rules have pretty limited effect.=C2=A0=C2=A0

<= div>"Stamps" are unspendable anyway by design and thus, we'd just be saving= some disk space for ourselves - true. It would have no effect on what they= 're doing, we're just cleaning up their essentially abandoned trash.
<= div>
For other spam however, they do in fact need their out= puts to remain spendable. Making their "art" unspendable would massively di= srupt that activity. For any serious protocol that wants to trick Bitcoin n= odes into storing useless data (from the perspective of monetary users of B= itcoin) they can always be pushed to asking themselves "why don't we do thi= s on another network that isn't going to delete our ability to spend our 'a= rt'?"

Again, it doesn't matter how dissuasive an= effect this conversation - or even activation of The Cat or any other spam= -mitigation - has. If it has *some* effect then it's just a question of mak= ing sure the tradeoffs are worth it. That is all you can ever hope for in r= educing spam on any protocol.

I don't think it's= at all reasonable to say that making an eight figure amount of NFTs/Inscri= ptions etc unspendable would have more than a "pretty limited effect".

>This is outright theft

No it isn't. It's more akin to "destruction of property". No one acquires= this "stolen property" as it ceases to exist.

&= gt;AI

It really isn't relevant. This is sadly be= coming a trope, to just complain that proposals people don't like are "writ= ten by AI". I did suggest that people should declare to what extent AI was/= wasn't used in an effort to update etiquette to current circumstances. I do= n't find the proposal ridiculous, though also not prepared to fully endorse= it either as I'll go into below.

I replied with= my stance on The Cat below if you're interested.

---

Hi Claire, list,

I don't wish for this to be taken as strong support or advocacy as I genu= inely am not that "Crossing the Rubicon" with UTXO deletion is worth it, th= ough I also find concerns that I have encountered on social media about pre= cedent to be overblown. Mechanisms for UTXO deletion exist within Bitcoin r= egardless of if The Cat were to activate or not. The motivation to employ t= hem does not necessarily extend to government blacklisting simply by virtue= of them having been utilized to delete the UTXOs that this specific propos= al would target.

I think anyone of capable of th= e slightest discernment can tell the difference between what this proposal = dubs "NMUs" versus genuine UTXOs, and that it would succeed in its goal of = making it far more difficult to convince suckers to buy some future Bitcoin= -using-NFT given the network's exercised ability and willingness to throw w= hat they're doing in the garbage.

I have b= een aware of this proposal for a couple of weeks, and it started getting di= scussed on social media prior to here.

Not once = in this time have I had the sinking feeling that if this were to succeed, t= hat it'd call my UTXOs into question as I just do not for a minute believe = people running Bitcoin nodes would ever activate a fork that targeted anyth= ing more than what "The Cat" seeks to eliminate, *or similar*.
Many are aware of my position on spam filtration. Spam filte= rs reject "valid transactions" as is happily pointed out by supposed ideolo= gues who have no understanding of how nodes typically function or indeed ho= w they must continue to operate. I am, for the record, in favour of nodes r= ejecting abusive activity, regardless of their protocol validity and consid= er this trivially moral for those who believe in property rights.

The Cat calls property rights into question by deleting U= TXOs. I don't consider it unreasonable for Bitcoin users to do this if they= see fit as the UTXO set is something that they must contribute resources t= o maintaining in perpetuity, as opposed to simply leaving unmolested and ig= nored. (And interestingly, the "property" the spammers claim to be concerne= d with is the data itself, not the ability to move it, and that's maintaine= d even post "The Cat" save for, though I don't want to misrepresent what th= eir intention is - the only reason they're interested in owning this "art" = is so that they can sell it and The Cat would make them unable to sell it w= ithout having to route around Bitcoin rug-pulling their ability to do so.)<= /div>

Therefore I see no relevant philosophical differ= ence between filtering "valid transactions" and deleting "valid UTXOs" if t= he discernment required in separating egregious abuse of the network from i= ntended usage is minimal - which it certainly is with regard to the current= spam. It's almost all sitting conveniently at the various dust limits with= glaringly obvious footprints, necessarily publicly indexed on websites/exp= lorers with well known software made for the purposes of interacting with t= hose ecosystems that can be recreated for the purposes of slating their ass= ociated UTXOs for deletion.

(Philosophical tidbi= t: both filtration and UTXO-deletion get characterized as 'censorship', whi= ch of course is false in both cases: Bitcoin users are not acting on behalf= of a government and instead simply doing what's in their best interest.)

In practice, and far more importantly, the differ= ence between spam filtration and deleting NMUS is the fact that a bad spam = filter is no big deal. It can be routed around and simply fixed if necessar= y and there's no getting rid of them from nodes anyway.

Mistaken UTXO deletion on the other hand would be disastrous. Recov= ery from that would be a mess to say the least.

= So the snapshot taken by "The Cat" would need to be extremely well vetted w= hich I believe the proposal actually covers extremely well as my natural co= ncern would be a too small a % of the Bitcoin community verifying its conte= nts and thus trusting third parties to have indexed all these junk UTXOs ac= curately. I cannot believe people would be so sloppy in that regard given t= hat their UTXOs could be what end up in that list so hopefully - as the pro= posal itself states - that should become a motivation for a huge number of = people verifying the contents of the list.

So in= summary, my concerns with The Cat are too few independently indexing and a= ttesting to the NMU list which again, the proposal addresses satisfactorily= in my opinion.

I remain unwilling to advocate f= or this proposal any more strongly than I have done here, but would appreci= ate more substantial push back from others who dislike it because as it sta= nds currently, I would not be unhappy if this ended up successfully activat= ing.

Kind regards,
Bitcoin Mechanic









=


On Thursday, December 11, 2025 at 7:30:56=E2= =80=AFAM UTC-8 Greg Maxwell wrote:
You misunderstood my message th= at you've quoted-- understandable because today Bitcoin usage today is = very different than=C2=A0back then.=C2=A0 In September 2013 the average bit= coin blocksize=C2=A0was 120 kbytes and, as a result, there was no meaningfu= l market competition for block space at the time.=C2=A0 As a result there w= as essentially no incentive to minimize data usage in transactions and ther= e was fairly little awareness of the potential means to do so, beyond simpl= e limits like things not relaying.=C2=A0 The situation today is entirely di= fferent: Techniques to minimize usage are well understood, widely deployed,= and the cost of storing data that way is very high so none happens except = by those who are very motivated and financially capable (and that motivatio= n and means results in speed bumps having little effect, -- or even positiv= e effect, as the remaining abuses appear to find bitcoin's costs/restri= ctions highly desirable to create scarcity for their tokens).
On your proposal,

The proposed gain is= some negligible one time reduction in utxo disk space. You motivated it by= claiming this is a 'memory usage' reduction, but it's not-- it= 's just full node storage in particular as the txouts in question are n= ormally sized and largely quiescent=C2=A0already-- so the savings is pretty= insignificant.=C2=A0 Were such a proposal seriously advanced it would like= ly cause a new flood of transactions both to move to evade it directly and = as a result of NFT indexer changes to just "wormhole" the tokens = to new outputs after the fact (and a new marketing opportunity=C2=A0for the= NFT gifters).=C2=A0 NFTs are just an imaginary parallel world that don'= ;t depend on the network to validate their activity, so they don't real= ly care about the network's rules, and as such the network's rules = have pretty limited effect.=C2=A0=C2=A0

And moreov= er the proposal would intentionally and knowingly confiscate millions of do= llars in funds.=C2=A0 This is outright theft, and I believe it makes the id= ea a total non-starter.

As an aside, since the ide= a fails so easily on basic principled grounds it's a disrespectful wast= e of participants time to advance a proposal at such length and technobabbl= y=C2=A0depth which could have been floated with a single sentence "How= would people feel about a proposal to discourage NFTs by identifying a sna= pshot of existing dust-value NFT outputs and making spending them consensus= invalid?"=C2=A0 or similar.=C2=A0 =C2=A0Much of the opposition to LLM= use in the field of BIP discussion has been due to widespread misuse of LL= Ms to create thickets of dense language and obscure non-starter, trivial, o= r ill considered proposals making them much more costly to deal with and di= scouraging serious and thoughtful review of *all* ongoing discussion.
=




On Wed, Dec 10, 2025 at 6:12=E2=80=AFPM Claire Ostrom <ostromcl...@gmail.com> wrote:
=
Dear Bitcoin-dev,

Given r= ecent discussions surrounding the malincentives of spam and the perceived f= utility in addressing these issues, I felt it necessary to propose a workin= g solution. For those interested, I have written a brief history of the pro= blem; please skip to =E2=80=9CThe BIP=E2=80=9D below if you are only intere= sted in the proposal.


Bitcoin is a pe= er to peer open source monetary network created to facilitate online paymen= ts between individuals without trust in a third party. By its nature as an = open protocol, and its censorship-resistant design with no single authority= maintaining its operation, we have to rely on incentives and culture for n= etwork stewardship. Historically, we saw many trends emerge which threatene= d Bitcoin=E2=80=99s primary use as a monetary network. They were successful= ly dealt with by introducing OP_Return with a small limit as a more efficie= nt and limited way of directing non-monetary data to a provably non-spendab= le space that could more easily be pruned from nodes and, importantly, not = pollute the UTXO set.


Legendary Bitco= in developer Gregory Maxwell said at the time, =E2=80=9CPart of the idea= here is shaping behavior towards conservative needs.=E2=80=9D

This was enforced through standardness filter= s, which are a way of discouraging certain types of transactions that, whil= e technically consensus valid, we have agreed as a community are usually no= t used in standard practice and are potentially harmful.


In recent years, these trends have come back into focus= with the creation of schemes like Ordinal theory and its associated inscri= ptions, and Bitcoin Stamps, which are techniques for embedding non-monetary= data (like images or tokens) into Bitcoin transactions. Ordinals typically= hide data in the Taproot witness field (benefiting from a weight =E2=80=9C= discount=E2=80=9D), while Stamps encode data in unspendable outputs (e.g., = fake bare multisig addresses). These practices turn the blockchain into a d= ata storage system rather than purely a payments network. As anyone familia= r with basic economics knows, what you subsidize, you get more of.

Critically, many Ordinal inscription and Stam= p transactions create dust outputs (tiny UTXOs of only a few hundred sats) = that remain unspent indefinitely, bloating the UTXO set. Because Stamp outp= uts are expected to remain unspent indefinitely, they persist in the UTXO s= et forever.


Veteran Bitcoin developer= Mark =E2=80=9CMurch=E2=80=9D Erhardt has described the stamps UTXO issue a= s =E2=80=9Cprobably, from a technical p= erspective, one of the more egregious uses of blockchain."<= /p>
3D"Screenshot

Over roughly 14 years (2009-e= arly 2023), Bitcoin=E2=80=99s UTXO set grew gradually to around 80-90 milli= on entries. Then, in less than a year, it doubled to more than 160 million = by late 2023, a historic anomaly driven largely by the Ordinals and Stamps = craze. Analyses suggest that by mid-2025, over 30% of all UTXOs were tied t= o Ordinal inscriptions. Nearly half of all UTXOs (around 49%) now contain l= ess than 1,000 satoshis, strongly indicating they are spammy dust outputs u= sed for data embedding rather than normal economic activity. Many of these = are Taproot outputs or outputs sitting exactly at the standard dust thresho= ld, consistent with algorithmic spam creation. In short, UTXO spam now acco= unts for tens of millions of entries and represents an unprecedented explos= ion of UTXO bloat.


The UTXO database (chainstate) has ballo= oned alongside this spam. Before 2023, the chainstate was on the order of 4= -5 GB; by early 2024 it exceeded 11 GB, meaning the disk footprint required= to hold the unspent set roughly doubled in about a year, in line with Ordi= nals and BRC-20 mania. Over the same period, the full blockchain grew by ab= out 93 GB in 2023 alone, versus roughly 55 GB per year previously, largely = due to inscription data filling blocks. While pruned nodes can discard old = block data, they cannot discard UTXOs: every unspent output, even spam, mus= t remain in the chainstate until it is spent or explicitly removed by a pro= tocol change. This makes UTXO spam a permanent, compounding burden on full = nodes. As Bitcoin developers have noted, techniques that deliberately embed= data in UTXOs are among the most egregious abuses of the system, precisely= because they clutter the UTXO set with junk that cannot be pruned away und= er current rules.


Bitcoin=E2=80=99s design includes some an= ti-spam measures, but spammers have continually evolved =E2=80=9Ccat-and-mo= use=E2=80=9D tactics to bypass them.


This is where our prop= osal comes in.

THE BIP: The Cat.


Recent = attempts to reduce spam have focused on the supply side, trying to stop spa= m through policy and standardness rules. These efforts have had limited suc= cess. The Cat instead looks to economics, removing or reducing the financia= l incentive for creating spam outputs in the first place. It targets the de= mand side by making designated Non-Monetary UTXOs (NMUs) permanently unspen= dable, which in turn reduces market demand for those assets.


The Cat defines a= fixed, reproducible set of =E2=80=9CNMUs=E2=80=9D using established extern= al indexers, and makes them permanently unspendable by consensus, so that s= uch data cannot be monetized or transacted, only archived. Once rendered un= spendable, we will be removing these UTXOs made unspendable by consensus un= der this proposal, from the UTXO set, materially reducing the current resou= rce requirement for nodes (likely on the order of tens of millions of UTXOs= , roughly ~30% of the set, subject to measurement). The NMU classification = itself is encoded in a compact membership structure (a Binary Fuse Filter p= lus a false-positive exclusion list) that ships with the binary and does no= t require any node to reindex or re-download the chain.



Draft Specifica= tion


Status: Discussion draft. A formal BIP, compliant = with BIP 0003 and the usual BIP process, will be prepared if there is inter= est in pursuing this direction.


1. Definitions


Non-Mone= tary UTXO (NMU):


A UTXO that is classified as containing inscription-style or = stamp-style data according to the procedure in =C2=A72 and that satisfies t= he value and creation-height constraints below.

NMU bit:


A single= Boolean flag (0 or 1) stored alongside each UTXO in the node=E2=80=99s UTX= O database:


  • NMU =3D 1 -> U= TXO is non-monetary and may not be spent.


    <= span style=3D"font-size:11pt;background-color:transparent;font-variant-nume= ric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ve= rtical-align:baseline">NMU =3D 0 -> UTXO is monetary (normal behavior).<= /span>


Conceptually, NMU =3D 1 means =E2=80=9Cthis outpoint is in NMUSet_sn= ap as defined by this BIP.=E2=80=9D Implementations MAY choose to compute t= his bit on the fly from the membership structure rather than store it expli= citly; see =C2=A73.


NMU value threshold:


A consensus constant V= ALUE_MAX_NMU =3D 1000 satoshis. Only UTXOs with value strictly less than VA= LUE_MAX_NMU are eligible to be classified as NMU. UTXOs with value greater = than or equal to VALUE_MAX_NMU MUST be treated as monetary (NMU =3D 0) for = all time under this BIP, even if external tools associate inscriptions or s= tamps with some of their satoshis.


NMU creation-height window= :


T= his proposal intentionally restricts NMU classification to UTXOs created be= tween:


H_min_NMU: the earliest block height at which the reference indexers (O= rd 0.24.0 and the specified Stamps version) first recognize any inscription= -style or stamp-style NMU, and


H_snap: the snapshot height defined in =C2=A72.= 4.


= Both H_min_NMU and H_snap are consensus constants fixed before activation. = Any UTXO created at height < H_min_NMU or > H_snap MUST be treated as= monetary (NMU =3D 0) regardless of filter results.


NMU member= ship structure (NMU_DATA):


= A static, exact membership structure that encodes N= MUSet_snap using:


  • A Binary Fu= se Filter (BFF-8) constructed from all eligible NMU outpoints; and


  • A false positive exclusion = list (FP_EXCLUDE) that contains all non-NMU outpoints at H_snap that would = otherwise match the filter.


NMU_DATA is distributed as a single bina= ry blob, together with a consensus constant NMU_DATA_HASH =3D SHA256d(NMU_D= ATA) which all compliant implementations MUST verify before using it for co= nsensus validation (see =C2=A73.3).


Activation height (H_cat):=


A = consensus constant H_cat, the block height at which the NMU spending rule i= n =C2=A74 first becomes eligible for enforcement. The exact value and deplo= yment mechanism for H_cat are out of scope for this draft and would be spec= ified in a formal BIP.


2. NMU classification (reproducible list)


The no= rmative consensus object introduced by this BIP is the set NMUSet_snap: a f= ixed set of outpoints classified as non-monetary at snapshot height H_snap = on the best chain, after applying the value and height restrictions in =C2= =A71 and =C2=A72.3.


Consensus enforcement of The Cat only depends on whether= an outpoint is in NMUSet_snap or not; it does not depend on how any partic= ular node obtained that set.


To define NMUSet_snap in a precise and reproducib= le way, this BIP specifies two reference classification rule sets that oper= ate purely on Bitcoin chain data, as implemented in:


    Ord 0.24.0 at commit 5d2fbbe64b362cd6c30d6901e50c= be80084761f8


  • Stamps= - [exact version/commit to be pinned before any activation]


These r= eference implementations define the inscription-style and stamp-style class= ification rules in terms of Bitcoin chain data. They are cited here as norm= ative descriptions of how to decide whether a given outpoint carries an ins= cription or a stamp at height H_snap.


Implementations that wish to independent= ly derive or verify NMUSet_snap MAY:


  • Execute these reference implementations from genesis up to H_snap, = or


  • Independently re= -implement the same classification rules and confirm that the resulting set= of outpoints matches the NMU set implied by NMU_DATA.

=


Running Ord o= r Stamps is not required for ordinary full-node operation under this BIP; t= hey are simply the canonical specification of the classification logic.


This s= ection uses the consensus constants H_cat, H_snap, and H_min_NMU as defined= in =C2=A71.


2.1 Ord NMU set


=

According to the classification rule= s implemented in Ord 0.24.0 at commit 5d2fbbe64b362cd6c30d6901e50cbe8008476= 1f8, witness data is parsed for =E2=80=9Cinscription envelopes=E2=80=9D and= each recognized inscription is associated with a particular outpoint (txid= , vout) on the best chain at height H_snap.


<= /p>

Define OrdNMUSet as the set of al= l outpoints that, when those Ord 0.24.0 rules are applied to the best chain= up to H_snap, are classified as carrying inscriptions at H_snap. Concretel= y, for each inscription that Ord 0.24.0 would associate with a specific out= point (txid, vout) on that chain, that outpoint is included in OrdNMUSet.


This= includes, for example, inscription UTXOs used by protocols such as BRC-20,= but the BIP makes no protocol-level distinction; they are all treated as = =E2=80=9CNMU=E2=80=9D if they meet the value and height thresholds in =C2= =A72.3.


An implementation may obtain OrdNMUSet by actually running Ord 0.24.0,= or by re-implementing its published classification rules and applying them= to the chain.


2.2 Stamps NMU set

According to the classificatio= n rules implemented in the specified BTC Stamps indexer (version/commit TBD= ), Counterparty metadata and Bitcoin transactions are parsed to identify = =E2=80=9Cstamp-style=E2=80=9D embedded assets and associate them with one o= r more bare multisig outputs on the best chain at height H_snap.

=


Define Stamps= NMUSet as the set of all outpoints that, when those Stamps rules are applie= d to the best chain up to H_snap, are classified as containing a stamp at H= _snap. For each stamp that the reference Stamps implementation would associ= ate with a specific outpoint (txid, vout) on that chain, that outpoint is i= ncluded in StampsNMUSet.


As with Ord, an implementation may obtain StampsNMUSe= t either by running the reference Stamps indexer or by independently implem= enting the same classification rules and applying them to the chain.=


2.3 Combined NMU set + value & height thresholds


The initial raw NM= U set at snapshot height is:


NMUSet_raw =3D OrdNMUSet =E2=88= =AA StampsNMUSet


Apply both the NMU value threshold and the creation-height wi= ndow:


NMUSet_snap =3D { u =E2=88=88 NMUSet_raw | value(u) <= ; VALUE_MAX_NMU and H_min_NMU =E2=89=A4 height(u) =E2=89=A4 H_snap }=


where val= ue(u) is the number of satoshis in UTXO u, and height(u) is the height of t= he block that created that UTXO.


Every UTXO in NMUSet_snap MUST be treated as = having NMU =3D 1 under the new consensus rule (see =C2=A74). Nodes MAY real= ize this either by pre-seeding an NMU bit in their UTXO database or by comp= uting it dynamically via the membership query in =C2=A73.3.


Notes:

<= p dir=3D"ltr" style=3D"font-size:11pt;line-height:1.38;margin-top:0pt;margi= n-bottom:0pt">

Running Ord or= Stamps is only required for those who wish to independently derive and ver= ify NMUSet_snap; it is not a requirement for ordinary full node operation u= nder The Cat.


The value threshold is intended to avoid classifying large, mi= xed-use UTXOs as NMUs when a small number of inscribed satoshis have been c= ombined with otherwise monetary funds.


Restricting to height(u) =E2=89=A5 H_mi= n_NMU reflects the historical fact that these protocols appeared only after= a certain point, and it trivially avoids misclassification of very old UTX= Os.


This proposal intentionally does not specify any new in-client classificat= ion rule for discovering future NMU formats. It explicitly targets non-mone= tary UTXOs identifiable via Ord 0.24.0 and Stamps at the time of snapshot.<= /span>


2.4 Snapshot block commitment and reorg behaviour


This BIP commit= s to a specific chain history at the snapshot height H_snap by introducing = a new consensus constant:


<= span style=3D"font-size:11pt;background-color:transparent;font-variant-nume= ric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ve= rtical-align:baseline">SNAP_BLOCK_HASH: a 32-byte value equal to the block = hash at height H_snap on the chain from which NMUSet_snap was originally de= rived.


A node MUST only enforce the NMU consensus rule from =C2=A74 if, for it= s current best chain:


There exists a block at height H_snap, and


The hash of that= block is exactly equal to SNAP_BLOCK_HASH.


<= /p>

If, for the node=E2=80=99s curren= t best chain, the block at height H_snap has a different hash, the node MUS= T treat all UTXOs as monetary (NMU =3D 0) for the purposes of consensus val= idation, and MUST NOT reject any transaction or block on the basis of the N= MU rule.


In particular, if a reorganization occurs that replaces the block at = height H_snap with a different block (i.e., a reorg deeper than H_snap), en= forcement of The Cat is automatically disabled until and unless the best ch= ain once again has SNAP_BLOCK_HASH at height H_snap. Any desire to apply NM= U classification to a different chain history would require a new consensus= commitment (for example, a new SNAP_BLOCK_HASH defined by a subsequent BIP= and activation process).


3. NMU bit storage, membership structure, and act= ivation


3.1 NMU bit storage model


Consensus only cares ab= out which UTXOs are NMU, not how the bit is stored or computed. Implementat= ions MAY:


  • Store the NMU bit a= s an extra bit in the UTXO database (e.g., in the Coin structure).


  • Store NMUs in a separate st= ructure keyed by outpoint.


  • Compute NMU on the fly at validation time using the NMU_DATA member= ship structure from =C2=A73.3, optionally caching results.

    • <= /ul>


    The only = consensus requirement is: given the same chain, compliant implementations m= ust converge on the same NMU classification for all UTXOs. Conceptually, fo= r a UTXO u with value(u) and height(u), NMU(u) is defined as:


    • 1 if:

    <= br>

    • H_min_NMU =E2=89=A4 height(u) =E2=89= =A4 H_snap, and


    • value(u) < VALUE_MAX_NMU, and


    • u =E2=88=88 NMUSet_snap (as = tested via =C2=A73.3),


    • 0 otherwise.


    3.2 Activation


    At activation height H= _cat:


    Nodes must have:


    • Fully val= idated the chain up to at least H_snap.

    =

    • Loaded and verified NMU_DATA (see =C2=A73.3).


    F= rom the first block at or after H_cat for which the snapshot block commitme= nt condition in =C2=A72.4 holds, nodes MUST enforce the consensus rule in = =C2=A74, using the NMU classification defined above. No reindex or UTXO rew= rite is required for activation; NMU classification can be applied as an ov= erlay on top of the existing UTXO database.


    <= /p>

    Implementations MAY, as an optimi= zation, perform a one-time pass over their UTXO set after activation to:


    • Set Coin.NMU =3D 1 for all UTXO= s that satisfy the NMU predicate; and/or


    • Physically delete such UTXOs from the UTXO database (= see =C2=A75).


    Such a pass is a local optimization and not required f= or consensus, provided the on-the-fly NMU classification via NMU_DATA would= yield the same results.


    3.3 NMU membership structure: Binary = Fuse Filter + exclusion list


    This BIP does not require nodes to redo initial b= lock download or reindex the chain in order to enforce NMU classification. = Instead, it commits to a canonical membership structure NMU_DATA which enco= des NMUSet_snap in a compact form.


    3.3.1 Canonical outpoint e= ncoding


    For all purposes related to NMU_DATA (filter construction, querying, a= nd the exclusion list), an outpoint (txid, vout) is encoded as a fixed 36-b= yte key.


    txid_le (bytes 0=E2=80=9331): the 32-byte transaction ID in little-en= dian order, matching the internal uint256 representation used by Bitcoin Co= re and similar implementations.

    vout_le (bytes 32=E2=80=9335): the 4-byte output index, serialized as= a little-endian unsigned 32-bit integer (e.g. 0 -> 00 00 00 00, 1 ->= 01 00 00 00, 256 -> 00 01 00 00).


    This encoding is normative for NMU_DATA.= All compliant implementations MUST use exactly this encoding when querying= the filter or the exclusion list.


    3.3.2 NMU_DATA serializati= on


    = NMU_DATA is a single binary blob. All integer fields are little-endian and = appear in the following order:


    • MAGIC (4 bytes): ASCII string "NMU1".

    • VERSION (1 byte): format version (initially 0x01).

    • SNAP_HEIGHT (4 bytes): block height H_s= nap.

    • =

      SNAP_HASH (32 bytes): block h= ash at H_snap (must match SNAP_BLOCK_HASH from section =C2=A72.4).

    • FILTER_SEED (8 bytes): 64-bit seed used by= the Binary Fuse Filter hash functions.

    • FILTER_LEN (4 bytes): length in bytes of FILTER_DATA.

      • =

    • FILTER_DATA (FILTER_LEN bytes): raw Binary Fuse F= ilter data.

    • FP_COUNT (4 bytes): nu= mber of false-positive entries.

    • FP= _ENTRIES (FP_COUNT =C3=97 36 bytes): lexicographically sorted array of cano= nical 36-byte outpoint encodings that are not in NMUSet_snap but would othe= rwise match the filter.

    • CHECKSUM (= 32 bytes): SHA256d of all preceding bytes from MAGIC through the last FP_EN= TRY.


    The SHA256d of the entire NMU_DATA blob is called NMU_DATA_HAS= H and is treated as a consensus constant compiled into node software.


    A node M= UST NOT enforce the NMU consensus rule unless NMU_DATA passes its internal = CHECKSUM validation and SHA256d(NMU_DATA) equals NMU_DATA_HASH.

    <= p dir=3D"ltr" style=3D"font-size:11pt;line-height:1.38;margin-top:0pt;margi= n-bottom:0pt">

    3.3.3 Binary Fuse Filter query


    The filter is a static Binary Fuse Filter ove= r 36-byte keys with 8-bit fingerprints, giving an approximate false-positiv= e rate of about 1/256.


    For a given key, a deterministic hash function derived = from FILTER_SEED maps the 36-byte key to three byte positions inside FILTER= _DATA and to an 8-bit fingerprint. A membership query reads the three bytes= at those positions, XORs them, and compares the result to the fingerprint.= If they match, the filter reports the key as =E2=80=9Cprobably present=E2= =80=9D.


    The exact mapping from a 36-byte key to three positions and an 8-bit f= ingerprint, and the interpretation of FILTER_DATA, MUST follow a single, fu= lly specified algorithm (for example, a pinned =E2=80=9Cbinary fuse filter= =E2=80=9D reference implementation). How FILTER_DATA was constructed is not= consensus-critical; only the query algorithm and the fixed contents of NMU= _DATA are consensus-critical.


    3.3.4 False positive exclusion l= ist


    Because the Binary Fuse Filter is probabilistic, some UTXOs that are not i= n NMUSet_snap will still be reported as present at H_snap. During snapshot = construction, the false positive exclusion list FP_EXCLUDE is computed by e= numerating all UTXOs at H_snap that are not in NMUSet_snap, testing each wi= th the filter, collecting those that match, and sorting their 36-byte keys = lexicographically to form FP_ENTRIES.


    At runtime, FP_EXCLUDE is treated as an = override: if an outpoint=E2=80=99s canonical key appears in FP_EXCLUDE, tha= t outpoint MUST be treated as non-NMU, regardless of the filter result.


    3.3.5 Membership query (is_nmu)


    =

    Given a UTXO u at outpoint (txid, vo= ut), with value(u) and height(u), nodes evaluate the NMU membership predica= te is_nmu(u) as follows.


    First, UTXOs outside the NMU window are never NMUs. I= f height(u) is less than H_min_NMU or greater than H_snap, is_nmu(u) is fal= se.


    Second, very large UTXOs are always treated as monetary. If value(u) is gr= eater than or equal to VALUE_MAX_NMU, is_nmu(u) is false.


    For the remaining U= TXOs, the node computes key =3D canonical_encode(txid, vout) using the 36-b= yte encoding defined in section 3.3.1. If key appears in FP_EXCLUDE (using = binary search over the sorted FP_ENTRIES array), is_nmu(u) is false. Otherw= ise, the node queries the Binary Fuse Filter with key. If and only if the f= ilter reports the key as present, is_nmu(u) is true.


    Within the domain H_min_N= MU =E2=89=A4 height(u) =E2=89=A4 H_snap and value(u) < VALUE_MAX_NMU, th= is predicate exactly matches membership in NMUSet_snap: every UTXO in NMUSe= t_snap is reported as NMU, and every UTXO outside NMUSet_snap is reported a= s non-NMU, with no false positives and no false negatives.


    4. New consensus= rule


    The rule in this section is enforced only when the snapshot block= commitment condition from =C2=A72.4 holds and NMU_DATA has been successful= ly verified.


    From the first block at or after H_cat that follows activation:


    Rule: Forbidden spending of NMUs


    <= /p>

    A transaction is invalid if any o= f its inputs refers to an outpoint (txid, vout) such that the corresponding= UTXO u satisfies is_nmu(u) =3D true as defined in =C2=A73.3.5 (equivalentl= y, has NMU =3D 1).


    Formally, when validating a transaction input:


    • Let (txid, vout) be the input outpoint.


    • Let u =3D Coin(txid,= vout) be the referenced UTXO as seen by the node at the time of validation= .


    • If u does not exi= st: reject as usual (unchanged behavior).


      <= span style=3D"font-size:11pt;background-color:transparent;font-variant-nume= ric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ve= rtical-align:baseline">Otherwise, if is_nmu(u) =3D true, then the transacti= on MUST be rejected as invalid.


    =

    This rule applies:


    • To mempool acceptance.


    • To block validation.

    =


    • To all future reorg scenarios, provided= the snapshot commitment in =C2=A72.4 remains satisfied.


      • 5. UTXO = set removal and pruning


      Because NMUs are permanently unspendable after = activation, they can be dropped from the spendable UTXO set.


      5= .1 Logical removal


      Implementations MUST treat UTXOs with is_nmu(u) =3D true (o= r NMU =3D 1) as non-existent for the purpose of:

      <= br>

      • Satisfying transaction inputs (they can never be used).=


      • Fee calculations, = coin selection, wallet balances, etc.

      5.2 Physical p= runing (optional)


      Nodes that operate with -prune=3D1 (or similar backwards-com= patible pruning configuration) MAY:


      • Omit NMUs from the on-disk UTXO set.


        <= li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;background-colo= r:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;fo= nt-variant-alternates:normal;vertical-align:baseline">

        Remove any previously persisted NMUs during a com= paction / cleanup pass by running is_nmu(u) on each UTXO and deleting those= that return true.


      This proposal does not require pruned nodes to di= scard raw historical blocks. It only authorizes pruning of UTXO entries tha= t are permanently unspendable due to the NMU rule.


      Non-pruned nodes (full arch= ival nodes) MAY continue to store historical blocks and full transaction da= ta as usual. This preserves archival access to inscription / stamp data whi= le still neutralizing it economically.


      Rationale


      This BIP makes minimal= changes to the consensus surface. It adds no new opcodes and does not expa= nd Bitcoin=E2=80=99s scripting language or programmability. Instead, it int= roduces a single new consensus concept: a binary classification that marks = some existing UTXOs as permanently unspendable Non-Monetary UTXOs (NMUs). I= n that sense, it is closer to a one-time reclassification of a subset of UT= XOs than an ongoing change to Bitcoin=E2=80=99s programming model.


      External= indexers, determinism, and reproducibility


      Instead of re-implementing = complex inscription and stamp classification rules in Bitcoin clients, this= BIP relies on mature tools that are already used by the non-monetary data = community, specifically Ord and Stamps. Exact versions of these indexers ar= e specified and pinned by commit so that their behavior is deterministic. T= he NMU set is defined in terms of chain data as seen through these specifie= d indexers, rather than as an arbitrary hard-coded list of UTXOs. This keep= s the consensus rule grounded in chain-derived information while avoiding t= he need to embed inscription logic directly in Bitcoin client software.


      Fix= ed snapshot vs future formats


      By scoping the NMU classification to what= Ord 0.24.0 and Stamps (at a pinned commit) can see at the snapshot height = H_snap, this proposal neutralizes the existing inscription and stamp econom= y on day one without importing evolving, open-ended classification rules in= to consensus. It treats the snapshot as a fixed historical boundary and lea= ves future NMU formats and mitigation strategies as a separate question for= policy or for future BIPs. If further action is desired on post-snapshot N= MU formats, the community can consider additional updates or separate propo= sals without expanding the scope of this one.


      =

      UTXO set size and overhead


      Because all NMUs become permanently unspendable under this proposal, they= can be removed from the UTXO set, which reduces its size. The new storage = overhead introduced by The Cat is dominated by the global membership struct= ure NMU_DATA, which consists of a Binary Fuse Filter over NMUSet_snap plus = a correction list of false positives. For a plausible NMU count on the orde= r of 50 million, the filter occupies roughly 9 bits per element (=E2=89=88 = 56 MB), and the exclusion list adds around 15=E2=80=9320 MB before compress= ion, for an uncompressed size on the order of 70=E2=80=9380 MB and an expec= ted compressed size of roughly 40=E2=80=9350 MB.

      <= br>

      This is small relative to typ= ical UTXO set sizes and to the on-disk savings from pruning tens of million= s of dust-sized NMUs. Per-UTXO storage overhead remains a single NMU bit if= implementations choose to materialize it in the database; the rest of the = classification data is stored once per node.


      <= /p>

      Censorship resistance and scop= e


      Bitcoin=E2=80=99s censorship resistance is primarily concerned with t= he ability to move monetary value without trusted intermediaries. This prop= osal intentionally targets non-monetary uses of the chain (inscriptions, st= amps, and similar schemes) and leaves ordinary monetary transfers untouched= . Reasonable people may still describe permanently disabling some UTXOs as = a form of censorship; the distinction this BIP draws is between money and a= rbitrary data storage.


      The same type of mechanism could in principle be abused= to target arbitrary UTXOs, which is why this proposal deliberately scopes = itself to a one-time, transparently derived set of dust-sized non-monetary = outputs. Any attempt to apply similar techniques to ordinary monetary UTXOs= would be highly contentious and would require explicit social consensus fr= om users, miners, and economic nodes. In other words, this mechanism does n= ot lower the technical or social barriers to censoring ordinary monetary ac= tivity; any such censorship would still require its own explicit, contentio= us change in consensus rules.


      The classification rules on which The Cat relies= are deliberately narrow and mechanical. An output is marked as an NMU only= if it is (a) identified by the pinned Ord/Stamps rules as carrying a non-m= onetary artifact at H_snap, (b) dust-sized, below the VALUE_MAX_NMU thresho= ld, and (c) within the defined height window. The intent is that no ordinar= y monetary UTXOs fall into NMUSet_snap; any such inclusion would be treated= as an error in the snapshot construction and grounds to regenerate NMU_DAT= A before activation, not as an acceptable trade-off. The 1,000-sat value li= mit serves as an additional hard guardrail against accidentally classifying= normally-sized wallet outputs.


      Centralization and trust model for NMU gene= ration


      Anyone can independently generate the list of NMUs. It is incu= mbent on people to do so if they wish to minimize the trust required to run= a fully validating node. The criteria for which outputs are designated as = NMUs are necessarily known and established by virtue of how prevalent and o= pen the targeted data protocols are.


      It is valid to worry that fewer than 100%= of node runners will regenerate the NMU list themselves, somewhat increasi= ng the overall trust placed in third parties compared to today. However, th= is concern applies specifically to a =E2=80=9Cblacklist of UTXOs,=E2=80=9D = which is precisely the area where scrutiny is highest. That scrutiny should= help ensure that enough independent parties index and attest to the conten= ts of NMUSet_snap to exceed any reasonable threshold of credulity.


      A useful an= alogy is the GUIX-based reproducible build process. Bitcoiners accept that = many users will only run node binaries they download, rather than compiling= from source and independently verifying the code. Compiled binaries must e= xist for Bitcoin to maintain decentralization in practice. This is an aspec= t of trust inherent in Bitcoin: we accept some technical limitations of use= rs and employ a practical, trust-minimized workaround that, while not perfe= ct, is better than the alternative.


      If there were to be an issue with widely u= sed binaries, it would become ubiquitously known very quickly. Similarly, i= f The Cat were flawed and began targeting monetary UTXOs, this would be det= ected well before activation, and the necessary fixes applied, with any dis= tortion of its motivation exposed and corrected.

      <= br>

      Backward compatibility


      This proposal is a consensus-changing soft fork. Legacy nodes that do not = implement The Cat will continue to accept blocks that spend NMUs as valid, = while nodes that do implement The Cat will reject such blocks as invalid. A= s with any soft fork, activation requires clear opt-in from miners and from= economic nodes. After activation, miners and other block proposers must av= oid including transactions that spend NMUs, because such blocks will be rej= ected by upgraded nodes. Wallets and applications that track inscriptions, = BRC-20 assets, and related schemes will observe that NMUs become permanentl= y unspendable under The Cat and that balances associated with those UTXOs a= re no longer movable under the activated ruleset.

      =

      FAQ


      Do node operat= ors need to run Ord or Stamps?


      No. The Cat does not require ordinary no= de operators to run Ord or Stamps, or to understand their rules in detail. = Those indexers are cited as normative references for the inscription and st= amp classification logic used to derive NMUSet_snap. In practice, nodes onl= y need the canonical NMU_DATA blob and its hash NMU_DATA_HASH to enforce th= e consensus rule.


      Anyone who wishes to independently verify NMUSet_snap can:


      insp= ect the open-source Ord and Stamps code,


      <= p dir=3D"ltr" style=3D"font-size:11pt;line-height:1.38;margin-top:0pt;margi= n-bottom:0pt">or re-implement equivalent classifica= tion rules,


      and confirm that the derived set of NMU outpoints matches the set = encoded in NMU_DATA (i.e., the blob whose hash is NMU_DATA_HASH).


      What rule= s do the reference indexers actually use to decide which UTXOs are NMUs?


      This BIP does not re-specify the full Ord and Stamps protocols, but in br= oad terms:


      Ord 0.24.0 (inscriptions).

      According to the classification rules implemented in Ord 0.24.0 at= commit 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is scanned f= or =E2=80=9Cinscription envelopes=E2=80=9D in Taproot script paths. An insc= ription envelope is an OP_FALSE OP_IF =E2=80=A6 OP_ENDIF block containing d= ata pushes that start with the ASCII tag ord and encode a content type and = body. When those rules are applied to the best chain up to height H_snap, e= ach recognized inscription is associated with a particular outpoint (txid, = vout) (typically the first satoshi of a reveal transaction input, or as dir= ected by the pointer field in the protocol). OrdNMUSet is defined as the se= t of outpoints that Ord 0.24.0 would classify as carrying inscriptions at H= _snap under these rules.


      Stamps (BTC Stamps).

      According to the classification rules implemented in the= pinned BTC Stamps indexer, Counterparty transactions are inspected for a S= TAMP:-prefixed base64 string in the description field, which encodes image = data. The Stamps rules then map this metadata to specific dust-sized bare m= ultisig outputs in the underlying Bitcoin transactions. When those rules ar= e applied to the best chain up to height H_snap, each recognized stamp is a= ssociated with one or more outpoints (txid, vout). StampsNMUSet is defined = as the set of outpoints that this reference Stamps implementation would cla= ssify as containing such stamp-style embedded assets at H_snap.

      <= p dir=3D"ltr" style=3D"font-size:11pt;line-height:1.38;margin-top:0pt;margi= n-bottom:0pt">

      Won=E2=80= =99t spammers just make workarounds and spam anyway?


      The Cat targets th= e financial incentive to create spam. It is almost impossible to stop a det= ermined user from adding data to Bitcoin. The more realistic mitigation is = to remove the ability to reliably trade these embedded assets as if they we= re durable, on-chain economic objects. Once the existing inscription and st= amp economies are neutralized and their dust-sized carrier UTXOs are fenced= off, the motivation to spam the chain in the same way is greatly reduced.<= /span>


      = Can=E2=80=99t users just spend their NMUs after the snapshot, removing them= from the list?


      Yes, a user can attempt to evade The Cat by spending an= NMU after the snapshot. However, there are tens of millions of such output= s. It would be extremely costly, in aggregate fees, to move them all. If la= rge-scale evasion occurs before activation, it is straightforward to take a= new snapshot, forcing evaders to pay again if they want to continue. This = is the nature of the cat-and-mouse game: attempts to pre-empt the snapshot = by moving large numbers of NMUs impose substantial costs on those outputs, = while the network can respond by choosing an appropriate snapshot height if= necessary.


      What if some of my UTXOs contain =E2=80=9Crare sats=E2=80=9D? W= on=E2=80=99t those get =E2=80=9CCatted=E2=80=9D?


      In this BIP, =E2=80=9C= rare sats=E2=80=9D can be understood as satoshis that Ord and similar index= ers are treating as non-monetary artifacts. The Cat does not look at indivi= dual sat numbers or =E2=80=9Crarity=E2=80=9D directly; it only classifies w= hole UTXOs via the is_nmu(u) predicate, using NMUSet_snap and a simple valu= e/height guardrail.


      A UTXO can only be classified as an NMU if all of the fo= llowing are true:


      • it falls in= side the NMU height window,


      • its value is strictly below VALUE_MAX_NMU (currently 1,000 sats), = and


      • its outpoint ap= pears in NMUSet_snap as identified by Ord/Stamps at the snapshot.


      An= ything at or above VALUE_MAX_NMU is always treated as a normal monetary out= put, regardless of what Ord says about the sats inside it.


      In practice, if you= once interacted with Ord and those =E2=80=9Crare sats=E2=80=9D now live in= side a normal-sized wallet UTXO (1,000 sats or more), this proposal does no= t touch that UTXO at all. It remains fully spendable under the ordinary rul= es. The only =E2=80=9Crare sats=E2=80=9D that get Catted are those delibera= tely parked in tiny dust outputs below the VALUE_MAX_NMU threshold, and tha= t Ord (or Stamps) is already treating as non-monetary artifacts at H_snap. = Those dust UTXOs are precisely the objects this proposal is targeting to fe= nce off from the monetary UTXO set.


--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/32f8c689-314d-4a5e-9af6-2e3e704582e= 6n%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/c541315d-a3d1-4416-9bf4-77f1f7d8f12en%40googlegroups.com.
------=_Part_18429_159114535.1765486461944-- ------=_Part_18428_2109494127.1765486461944--