From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Dec 2025 02:05:41 -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-0005qo-6C for bitcoindev@gnusha.org; Sat, 13 Dec 2025 02:05:41 -0800 Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-4efef582d65sf49777321cf.3 for ; Sat, 13 Dec 2025 02:05:37 -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=HJisMuVgLuX5wUoLS+GVqSt2FTmPhu5eg9/xEJ1OKi8=; b=ADqP7yea10elJnJZ5YD+dON0gHeCnFtoZto1qYR6tECAsUtKZFiq2wdPOKqcPREKVl zC5Q+77PCoo+zrrF01xBIWXMx9oIYr41MKOSuDij9WbFrF3hNqbWT0ru1WBGrBgDWUo9 JW9JVKVwQekOGMCO15lB+VE3veAeKBN6k2YVCmxaG23oJ98Mi0V0b9/TTtlxv8BU9YD+ Qn14dNRSTZSwZlQ0R22DxMvIkLFDbWrTLBN7W4ECj/XK+jirtXTrU8+qrgt3WhTM4Zix iEqaeB2BykGT0/mRN9PG6Kv4wzIoEsu6a0XKpWxdzNvc2G3vCbleXaYrQU6Qip9a/7jk 8Xhg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=HJisMuVgLuX5wUoLS+GVqSt2FTmPhu5eg9/xEJ1OKi8=; b=Y9/qRASky9SknMn2lo3Vkd5MBNyNozXBNxft2quAoHLL5vTxc3696DMp17IousOQg/ fTzuhCXRDSehcaUpI27pdBHBf6dPZVMzJ4zWNcUnddoITzgFgX4Q+SyH5Wme8fSiubrF Xh6D9QwPxDuuOXOQ1cfZ4K/40/OOW1JXYJVKeiyYuUA9fCeq+ixVOw1B2WOw2acviZ+l ijxEChvXyiSsOrE8KSmQiZFdLw/ZXkyZBX4MWbv+iwLMG/yv7u27Q+nKxxoUzds+mK46 +M/ZVQLHjsthjS06OTChMQH02HClKGvwe+RoOptYXWSGn7/gdQBVs5LYUBtmWM+YzXpp tZDg== 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=HJisMuVgLuX5wUoLS+GVqSt2FTmPhu5eg9/xEJ1OKi8=; b=T/NDI0QjC+n9xoTogyQj+VtwDoWWlRMG3ioGBgaJEvL4hseleWG67VS4/0jGQtPcdm gA/3yz9DNTuj/mK72Nql+gXRW3y6niOEB+Dp1wa4mcMWzZgiYxwVmklVvtJHD8oJ6a+9 Za1QY9WCHZqDNpJPnnIhxsfNwtqNwm7XnAwZqUzcaaTi9c4KZOnrNtzXOWr51O9LFAet aPLyVzjv018rnyYC4910XOizP58DbxzMzwKQzJsGY0EJ2RLvo+TxHDU4KOsZ1vhzJ52Y zPy9yUljf1iBLbi40aWDV1sD6P4G9H6UEe1MlDBtmubv3NyH8208mmri98kOc3ygaGK6 QH9A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCV37HvGWBUrLTeuRiPfLYgrCyAdYvGabEljRZUweMOzP3QRgwCrWTBb9nQ6KNtiDlgNK1K2T52evGOd@gnusha.org X-Gm-Message-State: AOJu0YyWkrf9h1uCZxk1twj3btap7RaQRW6p7CkBidD19WoPEIiISMJP rbSsWsISmhMBg9cTUGSm9Cy6oDjlefB//VWE6e8n1xImbssSnjfCVthG X-Google-Smtp-Source: AGHT+IH5/j1rUG3CHgNvPTApRqty6wiPpw9ch+gYx6rt53pEZaNyvbgfZQ4sEdkOUM4T61zvwvNzKA== X-Received: by 2002:ac8:7fc1:0:b0:4f0:2777:55c2 with SMTP id d75a77b69052e-4f1d0479ec0mr62464691cf.10.1765620330669; Sat, 13 Dec 2025 02:05:30 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZc0fn+xveS3UOFqKU6b2UjkInzzAlt+p5M++EnS6+BTQ==" Received: by 2002:a05:622a:101:b0:4ed:adb8:fab9 with SMTP id d75a77b69052e-4f1ced6d9e2ls20342241cf.1.-pod-prod-05-us; Sat, 13 Dec 2025 02:05:24 -0800 (PST) X-Received: by 2002:a05:620a:20d5:b0:8a3:fa43:321b with SMTP id af79cd13be357-8bb39dc4872mr540090885a.27.1765620324157; Sat, 13 Dec 2025 02:05:24 -0800 (PST) Received: by 2002:a05:690c:950d:b0:786:8d90:70d8 with SMTP id 00721157ae682-78e64591f1ems7b3; Thu, 11 Dec 2025 17:49:13 -0800 (PST) X-Received: by 2002:a05:690c:6ac5:b0:788:1b67:d741 with SMTP id 00721157ae682-78e6694fc59mr5882607b3.3.1765504152635; Thu, 11 Dec 2025 17:49:12 -0800 (PST) Date: Thu, 11 Dec 2025 17:49:11 -0800 (PST) From: TwoLargePizzas To: Bitcoin Development Mailing List Message-Id: <2ebbf019-a562-427d-93af-b88f0cf5658an@googlegroups.com> 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_33594_2097925772.1765504151838" X-Original-Sender: zarfius@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_33594_2097925772.1765504151838 Content-Type: multipart/alternative; boundary="----=_Part_33595_331766997.1765504151838" ------=_Part_33595_331766997.1765504151838 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > The proposed gain is some negligible one time reduction in utxo disk=20 space. Is it though? My understanding is that this proposal would disincentivize= =20 this kind of use of the UTXO set which would significantly reduce these=20 types of transactions going forward. That's not a one time reduction and=20 it's certainly not negligible. > Were such a proposal seriously advanced it would likely cause a new=20 flood of transactions both to move to evade it directly Maybe, but that's speculation at best. One could also speculate that even= =20 the existence of this BIP proposal would likely cause those types of=20 transactions to move elsewhere. If the "marketing opportunity" for the NFT= =20 grifters is to say the transactions could be worthless going forward, then= =20 yes, I agree. > NFTs are just an imaginary parallel world that don't depend on the=20 network to validate their activity, so they don't really care about the=20 network's rules, and as such the network's rules have pretty limited=20 effect. =20 If the rules don't matter, they won't be bothered if the rules change.=20 > the proposal would intentionally and knowingly confiscate millions of=20 dollars in funds. This is outright theft, and I believe it makes the idea= =20 a total non-starter. When you say "millions of dollars in funds" are you including the value of= =20 the NFTs tied to those sats or the just the total sum of all the=20 unspendable dust? It would seem a little contradictory to call NFTs an=20 imaginary in one breath and worth millions of dollars in the next. To be=20 clear, I'm not advocating for confiscation, just trying to understand=20 exactly where the millions of dollars in funds comes from. To me this proposal is more about sending a message that UTXO bloat is not= =20 welcome. I don't agree with direct confiscation of funds but at the same=20 time I hold the position that encouraging the NFT grifters is only going to= =20 lead to more NFT gifters. On Friday, 12 December 2025 at 1:30:56=E2=80=AFam UTC+10 Greg Maxwell wrote= : > 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/= 2ebbf019-a562-427d-93af-b88f0cf5658an%40googlegroups.com. ------=_Part_33595_331766997.1765504151838 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0 The proposed gain is some negligible one time reduction in utxo disk space.=

Is it though? My understanding is that this proposal = would disincentivize this kind of use of the UTXO set which would significa= ntly reduce these types of transactions going forward. That's not a one tim= e reduction and it's certainly not negligible.

&= gt;=C2=A0 Were such a proposal seriously advanced it would likely cause a new flood o= f transactions both to move to evade it directly

Maybe, but that's speculation at best. One could also speculate that even = the existence of this BIP proposal would likely cause those types of transa= ctions to move elsewhere. If the "marketing opportunity" for the NFT grifte= rs is to say the transactions could be worthless going forward, then yes, I= agree.

>=C2=A0 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 r= ules, and as such the network's rules have pretty limited effect.=C2=A0=C2= =A0

If the rules don't matter, they won't be bot= hered if the rules change.=C2=A0

>=C2=A0 the proposal would intentionally and knowingly confiscate millions of dolla= rs in funds.=C2=A0 This is outright theft, and I believe it makes the idea = a total non-starter.

When you say "millions of d= ollars in funds" are you including the value of the NFTs tied to those sats= or the just the total sum of all the unspendable dust? It would seem a lit= tle contradictory to call NFTs an imaginary in one breath and worth million= s of dollars in the next. To be clear, I'm not advocating for confiscation,= just trying to understand exactly where the millions of dollars in funds c= omes from.

To me this proposal is more about sen= ding a message that UTXO bloat is not welcome. I don't agree with direct co= nfiscation of funds but at the same time I hold the position that encouragi= ng the NFT grifters is only going to lead to more NFT gifters.
On Friday, 12 De= cember 2025 at 1:30:56=E2=80=AFam UTC+10 Greg Maxwell wrote:
You m= isunderstood my message that you've quoted-- understandable because tod= ay Bitcoin usage today is very different than=C2=A0back then.=C2=A0 In Sept= ember 2013 the average bitcoin blocksize=C2=A0was 120 kbytes and, as a resu= lt, there was no meaningful market competition for block space at the time.= =C2=A0 As a result there was essentially no incentive to minimize data usag= e in transactions and there was fairly little awareness of the potential me= ans to do so, beyond simple limits like things not relaying.=C2=A0 The situ= ation today is entirely different: Techniques to minimize usage are well un= derstood, widely deployed, and the cost of storing data that way is very hi= gh so none happens except by those who are very motivated and financially c= apable (and that motivation and means results in speed bumps having little = effect, -- or even positive effect, as the remaining abuses appear to find = bitcoin's costs/restrictions highly desirable to create scarcity for th= eir 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' reduct= ion, but it's not-- it's just full node storage in particular as th= e txouts in question are normally sized and largely quiescent=C2=A0already-= - so the savings is pretty insignificant.=C2=A0 Were such a proposal seriou= sly advanced it would likely cause a new flood of transactions both to move= to evade it directly and as a result of NFT indexer changes to just "= wormhole" the tokens to new outputs after the fact (and a new marketin= g opportunity=C2=A0for the NFT gifters).=C2=A0 NFTs are just an imaginary p= arallel world that don't depend on the network to validate their activi= ty, so they don't really care about the network's rules, and as suc= h the network's rules have pretty limited effect.=C2=A0=C2=A0

And moreover the proposal would intentionally and knowingly= confiscate millions of dollars in funds.=C2=A0 This is outright theft, and= I believe it makes the idea a total non-starter.

= As an aside, since the idea fails so easily on basic principled grounds it&= #39;s a disrespectful waste of participants time to advance a proposal at s= uch length and technobabbly=C2=A0depth which could have been floated with a= single sentence "How would people feel about a proposal to discourage= NFTs by identifying a snapshot of existing dust-value NFT outputs and maki= ng spending them consensus invalid?"=C2=A0 or similar.=C2=A0 =C2=A0Muc= h of the opposition to LLM use in the field of BIP discussion has been due = to widespread misuse of LLMs to create thickets of dense language and obscu= re non-starter, trivial, or ill considered proposals making them much more = costly to deal with and discouraging serious and thoughtful review of *all*= ongoing discussion.




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

Given recent discussions surrounding the malincentives = of spam and the perceived futility in addressing these issues, I felt it ne= cessary to propose a working solution. For those interested, I have written= a brief history of the problem; please skip to =E2=80=9CThe BIP=E2=80=9D b= elow if you are only interested in the proposal.


Bitcoin is a peer to peer open source monetary network created= to facilitate online payments between individuals without trust in a third= party. By its nature as an open protocol, and its censorship-resistant des= ign with no single authority maintaining its operation, we have to rely on = incentives and culture for network stewardship. Historically, we saw many t= rends emerge which threatened Bitcoin=E2=80=99s primary use as a monetary n= etwork. They were successfully dealt with by introducing OP_Return with a s= mall limit as a more efficient and limited way of directing non-monetary da= ta to a provably non-spendable space that could more easily be pruned from = nodes and, importantly, not pollute the UTXO set.


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


This was enfor= ced through standardness filters, which are a way of discouraging certain t= ypes of transactions that, while technically consensus valid, we have agree= d as a community are usually not used in standard practice and are potentia= lly harmful.


In recent years, these t= rends have come back into focus with the creation of schemes like Ordinal t= heory and its associated inscriptions, and Bitcoin Stamps, which are techni= ques for embedding non-monetary data (like images or tokens) into Bitcoin t= ransactions. Ordinals typically hide data in the Taproot witness field (ben= efiting from a weight =E2=80=9Cdiscount=E2=80=9D), while Stamps encode data= in unspendable outputs (e.g., fake bare multisig addresses). These practic= es turn the blockchain into a data storage system rather than purely a paym= ents network. As anyone familiar with basic economics knows, what you subsi= dize, you get more of.


Critically, ma= ny Ordinal inscription and Stamp transactions create dust outputs (tiny UTX= Os of only a few hundred sats) that remain unspent indefinitely, bloating t= he UTXO set. Because Stamp outputs are expected to remain unspent indefinit= ely, they persist in the UTXO set forever.


Veteran Bitcoin developer Mark =E2=80=9CMurch=E2=80=9D Erhardt has de= scribed the stamps UTXO issue as =E2= =80=9Cprobably, from a technical perspective, one of the more egregious use= s of blockchain."


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 ht= tps://groups.google.com/d/msgid/bitcoindev/32f8c689-314d-4a5e-9af6-2e3e7045= 82e6n%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/2ebbf019-a562-427d-93af-b88f0cf5658an%40googlegroups.com.
------=_Part_33595_331766997.1765504151838-- ------=_Part_33594_2097925772.1765504151838--