From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 12 Dec 2025 13:26:59 -0800 Received: from mail-ot1-f62.google.com ([209.85.210.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUAf9-0008NX-En for bitcoindev@gnusha.org; Fri, 12 Dec 2025 13:26:59 -0800 Received: by mail-ot1-f62.google.com with SMTP id 46e09a7af769-7c6ce3b9fa0sf1797794a34.0 for ; Fri, 12 Dec 2025 13:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765574809; x=1766179609; 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=MIh+bxy0DYYcAE/Pn6BudkoZv497bpBbfwDIWsdULVs=; b=GsxySTLgtSN3Xl0+F5yoGB7JIvDjUuhvoG72PvR7EPb6buHa8cw47EBDyb3hDCBYky 8jJF05EKJZ3n8b/Wbl9N0YnfIEHG83u8rM1rmdXGuFmwZswZbQBRWHVwTUtYh6Disb0q N+QGKWNkUnXj+DzZKUNZdN5oixTiY7zurdCRokFT1LSFqV3MYLr6Dv3FbVN4mcEF760I sHA2S9QJIRZWXtQR36363gGP+t2NOmyDAdeE5FAEK88IBhyMGtWSyJK45X4TrMD2KP1a 5ZKlFb04jsAALNaQSZ8UHE1FVTRjH5s78wjb0c7QxX5M3z9yj5NqPnJnIqjESVCDgHIJ st2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765574809; x=1766179609; 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=MIh+bxy0DYYcAE/Pn6BudkoZv497bpBbfwDIWsdULVs=; b=EJ+dBQiLMKkKBW4wV4nTvhzsBJoZ6lYdgIKzbtylXVDJs3o6Scz2dc7trDhYbQ+IbS CeanX3AgirJ7wfXczUpR9Hz0W6Ys0cMB+KkKp1JVigsQmw+Zo+7LqBL/cM/e8Rg0TXtn r2v/C2v5tLjh1ryVs5C837b/8kVwkPzJv4VsYCll3nLXDijqCbW77stqRM5ZdvviF4nu JKA87pv55aLF99izGPiJPkhIZucsIvNWPQqPXFp8XQt03QJQ7l5ee0tQcjM8BPwTibQ0 ChVW3AzyHrGFHHLjEDd8kNByUOWiNcWuxSvyxroAPWWsyiS2qz+bn9DyBD/Po5WlZpW/ 8skA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765574809; x=1766179609; 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=MIh+bxy0DYYcAE/Pn6BudkoZv497bpBbfwDIWsdULVs=; b=f+NUr4JxzJ9HYT4EVV1B6m9rV/8WvpgOTppOePMca2PedoT8frO3u86C1gRpv4JUHh Qaz0QZDn15hf/NXvj59YDW1zaAqtuVJ3as/NNgGuRWNQx6gO3D4cX9+hfTcQtiJveP0I mlgW0E3y4vLS31qzlvVIFYwiu+dkmj86jkn+CgqUF/D4aYTBMxKX5y1xMzz1+IwUXhbg ZAhsV5b0CDbiSXk5VSyJxrirHsGyoRYv3RErLIW+yjgQUqS2uEqfLkPKkRAj0qFHdODE BujQL150h0+SNMRCxqGX1dnqKQlKdUKYPg44Fyb6ZnilQW4xZtY9JO1eBJD/ZePhWd3l XcCg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWBS85FvJuL2rCd0vThF+qkJXBiEP8PxoBL2FyZ0dDLGgfia/NuZSReZOb6w/FM9h+XKHPzesJZzBKj@gnusha.org X-Gm-Message-State: AOJu0YzftYOQQJpeGGQEEbBM9zI1pCuJH7lSpsw0tZu9d3vwmuGjZxGg TNeWOWiawUUDcOwSV8exuQB3PJDnkGJHthgfA/wRKXWWdnRadGFp5IeT X-Google-Smtp-Source: AGHT+IF9S7WlTeWGqzZye87Nt8WjZVNMTbBnJEe4PyCu+Nxy3mgTkoY2gT6px+xGXzqhHyp1XaE6eg== X-Received: by 2002:a05:6820:82a:b0:659:9a49:8e3d with SMTP id 006d021491bc7-65b45182425mr1534058eaf.13.1765574808769; Fri, 12 Dec 2025 13:26:48 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbmbtkdbo40C4OCQjfeNK+FbUP48zndVsXpsM0vGkY2pQ==" Received: by 2002:a05:6871:81f:b0:3e8:4fc8:2284 with SMTP id 586e51a60fabf-3f5f83bf1bbls662188fac.0.-pod-prod-07-us; Fri, 12 Dec 2025 13:26:45 -0800 (PST) X-Received: by 2002:a05:6808:2e45:b0:450:c417:3a9a with SMTP id 5614622812f47-455aca58743mr1811914b6e.67.1765574804900; Fri, 12 Dec 2025 13:26:44 -0800 (PST) Received: by 2002:a05:690c:950d:b0:786:8d90:70d8 with SMTP id 00721157ae682-78e64591f1ems7b3; Fri, 12 Dec 2025 09:13:04 -0800 (PST) X-Received: by 2002:a05:690c:610f:b0:78d:6dba:6a4 with SMTP id 00721157ae682-78e66e5091cmr23416277b3.42.1765559583642; Fri, 12 Dec 2025 09:13:03 -0800 (PST) Date: Fri, 12 Dec 2025 09:13:03 -0800 (PST) From: Jonathan Voss To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com> References: <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com> Subject: [bitcoindev] Re: The Cat, BIP draft discussion. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_227820_2037574373.1765559583024" X-Original-Sender: K98kurz@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_227820_2037574373.1765559583024 Content-Type: multipart/alternative; boundary="----=_Part_227821_915674180.1765559583024" ------=_Part_227821_915674180.1765559583024 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since the Bitcoin Stamps outputs are already unspendable, it makes perfect= =20 sense to mark and drop them from the UTXO set. The outputs marked by Ord as= =20 containing the sats associated with a witness Inscription, on the other=20 hand, are inherently spendable; freezing those outputs would be direct=20 confiscation, which is conceptually antithetical to the purpose of Bitcoin = *per=20 se*. However, a transaction validation rule that requires that the number= =20 of outputs of a transaction containing those sats must be lower than the=20 number of inputs would damage the utility of Ordinals without confiscating= =20 the underlying bitcoins. This would require separately defining the=20 unspendable Stamp outputs and the abusive spam Ordinal outputs; the latter= =20 could be simplified by just specifying that any transaction containing an= =20 input of less than 1,000 sats must have fewer outputs than inputs, greatly= =20 reducing the complexity of the consensus change while still achieving=20 long-term UTXO set size reduction. On Wednesday, December 10, 2025 at 1:12:31=E2=80=AFPM UTC-5 Claire Ostrom w= rote: > 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 if= 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 rel= y=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 mo= netary=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-monetary= =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=9CPa= rt 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 creation= =20 > of schemes like Ordinal theory and its associated inscriptions, and Bitco= in=20 > Stamps, which are techniques for embedding non-monetary data (like images= =20 > or tokens) into Bitcoin transactions. Ordinals typically hide data in the= =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 tha= n=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 t= o=20 > remain unspent indefinitely, they persist in the UTXO set forever. > > Veteran Bitcoin developer Mark =E2=80=9CMurch=E2=80=9D Erhardt has descri= bed the stamps=20 > UTXO issue as =E2=80=9Cprobably, from a technical perspective, one of the= 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 = gradually=20 > to around 80-90 million entries. Then, in less than a year, it doubled to= =20 > more than 160 million by late 2023, a historic anomaly driven largely by= =20 > the Ordinals and Stamps craze. Analyses suggest that by mid-2025, over 30= %=20 > of all UTXOs were tied to Ordinal inscriptions. Nearly half of all UTXOs= =20 > (around 49%) now contain less than 1,000 satoshis, strongly indicating th= ey=20 > are spammy dust outputs used for data embedding rather than normal econom= ic=20 > activity. Many of these are Taproot outputs or outputs sitting exactly at= =20 > the standard dust threshold, consistent with algorithmic spam creation. I= n=20 > short, UTXO spam now accounts for tens of millions of entries and=20 > represents an unprecedented explosion of UTXO bloat. > > 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 exceede= d=20 > 11 GB, meaning the disk footprint required to hold the unspent set roughl= y=20 > doubled in about a year, in line with Ordinals and BRC-20 mania. Over the= =20 > same period, the full blockchain grew by about 93 GB in 2023 alone, versu= s=20 > roughly 55 GB per year previously, largely due to inscription data fillin= g=20 > blocks. While pruned nodes can discard old block data, they cannot discar= d=20 > UTXOs: every unspent output, even spam, must remain in the chainstate unt= il=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 developers= =20 > have noted, techniques that deliberately embed data in UTXOs are among th= e=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 h= ave=20 > continually evolved =E2=80=9Ccat-and-mouse=E2=80=9D tactics to bypass the= m. > > This is where our proposal comes in. > > THE BIP: The Cat. > > > Recent attempts to reduce spam have focused on the supply side, trying to= =20 > stop spam through policy and standardness rules. These efforts have had= =20 > limited success. The Cat instead looks to economics, removing or reducing= =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 using= established=20 > external indexers, and makes them permanently unspendable by consensus, s= o=20 > that such data cannot be monetized or transacted, only archived. Once=20 > rendered unspendable, we will be removing these UTXOs made unspendable by= =20 > consensus under this proposal, from the UTXO set, materially reducing the= =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 this= =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 a= nd=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 as= defined by=20 > this BIP.=E2=80=9D Implementations MAY choose to compute this bit on the = fly from=20 > 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 val= ue=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 a= s=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 created= =20 > between: > > > H_min_NMU: the earliest block height at which the reference indexers (Ord= =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 activation= .=20 > Any UTXO created at height < H_min_NMU or > H_snap MUST be treated as=20 > 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 non-NMU= =20 > outpoints at H_snap that would otherwise match the filter. > =20 > > NMU_DATA is distributed as a single binary blob, together with a consensu= s=20 > constant NMU_DATA_HASH =3D SHA256d(NMU_DATA) which all compliant=20 > implementations MUST verify before using it for consensus validation (see= =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 a= nd=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 i= n=20 > NMUSet_snap or not; it does not depend on how any particular node obtaine= d=20 > 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 are= =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 NMU= _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 as= =20 > defined in =C2=A71. > > > 2.1 Ord NMU set > > > According to the classification rules implemented in Ord 0.24.0 at commit= =20 > 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is parsed for=20 > =E2=80=9Cinscription envelopes=E2=80=9D and each recognized inscription i= s 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 Or= d=20 > 0.24.0 would associate with a specific outpoint (txid, vout) on that chai= n,=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 thresh= olds in =C2=A72.3. > > > An implementation may obtain OrdNMUSet by actually running Ord 0.24.0, or= =20 > by re-implementing its published classification rules and applying them t= o=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 embedde= d assets and=20 > associate them with one or more bare multisig outputs on the best chain a= t=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 n= ew=20 > consensus rule (see =C2=A74). Nodes MAY realize this either by pre-seedin= g 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 independentl= y=20 > derive and verify NMUSet_snap; it is not a requirement for ordinary full= =20 > 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 combine= d=20 > with otherwise monetary funds. > > > Restricting to height(u) =E2=89=A5 H_min_NMU reflects the historical fact= 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 H_sna= p=20 > by introducing a new consensus constant: > > > SNAP_BLOCK_HASH: a 32-byte value equal to the block hash at height H_snap= =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_snap= has a=20 > different hash, the node MUST treat all UTXOs as monetary (NMU =3D 0) for= 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 bes= t=20 > chain once again has SNAP_BLOCK_HASH at height H_snap. Any desire to appl= y=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 stored= =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 UTXO= s.=20 > Conceptually, for a UTXO u with value(u) and height(u), NMU(u) is defined= =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 consensus= rule=20 > in =C2=A74, using the NMU classification defined above. No reindex or UTX= O=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/o= r > =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 reindex= =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-by= te=20 > key. > > > txid_le (bytes 0=E2=80=9331): the 32-byte transaction ID in little-endian= 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 an= d=20 > 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 SNAP_BLOCK_HASH= =20 > from section =C2=A72.4). > -=20 > =20 > FILTER_SEED (8 bytes): 64-bit seed used by the Binary Fuse Filter hash= =20 > 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 w= ould=20 > otherwise match the filter. > -=20 > =20 > CHECKSUM (32 bytes): SHA256d of all preceding bytes from MAGIC through= =20 > 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 its= =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 an= =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 they= =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 fil= ter=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 snapsh= ot=20 > construction, the false positive exclusion list FP_EXCLUDE is computed by= =20 > enumerating all UTXOs at H_snap that are not in NMUSet_snap, testing each= =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=99= s=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 appears= =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 wi= th=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 valu= e(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 successfu= lly=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 (txid= ,=20 > vout) such that the corresponding UTXO u satisfies is_nmu(u) =3D true as= =20 > 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 = at=20 > 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 rejecte= d=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) a= s=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 pruni= ng=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 access= =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 alread= y=20 > used by the non-monetary data community, specifically Ord and Stamps. Exa= ct=20 > versions of these indexers are specified and pinned by commit so that the= ir=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 without= =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 fo= r=20 > future BIPs. If further action is desired on post-snapshot NMU formats, t= he=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, they= =20 > can be removed from the UTXO set, which reduces its size. The new storage= =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_sn= ap=20 > plus a correction list of false positives. For a plausible NMU count on t= he=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 compressi= on, for an=20 > uncompressed size on the order of 70=E2=80=9380 MB and an expected compre= ssed 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 storag= e=20 > overhead remains a single NMU bit if implementations choose to materializ= e=20 > it in the database; the rest of the classification data is stored once pe= r=20 > node. > > > Censorship resistance and scope > > > Bitcoin=E2=80=99s censorship resistance is primarily concerned with the a= bility to=20 > move monetary value without trusted intermediaries. This proposal=20 > intentionally targets non-monetary uses of the chain (inscriptions, stamp= s,=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 to= a=20 > one-time, transparently derived set of dust-sized non-monetary outputs. A= ny=20 > attempt to apply similar techniques to ordinary monetary UTXOs would be= =20 > highly contentious and would require explicit social consensus from users= ,=20 > miners, and economic nodes. In other words, this mechanism does not lower= =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) identifie= d=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) within= =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 in= =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 full= y=20 > validating node. The criteria for which outputs are designated as NMUs ar= e=20 > necessarily known and established by virtue of how prevalent and open the= =20 > targeted data protocols are. > > > It is valid to worry that fewer than 100% of node runners will regenerate= =20 > the NMU list themselves, somewhat increasing the overall trust placed in= =20 > third parties compared to today. However, this concern applies specifical= ly=20 > to a =E2=80=9Cblacklist of UTXOs,=E2=80=9D which is precisely the area wh= ere scrutiny is=20 > highest. That scrutiny should help ensure that enough independent parties= =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. Bitcoiners= =20 > accept that many users will only run node binaries they download, rather= =20 > than compiling from source and independently verifying the code. Compiled= =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 not= =20 > implement The Cat will continue to accept blocks that spend NMUs as valid= ,=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 wi= ll=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 associated= =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 Stamps= ,=20 > 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 encoded= =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 commit= =20 > 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is scanned for=20 > =E2=80=9Cinscription envelopes=E2=80=9D in Taproot script paths. An inscr= iption envelope is=20 > an OP_FALSE OP_IF =E2=80=A6 OP_ENDIF block containing data pushes that st= art with=20 > the ASCII tag ord and encode a content type and body. When those rules ar= e=20 > applied to the best chain up to height H_snap, each recognized inscriptio= n=20 > is associated with a particular outpoint (txid, vout) (typically the firs= t=20 > satoshi of a reveal transaction input, or as directed by the pointer fiel= d=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 rule= s. > > > Stamps (BTC Stamps). > > According to the classification rules implemented in the pinned BTC Stamp= s=20 > indexer, Counterparty transactions are inspected for a STAMP:-prefixed=20 > base64 string in the description field, which encodes image data. The=20 > Stamps rules then map this metadata to specific dust-sized bare multisig= =20 > outputs in the underlying Bitcoin transactions. When those rules are=20 > 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 defin= ed=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 mor= e=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 chain= =20 > in the same way is greatly reduced. > > > Can=E2=80=99t users just spend their NMUs after the snapshot, removing th= em 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 b= e=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 b= y=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 th= at Ord and=20 > similar indexers are treating as non-monetary artifacts. The Cat does not= =20 > look at individual sat numbers or =E2=80=9Crarity=E2=80=9D directly; it o= nly 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 the= =20 > snapshot. > =20 > > Anything at or above VALUE_MAX_NMU is always treated as a normal monetary= =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 sats= =E2=80=9D now=20 > live inside a normal-sized wallet UTXO (1,000 sats or more), this proposa= l=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 O= rd=20 > (or Stamps) is already treating as non-monetary artifacts at H_snap. Thos= e=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 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/= e3658771-128f-4e45-9465-860baf466ee4n%40googlegroups.com. ------=_Part_227821_915674180.1765559583024 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since the Bitcoin Stamps outputs are already unspendable, it makes perfect = sense to mark and drop them from the UTXO set. The outputs marked by Ord as= containing the sats associated with a witness Inscription, on the other ha= nd, are inherently spendable; freezing those outputs would be direct confis= cation, which is conceptually antithetical to the purpose of Bitcoin per= se. However, a transaction validation rule that requires that the numb= er of outputs of a transaction containing those sats must be lower than the= number of inputs would damage the utility of Ordinals without confiscating= the underlying bitcoins. This would require separately defining the unspen= dable Stamp outputs and the abusive spam Ordinal outputs; the latter could = be simplified by just specifying that any transaction containing an input o= f less than 1,000 sats must have fewer outputs than inputs, greatly reducin= g the complexity of the consensus change while still achieving long-term UT= XO set size reduction.

On Wednesday, December 10, 2025 at 1:12:31= =E2=80=AFPM UTC-5 Claire Ostrom wrote:
Dear Bitcoin-dev,

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


Bitcoin is a peer to peer open source monetary network created to faci= litate online payments between individuals without trust in a third party. = By its nature as an open protocol, and its censorship-resistant design with= no single authority maintaining its operation, we have to rely on incentiv= es and culture for network stewardship. Historically, we saw many trends em= erge which threatened Bitcoin=E2=80=99s primary use as a monetary network. = They were successfully dealt with by introducing OP_Return with a small lim= it as a more efficient and limited way of directing non-monetary data to a = provably non-spendable space that could more easily be pruned from nodes an= d, importantly, not pollute the UTXO set.


Legendary Bitcoin developer Gregory Maxwell said at the time, <= a href=3D"https://github.com/bitcoin/bitcoin/pull/2738#issuecomment-2501736= 8" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g= oogle.com/url?hl=3Den-US&q=3Dhttps://github.com/bitcoin/bitcoin/pull/27= 38%23issuecomment-25017368&source=3Dgmail&ust=3D1765641837818000&am= p;usg=3DAOvVaw28igezmWkWJ7CGrzKbV8ID">= =E2=80=9CPart of the idea here is shaping behavior towards conservative nee= ds.=E2=80=9D


This was enforced th= rough standardness filters, which are a way of discouraging certain types o= f transactions that, while technically consensus valid, we have agreed as a= community are usually not used in standard practice and are potentially ha= rmful.


In recent years, these trends = have come back into focus with the creation of schemes like Ordinal theory = and its associated inscriptions, and Bitcoin Stamps, which are techniques f= or embedding non-monetary data (like images or tokens) into Bitcoin transac= tions. Ordinals typically hide data in the Taproot witness field (benefitin= g from a weight =E2=80=9Cdiscount=E2=80=9D), while Stamps encode data in un= spendable outputs (e.g., fake bare multisig addresses). These practices tur= n the blockchain into a data storage system rather than purely a payments n= etwork. As anyone familiar with basic economics knows, what you subsidize, = you get more of.


Critically, many Ord= inal inscription and Stamp transactions create dust outputs (tiny UTXOs of = only a few hundred sats) that remain unspent indefinitely, bloating the UTX= O set. Because Stamp outputs are expected to remain unspent indefinitely, t= hey persist in the UTXO set forever.


= Veteran Bitcoin developer Mark =E2=80=9CMurch=E2=80=9D Erhardt has describe= d the stamps UTXO issue as =E2=80=9Cpr= obably, from a technical perspective, one of the more egregious uses of blo= ckchain."


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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/e3658771-128f-4e45-9465-860baf466ee4n%40googlegroups.com.
------=_Part_227821_915674180.1765559583024-- ------=_Part_227820_2037574373.1765559583024--