* Re: [bitcoindev] The Cat, BIP draft discussion.
[not found] ` <CAAS2fgRR77nZj3-rJo70dnxe8Lma88-C9JqdVTYfXGHRgFu3pA@mail.gmail.com>
@ 2025-12-11 20:54 ` Bitcoin Mechanic
2025-12-12 1:49 ` TwoLargePizzas
1 sibling, 0 replies; 20+ messages in thread
From: Bitcoin Mechanic @ 2025-12-11 20:54 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 53687 bytes --]
Hi Greg, (for response to Claire, list, please scroll down)
>The situation today is entirely different: Techniques to minimize usage
are well understood, widely deployed, and the cost of storing data that way
is very high so none happens except by those who are very motivated and
financially capable (and that motivation and means results in speed bumps
having little effect...
This isn't true. It's the classic "survivorship bias" mistake that gets
made constantly throughout the general discussion about arbitrary data.
You're trying to count road traffic accidents that didn't occur due to the
existence of said speed bumps which can only be done through indirect
analysis for obvious reasons. Every time this comes up, people can point to
things as minimal as a tweet from someone influential with the Bitcoin
space saying something to the tune of "I don't like spam" that results in
some scam built on top of Bitcoin tanking to zero and its ecosystem dying.
The easiest example is always Vitalik explaining his decision to make ETH
elsewhere and not on Bitcoin due - in part - to spam filters which today
you all decided "don't work" despite having demonstrably helped in keeping
Bitcoin separate from that dumpster fire -
https://x.com/VitalikButerin/status/929805462052229120
tldr: It doesn't matter if anti-spam mechanisms are not water-tight. You
acknowledging that "they have little effect" is an admission of the fact
that they have *some* effect which is fine - assuming the tradeoffs are
acceptable. I am certainly happy to work within those confines - and indeed
have been for this entire discussion. Spam mitigation cannot come at too
great of a detriment to other aspects of Bitcoin and "The Cat" is certainly
reasonable to consider over the line (though I'm not sure where I stand yet
- so I appreciate any further discussion on the topic.)
Philosophically UTXO deletion is counter to Bitcoin's ethos, no one would
deny it. Practically speaking however, we all know that's it's perfectly
reasonable to dismiss a large % of the UTXO set as junk (regardless of if
The Cat or similar were to activate).
>>negligible one time reduction in utxo disk space
I would never have considered The Cat if such a large % wasn't garbage. But
at present, it looks to be somewhere between 40-50% of it - and deleting
that would not be negligible. For a maximally pruned node that's a 50%
reduction in disk space and when people run vast arrays of nodes in the
cloud (large miners do this for obvious reasons) the savings quickly become
non-negligible.
>NFTs are just an imaginary parallel world that don't depend on the network
to validate their activity, so they don't really care about the network's
rules, and as such the network's rules have pretty limited effect.
"Stamps" are unspendable anyway by design and thus, we'd just be saving
some disk space for ourselves - true. It would have no effect on what
they're doing, we're just cleaning up their essentially abandoned trash.
For other spam however, they do in fact need their outputs to remain
spendable. Making their "art" unspendable would massively disrupt that
activity. For any serious protocol that wants to trick Bitcoin nodes into
storing useless data (from the perspective of monetary users of Bitcoin)
they can always be pushed to asking themselves "why don't we do this on
another network that isn't going to delete our ability to spend our 'art'?"
Again, it doesn't matter how dissuasive an effect this conversation - or
even activation of The Cat or any other spam-mitigation - has. If it has
*some* effect then it's just a question of making sure the tradeoffs are
worth it. That is all you can ever hope for in reducing spam on any
protocol.
I don't think it's at all reasonable to say that making an eight figure
amount of NFTs/Inscriptions etc unspendable would have more than a "pretty
limited effect".
>This is outright theft
No it isn't. It's more akin to "destruction of property". No one acquires
this "stolen property" as it ceases to exist.
>AI
It really isn't relevant. This is sadly becoming a trope, to just complain
that proposals people don't like are "written by AI". I did suggest that
people should declare to what extent AI was/wasn't used in an effort to
update etiquette to current circumstances. I don't find the proposal
ridiculous, though also not prepared to fully endorse it either as I'll go
into below.
I replied with my stance on The Cat below if you're interested.
---
Hi Claire, list,
I don't wish for this to be taken as strong support or advocacy as I
genuinely am not that "Crossing the Rubicon" with UTXO deletion is worth
it, though I also find concerns that I have encountered on social media
about precedent to be overblown. Mechanisms for UTXO deletion exist within
Bitcoin regardless of if The Cat were to activate or not. The motivation to
employ them does not necessarily extend to government blacklisting simply
by virtue of them having been utilized to delete the UTXOs that this
specific proposal would target.
I think anyone of capable of the slightest discernment can tell the
difference between what this proposal dubs "NMUs" versus genuine UTXOs, and
that it would succeed in its goal of making it far more difficult to
convince suckers to buy some future Bitcoin-using-NFT given the network's
exercised ability and willingness to throw what they're doing in the
garbage.
I have been aware of this proposal for a couple of weeks, and it started
getting discussed on social media prior to here.
Not once in this time have I had the sinking feeling that if this were to
succeed, that it'd call my UTXOs into question as I just do not for a
minute believe people running Bitcoin nodes would ever activate a fork that
targeted anything more than what "The Cat" seeks to eliminate, *or similar*.
Many are aware of my position on spam filtration. Spam filters reject
"valid transactions" as is happily pointed out by supposed ideologues who
have no understanding of how nodes typically function or indeed how they
must continue to operate. I am, for the record, in favour of nodes
rejecting abusive activity, regardless of their protocol validity and
consider this trivially moral for those who believe in property rights.
The Cat calls property rights into question by deleting UTXOs. I don't
consider it unreasonable for Bitcoin users to do this if they see fit as
the UTXO set is something that they must contribute resources to
maintaining in perpetuity, as opposed to simply leaving unmolested and
ignored. (And interestingly, the "property" the spammers claim to be
concerned with is the data itself, not the ability to move it, and that's
maintained even post "The Cat" save for, though I don't want to
misrepresent what their intention is - the only reason they're interested
in owning this "art" is so that they can sell it and The Cat would make
them unable to sell it without having to route around Bitcoin rug-pulling
their ability to do so.)
Therefore I see no relevant philosophical difference between filtering
"valid transactions" and deleting "valid UTXOs" if the discernment required
in separating egregious abuse of the network from intended usage is minimal
- which it certainly is with regard to the current spam. It's almost all
sitting conveniently at the various dust limits with glaringly obvious
footprints, necessarily publicly indexed on websites/explorers with well
known software made for the purposes of interacting with those ecosystems
that can be recreated for the purposes of slating their associated UTXOs
for deletion.
(Philosophical tidbit: both filtration and UTXO-deletion get characterized
as 'censorship', which of course is false in both cases: Bitcoin users are
not acting on behalf of a government and instead simply doing what's in
their best interest.)
In practice, and far more importantly, the difference between spam
filtration and deleting NMUS is the fact that a bad spam filter is no big
deal. It can be routed around and simply fixed if necessary and there's no
getting rid of them from nodes anyway.
Mistaken UTXO deletion on the other hand would be disastrous. Recovery from
that would be a mess to say the least.
So the snapshot taken by "The Cat" would need to be extremely well vetted
which I believe the proposal actually covers extremely well as my natural
concern would be a too small a % of the Bitcoin community verifying its
contents and thus trusting third parties to have indexed all these junk
UTXOs accurately. I cannot believe people would be so sloppy in that regard
given that their UTXOs could be what end up in that list so hopefully - as
the proposal itself states - that should become a motivation for a huge
number of people verifying the contents of the list.
So in summary, my concerns with The Cat are too few independently indexing
and attesting to the NMU list which again, the proposal addresses
satisfactorily in my opinion.
I remain unwilling to advocate for this proposal any more strongly than I
have done here, but would appreciate more substantial push back from others
who dislike it because as it stands currently, I would not be unhappy if
this ended up successfully activating.
Kind regards,
Bitcoin Mechanic
On Thursday, December 11, 2025 at 7:30:56 AM UTC-8 Greg Maxwell wrote:
> You misunderstood my message that you've quoted-- understandable because
> today Bitcoin usage today is very different than back then. In September
> 2013 the average bitcoin blocksize was 120 kbytes and, as a result, there
> was no meaningful market competition for block space at the time. As a
> result there was essentially no incentive to minimize data usage in
> transactions and there was fairly little awareness of the potential means
> to do so, beyond simple limits like things not relaying. The situation
> today is entirely different: Techniques to minimize usage are well
> understood, widely deployed, and the cost of storing data that way is very
> high so none happens except by those who are very motivated and financially
> capable (and that 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 their
> tokens).
>
> On your proposal,
>
> The proposed gain is some negligible one time reduction in utxo disk
> space. You motivated it by claiming this is a 'memory usage' reduction, but
> it's not-- it's just full node storage in particular as the txouts in
> question are normally sized and largely quiescent already-- so the savings
> is pretty insignificant. Were such a proposal seriously 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 marketing opportunity for the NFT
> gifters). NFTs are just an imaginary parallel world that don't depend on
> the network to validate their activity, so they don't really care about the
> network's rules, and as such the network's rules have pretty limited
> effect.
>
> And moreover the proposal would intentionally and knowingly confiscate
> millions of dollars in funds. 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's a disrespectful waste of participants time to advance a proposal at
> such length and technobabbly depth 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 making
> spending them consensus invalid?" or similar. Much 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 obscure 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 PM Claire Ostrom <ostromcl...@gmail.com>
> 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 brief
>> history of the problem; please skip to “The BIP” below 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
>> design with no single authority maintaining its operation, we have to rely
>> on incentives and culture for network stewardship. Historically, we saw
>> many trends emerge which threatened Bitcoin’s primary use as a monetary
>> network. They were successfully dealt with by introducing OP_Return with a
>> small limit 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 and, importantly, not pollute the UTXO set.
>>
>> Legendary Bitcoin developer Gregory Maxwell said at the time, “Part of
>> the idea here is shaping behavior towards conservative needs.”
>> <https://github.com/bitcoin/bitcoin/pull/2738#issuecomment-25017368>
>>
>> This was enforced through standardness filters, which are a way of
>> discouraging certain types of transactions that, while technically
>> consensus valid, we have agreed as a community are usually not used in
>> standard practice and are potentially harmful.
>>
>> In recent years, these trends have come back into focus with the creation
>> of schemes like Ordinal theory and its associated inscriptions, and Bitcoin
>> Stamps, which are techniques for embedding non-monetary data (like images
>> or tokens) into Bitcoin transactions. Ordinals typically hide data in the
>> Taproot witness field (benefiting from a weight “discount”), while Stamps
>> encode data in unspendable outputs (e.g., fake bare multisig addresses).
>> These practices turn the blockchain into a data storage system rather than
>> purely a payments network. As anyone familiar with basic economics knows,
>> what you subsidize, you get more of.
>>
>> Critically, many Ordinal inscription and Stamp transactions create dust
>> outputs (tiny UTXOs of only a few hundred sats) that remain unspent
>> indefinitely, bloating the UTXO set. Because Stamp outputs are expected to
>> remain unspent indefinitely, they persist in the UTXO set forever.
>>
>> Veteran Bitcoin developer Mark “Murch” Erhardt has described the stamps
>> UTXO issue as “probably, from a technical perspective, one of the more
>> egregious uses of blockchain."
>> <https://bitcoinops.org/en/podcast/2023/12/21/>
>>
>> [image: Screenshot 2025-12-01 212654.png]
>>
>> Over roughly 14 years (2009-early 2023), Bitcoin’s UTXO set grew
>> gradually to around 80-90 million 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 to Ordinal inscriptions. Nearly
>> half of all UTXOs (around 49%) now contain less than 1,000 satoshis,
>> strongly indicating they are spammy dust outputs used for data embedding
>> rather than normal economic activity. Many of these are Taproot outputs or
>> outputs sitting exactly at the standard dust threshold, consistent with
>> algorithmic spam creation. In short, UTXO spam now accounts for tens of
>> millions of entries and represents an unprecedented explosion of UTXO bloat.
>>
>> The UTXO database (chainstate) has ballooned 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 Ordinals and BRC-20 mania. Over the
>> same period, the full blockchain grew by about 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, must remain in the chainstate until
>> it is spent or explicitly removed by a protocol 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 under current rules.
>>
>> Bitcoin’s design includes some anti-spam measures, but spammers have
>> continually evolved “cat-and-mouse” tactics to bypass them.
>>
>> This is where our proposal comes in.
>>
>> THE BIP: The Cat.
>>
>>
>> Recent attempts to reduce spam have focused on the supply side, trying to
>> stop spam through policy and standardness rules. These efforts have had
>> limited success. The Cat instead looks to economics, removing or reducing
>> the financial incentive for creating spam outputs in the first place. It
>> targets the demand side by making designated Non-Monetary UTXOs (NMUs)
>> permanently unspendable, which in turn reduces market demand for those
>> assets.
>>
>>
>> The Cat defines a fixed, reproducible set of “NMUs” using established
>> external indexers, and makes them permanently unspendable by consensus, so
>> that such data cannot be monetized or transacted, only archived. Once
>> rendered unspendable, we will be removing these UTXOs made unspendable by
>> consensus under this proposal, from the UTXO set, materially reducing the
>> current resource 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 plus a false-positive exclusion list) that ships with
>> the binary and does not require any node to reindex or re-download the
>> chain.
>>
>>
>>
>> Draft Specification
>>
>>
>> Status: Discussion draft. A formal BIP, compliant with BIP 0003 and the
>> usual BIP process, will be prepared if there is interest in pursuing this
>> direction.
>>
>>
>> 1. Definitions
>>
>>
>> Non-Monetary UTXO (NMU):
>>
>>
>> A UTXO that is classified as containing inscription-style or stamp-style
>> data according to the procedure in §2 and that satisfies the value and
>> creation-height constraints below.
>>
>>
>> NMU bit:
>>
>>
>> A single Boolean flag (0 or 1) stored alongside each UTXO in the node’s
>> UTXO database:
>>
>>
>>
>> -
>>
>> NMU = 1 -> UTXO is non-monetary and may not be spent.
>>
>>
>>
>> -
>>
>> NMU = 0 -> UTXO is monetary (normal behavior).
>>
>>
>> Conceptually, NMU = 1 means “this outpoint is in NMUSet_snap as defined
>> by this BIP.” Implementations MAY choose to compute this bit on the fly
>> from the membership structure rather than store it explicitly; see §3.
>>
>>
>> NMU value threshold:
>>
>>
>> A consensus constant VALUE_MAX_NMU = 1000 satoshis. Only UTXOs with value
>> strictly less than VALUE_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 = 0) for all time under this BIP, even if external tools
>> associate inscriptions or stamps with some of their satoshis.
>>
>>
>> NMU creation-height window:
>>
>>
>> This proposal intentionally restricts NMU classification to UTXOs created
>> between:
>>
>>
>> H_min_NMU: the earliest block height at which the reference indexers (Ord
>> 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 §2.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 = 0) regardless of filter results.
>>
>>
>> NMU membership structure (NMU_DATA):
>>
>>
>> A static, exact membership structure that encodes NMUSet_snap using:
>>
>>
>>
>> -
>>
>> A Binary Fuse 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 binary blob, together with a
>> consensus constant NMU_DATA_HASH = SHA256d(NMU_DATA) which all compliant
>> implementations MUST verify before using it for consensus validation (see
>> §3.3).
>>
>>
>> Activation height (H_cat):
>>
>>
>> A consensus constant H_cat, the block height at which the NMU spending
>> rule in §4 first becomes eligible for enforcement. The exact value and
>> deployment mechanism for H_cat are out of scope for this draft and would be
>> specified in a formal BIP.
>>
>>
>> 2. NMU classification (reproducible list)
>>
>>
>> The normative consensus object introduced by this BIP is the set
>> NMUSet_snap: a fixed set of outpoints classified as non-monetary at
>> snapshot height H_snap on the best chain, after applying the value and
>> height restrictions in §1 and §2.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 particular node
>> obtained that set.
>>
>>
>> To define NMUSet_snap in a precise and reproducible way, this BIP
>> specifies two reference classification rule sets that operate purely on
>> Bitcoin chain data, as implemented in:
>>
>>
>>
>> -
>>
>> Ord 0.24.0 at commit 5d2fbbe64b362cd6c30d6901e50cbe80084761f8
>>
>>
>>
>> -
>>
>> Stamps - [exact version/commit to be pinned before any activation]
>>
>>
>> These reference implementations define the inscription-style and
>> stamp-style classification rules in terms of Bitcoin chain data. They are
>> cited here as normative descriptions of how to decide whether a given
>> outpoint carries an inscription or a stamp at height H_snap.
>>
>>
>> Implementations that wish to independently 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 or Stamps is not required for ordinary full-node operation
>> under this BIP; they are simply the canonical specification of the
>> classification logic.
>>
>>
>> This section uses the consensus constants H_cat, H_snap, and H_min_NMU as
>> defined in §1.
>>
>>
>> 2.1 Ord NMU set
>>
>>
>> According to the classification rules implemented in Ord 0.24.0 at commit
>> 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is parsed for
>> “inscription envelopes” and each recognized inscription is associated with
>> 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
>> rules are applied to the best chain up to H_snap, are classified as
>> carrying inscriptions at H_snap. Concretely, for each inscription that Ord
>> 0.24.0 would associate with a specific outpoint (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 “NMU” if they meet the value and height thresholds in §2.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 classification rules implemented in the specified BTC
>> Stamps indexer (version/commit TBD), Counterparty metadata and Bitcoin
>> transactions are parsed to identify “stamp-style” embedded assets and
>> associate them with one or more bare multisig outputs on the best chain at
>> height H_snap.
>>
>>
>> Define StampsNMUSet as the set of all outpoints that, when those Stamps
>> rules are applied 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 associate with a specific outpoint (txid, vout) on
>> that chain, that outpoint is included in StampsNMUSet.
>>
>>
>> As with Ord, an implementation may obtain StampsNMUSet either by running
>> the reference Stamps indexer or by independently implementing the same
>> 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 = OrdNMUSet ∪ StampsNMUSet
>>
>>
>> Apply both the NMU value threshold and the creation-height window:
>>
>>
>> NMUSet_snap = { u ∈ NMUSet_raw | value(u) < VALUE_MAX_NMU and H_min_NMU ≤
>> height(u) ≤ H_snap }
>>
>>
>> where value(u) is the number of satoshis in UTXO u, and height(u) is the
>> height of the block that created that UTXO.
>>
>>
>> Every UTXO in NMUSet_snap MUST be treated as having NMU = 1 under the new
>> consensus rule (see §4). Nodes MAY realize this either by pre-seeding an
>> NMU bit in their UTXO database or by computing it dynamically via the
>> membership query in §3.3.
>>
>>
>> Notes:
>>
>>
>> Running Ord or Stamps is only required for those who wish to
>> independently derive and verify NMUSet_snap; it is not a requirement for
>> ordinary full node operation under The Cat.
>>
>>
>> The value threshold is intended to avoid classifying large, mixed-use
>> UTXOs as NMUs when a small number of inscribed satoshis have been combined
>> with otherwise monetary funds.
>>
>>
>> Restricting to height(u) ≥ H_min_NMU reflects the historical fact that
>> these protocols appeared only after a certain point, and it trivially
>> avoids misclassification of very old UTXOs.
>>
>>
>> This proposal intentionally does not specify any new in-client
>> classification rule for discovering future NMU formats. It explicitly
>> targets non-monetary UTXOs identifiable via Ord 0.24.0 and Stamps at the
>> time of snapshot.
>>
>>
>> 2.4 Snapshot block commitment and reorg behaviour
>>
>>
>> This BIP commits to a specific chain history at the snapshot height
>> H_snap by introducing a new consensus constant:
>>
>>
>> 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 derived.
>>
>>
>> A node MUST only enforce the NMU consensus rule from §4 if, for its
>> 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’s current best chain, the block at height H_snap has a
>> different hash, the node MUST treat all UTXOs as monetary (NMU = 0) for the
>> purposes of consensus validation, and MUST NOT reject any transaction or
>> block on the basis of the NMU 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),
>> enforcement of The Cat is automatically disabled until and unless the best
>> chain once again has SNAP_BLOCK_HASH at height H_snap. Any desire to apply
>> NMU 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 activation
>>
>>
>> 3.1 NMU bit storage model
>>
>>
>> Consensus only cares about which UTXOs are NMU, not how the bit is stored
>> or computed. Implementations MAY:
>>
>>
>>
>> -
>>
>> Store the NMU bit as an extra bit in the UTXO database (e.g., in the
>> Coin structure).
>>
>>
>>
>> -
>>
>> Store NMUs in a separate structure keyed by outpoint.
>>
>>
>>
>> -
>>
>> Compute NMU on the fly at validation time using the NMU_DATA
>> membership structure from §3.3, optionally caching results.
>>
>>
>> The only consensus requirement is: given the same chain, compliant
>> implementations must converge on the same NMU classification for all UTXOs.
>> Conceptually, for a UTXO u with value(u) and height(u), NMU(u) is defined
>> as:
>>
>>
>>
>> -
>>
>> 1 if:
>>
>>
>>
>> -
>>
>> H_min_NMU ≤ height(u) ≤ H_snap, and
>>
>>
>>
>> -
>>
>> value(u) < VALUE_MAX_NMU, and
>>
>>
>>
>> -
>>
>> u ∈ NMUSet_snap (as tested via §3.3),
>>
>>
>>
>> -
>>
>> 0 otherwise.
>>
>>
>> 3.2 Activation
>>
>>
>> At activation height H_cat:
>>
>>
>> Nodes must have:
>>
>>
>>
>> -
>>
>> Fully validated the chain up to at least H_snap.
>>
>>
>>
>> -
>>
>> Loaded and verified NMU_DATA (see §3.3).
>>
>>
>> From the first block at or after H_cat for which the snapshot block
>> commitment condition in §2.4 holds, nodes MUST enforce the consensus rule
>> in §4, using the NMU classification defined above. No reindex or UTXO
>> rewrite is required for activation; NMU classification can be applied as an
>> overlay on top of the existing UTXO database.
>>
>>
>> Implementations MAY, as an optimization, perform a one-time pass over
>> their UTXO set after activation to:
>>
>>
>>
>> -
>>
>> Set Coin.NMU = 1 for all UTXOs that satisfy the NMU predicate; and/or
>>
>>
>>
>> -
>>
>> Physically delete such UTXOs from the UTXO database (see §5).
>>
>>
>> Such a pass is a local optimization and not required for 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 block download or reindex
>> the chain in order to enforce NMU classification. Instead, it commits to a
>> canonical membership structure NMU_DATA which encodes NMUSet_snap in a
>> compact form.
>>
>>
>> 3.3.1 Canonical outpoint encoding
>>
>>
>> For all purposes related to NMU_DATA (filter construction, querying, and
>> the exclusion list), an outpoint (txid, vout) is encoded as a fixed 36-byte
>> key.
>>
>>
>> txid_le (bytes 0–31): the 32-byte transaction ID in little-endian order,
>> matching the internal uint256 representation used by Bitcoin Core and
>> similar implementations.
>>
>> vout_le (bytes 32–35): 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 serialization
>>
>>
>> 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_snap.
>> -
>>
>> SNAP_HASH (32 bytes): block hash at H_snap (must match
>> SNAP_BLOCK_HASH from section §2.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 Filter data.
>> -
>>
>> FP_COUNT (4 bytes): number of false-positive entries.
>> -
>>
>> FP_ENTRIES (FP_COUNT × 36 bytes): lexicographically sorted array of
>> canonical 36-byte outpoint encodings that are not in NMUSet_snap but would
>> otherwise match the filter.
>> -
>>
>> CHECKSUM (32 bytes): SHA256d of all preceding bytes from MAGIC
>> through the last FP_ENTRY.
>>
>>
>> The SHA256d of the entire NMU_DATA blob is called NMU_DATA_HASH and is
>> treated as a consensus constant compiled into node software.
>>
>>
>> A node MUST NOT enforce the NMU consensus rule unless NMU_DATA passes its
>> 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
>> fingerprints, giving an approximate false-positive 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 “probably present”.
>>
>>
>> The exact mapping from a 36-byte key to three positions and an 8-bit
>> fingerprint, and the interpretation of FILTER_DATA, MUST follow a single,
>> fully specified algorithm (for example, a pinned “binary fuse filter”
>> 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 list
>>
>>
>> Because the Binary Fuse Filter is probabilistic, some UTXOs that are not
>> in NMUSet_snap will still be reported as present at H_snap. During snapshot
>> construction, the false positive exclusion list FP_EXCLUDE is computed by
>> enumerating all UTXOs at H_snap that are not in NMUSet_snap, testing each
>> with 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’s
>> canonical key appears in FP_EXCLUDE, that 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, vout), with value(u) and height(u),
>> 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
>> 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
>> greater than or equal to VALUE_MAX_NMU, is_nmu(u) is false.
>>
>>
>> For the remaining UTXOs, the node computes key = canonical_encode(txid,
>> vout) using the 36-byte 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. Otherwise, the node queries the Binary Fuse Filter with
>> key. If and only if the filter reports the key as present, is_nmu(u) is
>> true.
>>
>>
>> Within the domain H_min_NMU ≤ height(u) ≤ H_snap and value(u) <
>> VALUE_MAX_NMU, this predicate exactly matches membership in NMUSet_snap:
>> every UTXO in NMUSet_snap is reported as NMU, and every UTXO outside
>> NMUSet_snap is reported as 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 §2.4 holds and NMU_DATA has been successfully
>> 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, vout) such that the corresponding UTXO u satisfies is_nmu(u) = true
>> as defined in §3.3.5 (equivalently, has NMU = 1).
>>
>>
>> Formally, when validating a transaction input:
>>
>>
>>
>> -
>>
>> Let (txid, vout) be the input outpoint.
>>
>>
>>
>> -
>>
>> Let u = Coin(txid, vout) be the referenced UTXO as seen by the node
>> at the time of validation.
>>
>>
>>
>> -
>>
>> If u does not exist: reject as usual (unchanged behavior).
>>
>>
>>
>> -
>>
>> Otherwise, if is_nmu(u) = true, then the transaction MUST be rejected
>> as invalid.
>>
>>
>> This rule applies:
>>
>>
>>
>> -
>>
>> To mempool acceptance.
>>
>>
>>
>> -
>>
>> To block validation.
>>
>>
>>
>> -
>>
>> To all future reorg scenarios, provided the snapshot commitment in
>> §2.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) = true (or NMU = 1) as
>> non-existent for the purpose of:
>>
>>
>>
>> -
>>
>> Satisfying transaction inputs (they can never be used).
>>
>>
>>
>> -
>>
>> Fee calculations, coin selection, wallet balances, etc.
>>
>>
>> 5.2 Physical pruning (optional)
>>
>>
>> Nodes that operate with -prune=1 (or similar backwards-compatible pruning
>> configuration) MAY:
>>
>>
>>
>> -
>>
>> Omit NMUs from the on-disk UTXO set.
>>
>>
>>
>> -
>>
>> Remove any previously persisted NMUs during a compaction / cleanup
>> pass by running is_nmu(u) on each UTXO and deleting those that return true.
>>
>>
>> This proposal does not require pruned nodes to discard raw historical
>> blocks. It only authorizes pruning of UTXO entries that are permanently
>> unspendable due to the NMU rule.
>>
>>
>> Non-pruned nodes (full archival nodes) MAY continue to store historical
>> blocks and full transaction data as usual. This preserves archival access
>> to inscription / stamp data while still neutralizing it economically.
>>
>>
>> Rationale
>>
>>
>> This BIP makes minimal changes to the consensus surface. It adds no new
>> opcodes and does not expand Bitcoin’s scripting language or
>> programmability. Instead, it introduces a single new consensus concept: a
>> binary classification that marks some existing UTXOs as permanently
>> unspendable Non-Monetary UTXOs (NMUs). In that sense, it is closer to a
>> one-time reclassification of a subset of UTXOs than an ongoing change to
>> Bitcoin’s 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 are specified and pinned by commit so that their
>> behavior is deterministic. The NMU set is defined in terms of chain data as
>> seen through these specified indexers, rather than as an arbitrary
>> hard-coded list of UTXOs. This keeps the consensus rule grounded in
>> chain-derived information while avoiding the need to embed inscription
>> 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
>> pinned commit) can see at the snapshot height H_snap, this proposal
>> neutralizes the existing inscription and stamp economy on day one without
>> importing evolving, open-ended classification rules into consensus. It
>> treats the snapshot as a fixed historical boundary and leaves future NMU
>> formats and mitigation strategies as a separate question for policy or for
>> future BIPs. If further action is desired on post-snapshot NMU formats, the
>> community can consider additional updates or separate proposals 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
>> structure 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
>> order of 50 million, the filter occupies roughly 9 bits per element (≈ 56
>> MB), and the exclusion list adds around 15–20 MB before compression, for an
>> uncompressed size on the order of 70–80 MB and an expected compressed size
>> of roughly 40–50 MB.
>>
>>
>> This is small relative to typical UTXO set sizes and to the on-disk
>> savings from pruning tens of millions 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.
>>
>>
>> Censorship resistance and scope
>>
>>
>> Bitcoin’s censorship resistance is primarily concerned with the ability
>> to move monetary value without trusted intermediaries. This proposal
>> intentionally targets non-monetary uses of the chain (inscriptions, stamps,
>> 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
>> arbitrary 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 from users,
>> miners, and economic nodes. In other words, this mechanism does not lower
>> the technical or social barriers to censoring ordinary monetary activity;
>> any such censorship would still require its own explicit, contentious
>> 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-monetary artifact at
>> H_snap, (b) dust-sized, below the VALUE_MAX_NMU threshold, and (c) within
>> the defined height window. The intent is that no ordinary monetary UTXOs
>> fall into NMUSet_snap; any such inclusion would be treated as an error in
>> the snapshot construction and grounds to regenerate NMU_DATA before
>> activation, not as an acceptable trade-off. The 1,000-sat value limit
>> serves as an additional hard guardrail against accidentally classifying
>> normally-sized wallet outputs.
>>
>>
>> Centralization and trust model for NMU generation
>>
>>
>> Anyone can independently generate the list of NMUs. It is incumbent 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 open the
>> targeted data protocols are.
>>
>>
>> It is valid to worry that fewer than 100% of node runners will regenerate
>> the NMU list themselves, somewhat increasing the overall trust placed in
>> third parties compared to today. However, this concern applies specifically
>> to a “blacklist of UTXOs,” which is precisely the area where scrutiny is
>> highest. That scrutiny should help ensure that enough independent parties
>> index and attest to the contents of NMUSet_snap to exceed any reasonable
>> threshold of credulity.
>>
>>
>> A useful analogy 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 exist for Bitcoin to maintain decentralization in practice.
>> This is an aspect of trust inherent in Bitcoin: we accept some technical
>> limitations of users and employ a practical, trust-minimized workaround
>> that, while not perfect, is better than the alternative.
>>
>>
>> If there were to be an issue with widely used binaries, it would become
>> ubiquitously known very quickly. Similarly, if The Cat were flawed and
>> began targeting monetary UTXOs, this would be detected well before
>> activation, and the necessary fixes applied, with any distortion of its
>> motivation exposed and corrected.
>>
>>
>> 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.
>> As with any soft fork, activation requires clear opt-in from miners and
>> from economic nodes. After activation, miners and other block proposers
>> must avoid including transactions that spend NMUs, because such blocks will
>> be rejected by upgraded nodes. Wallets and applications that track
>> inscriptions, BRC-20 assets, and related schemes will observe that NMUs
>> become permanently unspendable under The Cat and that balances associated
>> 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, or to understand their rules in detail. Those indexers are cited as
>> normative references for the inscription and stamp classification logic
>> used to derive NMUSet_snap. In practice, nodes only need the canonical
>> 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
>> 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
>> are NMUs?
>>
>>
>> This BIP does not re-specify the full Ord and Stamps protocols, but in
>> broad terms:
>>
>>
>> Ord 0.24.0 (inscriptions).
>>
>> According to the classification rules implemented in Ord 0.24.0 at commit
>> 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is scanned for
>> “inscription envelopes” in Taproot script paths. An inscription envelope is
>> an OP_FALSE OP_IF … OP_ENDIF block containing data 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, each recognized inscription
>> is associated with a particular outpoint (txid, vout) (typically the first
>> satoshi of a reveal transaction input, or as directed by the pointer field
>> in the protocol). OrdNMUSet is defined as the set 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
>> STAMP:-prefixed base64 string in the description field, which encodes image
>> data. The Stamps rules then map this metadata to specific dust-sized bare
>> multisig outputs in the underlying Bitcoin transactions. When those rules
>> are applied to the best chain up to height H_snap, each recognized stamp is
>> associated with one or more outpoints (txid, vout). StampsNMUSet is defined
>> as the set of outpoints that this reference Stamps implementation would
>> classify as containing such stamp-style embedded assets at H_snap.
>>
>>
>> Won’t spammers just make workarounds and spam anyway?
>>
>>
>> The Cat targets the financial incentive to create spam. It is almost
>> impossible to stop a determined user from adding data to Bitcoin. The more
>> realistic mitigation is to remove the ability to reliably trade these
>> embedded assets as if they were durable, on-chain economic objects. Once
>> the existing inscription and stamp 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.
>>
>>
>> Can’t 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 outputs. It would be
>> extremely costly, in aggregate fees, to move them all. If large-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 “rare sats”? Won’t those get “Catted”?
>>
>>
>> In this BIP, “rare sats” can be understood as satoshis that Ord and
>> similar indexers are treating as non-monetary artifacts. The Cat does not
>> look at individual sat numbers or “rarity” directly; it only classifies
>> whole UTXOs via the is_nmu(u) predicate, using NMUSet_snap and a simple
>> value/height guardrail.
>>
>>
>> A UTXO can only be classified as an NMU if all of the following are true:
>>
>>
>>
>> -
>>
>> it falls inside the NMU height window,
>>
>>
>>
>> -
>>
>> its value is strictly below VALUE_MAX_NMU (currently 1,000 sats), and
>>
>>
>>
>> -
>>
>> its outpoint appears in NMUSet_snap as identified by Ord/Stamps at
>> the snapshot.
>>
>>
>> Anything at or above VALUE_MAX_NMU is always treated as a normal monetary
>> output, regardless of what Ord says about the sats inside it.
>>
>>
>> In practice, if you once interacted with Ord and those “rare sats” now
>> live inside a normal-sized wallet UTXO (1,000 sats or more), this proposal
>> does not touch that UTXO at all. It remains fully spendable under the
>> ordinary rules. The only “rare sats” that get Catted are those deliberately
>> parked in tiny dust outputs below the VALUE_MAX_NMU threshold, and that 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 fence
>> off from the monetary UTXO set.
>>
>>
>> --
>> 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
>> email to bitcoindev+...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/32f8c689-314d-4a5e-9af6-2e3e704582e6n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/32f8c689-314d-4a5e-9af6-2e3e704582e6n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c541315d-a3d1-4416-9bf4-77f1f7d8f12en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 137297 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] The Cat, BIP draft discussion.
[not found] ` <CAAS2fgRR77nZj3-rJo70dnxe8Lma88-C9JqdVTYfXGHRgFu3pA@mail.gmail.com>
2025-12-11 20:54 ` [bitcoindev] The Cat, BIP draft discussion Bitcoin Mechanic
@ 2025-12-12 1:49 ` TwoLargePizzas
2025-12-13 15:02 ` Greg Maxwell
1 sibling, 1 reply; 20+ messages in thread
From: TwoLargePizzas @ 2025-12-12 1:49 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 46081 bytes --]
> 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 significantly reduce these
types of transactions going forward. That's not a one time reduction and
it's certainly not negligible.
> Were such a proposal seriously advanced it would likely cause a new
flood of 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
transactions to move elsewhere. If the "marketing opportunity" for the NFT
grifters is to say the transactions could be worthless going forward, then
yes, I agree.
> NFTs are just an imaginary parallel world that don't depend on the
network to validate their activity, so they don't really care about the
network's rules, and as such the network's rules have pretty limited
effect.
If the rules don't matter, they won't be bothered if the rules change.
> the proposal would intentionally and knowingly confiscate millions of
dollars in funds. This is outright theft, and I believe it makes the idea
a total non-starter.
When you say "millions of dollars 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 little contradictory to call NFTs an
imaginary in one breath and worth millions 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 comes from.
To me this proposal is more about sending a message that UTXO bloat is not
welcome. I don't agree with direct confiscation of funds but at the same
time I hold the position that encouraging the NFT grifters is only going to
lead to more NFT gifters.
On Friday, 12 December 2025 at 1:30:56 am UTC+10 Greg Maxwell wrote:
> You misunderstood my message that you've quoted-- understandable because
> today Bitcoin usage today is very different than back then. In September
> 2013 the average bitcoin blocksize was 120 kbytes and, as a result, there
> was no meaningful market competition for block space at the time. As a
> result there was essentially no incentive to minimize data usage in
> transactions and there was fairly little awareness of the potential means
> to do so, beyond simple limits like things not relaying. The situation
> today is entirely different: Techniques to minimize usage are well
> understood, widely deployed, and the cost of storing data that way is very
> high so none happens except by those who are very motivated and financially
> capable (and that 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 their
> tokens).
>
> On your proposal,
>
> The proposed gain is some negligible one time reduction in utxo disk
> space. You motivated it by claiming this is a 'memory usage' reduction, but
> it's not-- it's just full node storage in particular as the txouts in
> question are normally sized and largely quiescent already-- so the savings
> is pretty insignificant. Were such a proposal seriously 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 marketing opportunity for the NFT
> gifters). NFTs are just an imaginary parallel world that don't depend on
> the network to validate their activity, so they don't really care about the
> network's rules, and as such the network's rules have pretty limited
> effect.
>
> And moreover the proposal would intentionally and knowingly confiscate
> millions of dollars in funds. 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's a disrespectful waste of participants time to advance a proposal at
> such length and technobabbly depth 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 making
> spending them consensus invalid?" or similar. Much 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 obscure 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 PM Claire Ostrom <ostromcl...@gmail.com>
> 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 brief
>> history of the problem; please skip to “The BIP” below 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
>> design with no single authority maintaining its operation, we have to rely
>> on incentives and culture for network stewardship. Historically, we saw
>> many trends emerge which threatened Bitcoin’s primary use as a monetary
>> network. They were successfully dealt with by introducing OP_Return with a
>> small limit 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 and, importantly, not pollute the UTXO set.
>>
>> Legendary Bitcoin developer Gregory Maxwell said at the time, “Part of
>> the idea here is shaping behavior towards conservative needs.”
>> <https://github.com/bitcoin/bitcoin/pull/2738#issuecomment-25017368>
>>
>> This was enforced through standardness filters, which are a way of
>> discouraging certain types of transactions that, while technically
>> consensus valid, we have agreed as a community are usually not used in
>> standard practice and are potentially harmful.
>>
>> In recent years, these trends have come back into focus with the creation
>> of schemes like Ordinal theory and its associated inscriptions, and Bitcoin
>> Stamps, which are techniques for embedding non-monetary data (like images
>> or tokens) into Bitcoin transactions. Ordinals typically hide data in the
>> Taproot witness field (benefiting from a weight “discount”), while Stamps
>> encode data in unspendable outputs (e.g., fake bare multisig addresses).
>> These practices turn the blockchain into a data storage system rather than
>> purely a payments network. As anyone familiar with basic economics knows,
>> what you subsidize, you get more of.
>>
>> Critically, many Ordinal inscription and Stamp transactions create dust
>> outputs (tiny UTXOs of only a few hundred sats) that remain unspent
>> indefinitely, bloating the UTXO set. Because Stamp outputs are expected to
>> remain unspent indefinitely, they persist in the UTXO set forever.
>>
>> Veteran Bitcoin developer Mark “Murch” Erhardt has described the stamps
>> UTXO issue as “probably, from a technical perspective, one of the more
>> egregious uses of blockchain."
>> <https://bitcoinops.org/en/podcast/2023/12/21/>
>>
>> [image: Screenshot 2025-12-01 212654.png]
>>
>> Over roughly 14 years (2009-early 2023), Bitcoin’s UTXO set grew
>> gradually to around 80-90 million 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 to Ordinal inscriptions. Nearly
>> half of all UTXOs (around 49%) now contain less than 1,000 satoshis,
>> strongly indicating they are spammy dust outputs used for data embedding
>> rather than normal economic activity. Many of these are Taproot outputs or
>> outputs sitting exactly at the standard dust threshold, consistent with
>> algorithmic spam creation. In short, UTXO spam now accounts for tens of
>> millions of entries and represents an unprecedented explosion of UTXO bloat.
>>
>> The UTXO database (chainstate) has ballooned 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 Ordinals and BRC-20 mania. Over the
>> same period, the full blockchain grew by about 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, must remain in the chainstate until
>> it is spent or explicitly removed by a protocol 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 under current rules.
>>
>> Bitcoin’s design includes some anti-spam measures, but spammers have
>> continually evolved “cat-and-mouse” tactics to bypass them.
>>
>> This is where our proposal comes in.
>>
>> THE BIP: The Cat.
>>
>>
>> Recent attempts to reduce spam have focused on the supply side, trying to
>> stop spam through policy and standardness rules. These efforts have had
>> limited success. The Cat instead looks to economics, removing or reducing
>> the financial incentive for creating spam outputs in the first place. It
>> targets the demand side by making designated Non-Monetary UTXOs (NMUs)
>> permanently unspendable, which in turn reduces market demand for those
>> assets.
>>
>>
>> The Cat defines a fixed, reproducible set of “NMUs” using established
>> external indexers, and makes them permanently unspendable by consensus, so
>> that such data cannot be monetized or transacted, only archived. Once
>> rendered unspendable, we will be removing these UTXOs made unspendable by
>> consensus under this proposal, from the UTXO set, materially reducing the
>> current resource 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 plus a false-positive exclusion list) that ships with
>> the binary and does not require any node to reindex or re-download the
>> chain.
>>
>>
>>
>> Draft Specification
>>
>>
>> Status: Discussion draft. A formal BIP, compliant with BIP 0003 and the
>> usual BIP process, will be prepared if there is interest in pursuing this
>> direction.
>>
>>
>> 1. Definitions
>>
>>
>> Non-Monetary UTXO (NMU):
>>
>>
>> A UTXO that is classified as containing inscription-style or stamp-style
>> data according to the procedure in §2 and that satisfies the value and
>> creation-height constraints below.
>>
>>
>> NMU bit:
>>
>>
>> A single Boolean flag (0 or 1) stored alongside each UTXO in the node’s
>> UTXO database:
>>
>>
>>
>> -
>>
>> NMU = 1 -> UTXO is non-monetary and may not be spent.
>>
>>
>>
>> -
>>
>> NMU = 0 -> UTXO is monetary (normal behavior).
>>
>>
>> Conceptually, NMU = 1 means “this outpoint is in NMUSet_snap as defined
>> by this BIP.” Implementations MAY choose to compute this bit on the fly
>> from the membership structure rather than store it explicitly; see §3.
>>
>>
>> NMU value threshold:
>>
>>
>> A consensus constant VALUE_MAX_NMU = 1000 satoshis. Only UTXOs with value
>> strictly less than VALUE_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 = 0) for all time under this BIP, even if external tools
>> associate inscriptions or stamps with some of their satoshis.
>>
>>
>> NMU creation-height window:
>>
>>
>> This proposal intentionally restricts NMU classification to UTXOs created
>> between:
>>
>>
>> H_min_NMU: the earliest block height at which the reference indexers (Ord
>> 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 §2.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 = 0) regardless of filter results.
>>
>>
>> NMU membership structure (NMU_DATA):
>>
>>
>> A static, exact membership structure that encodes NMUSet_snap using:
>>
>>
>>
>> -
>>
>> A Binary Fuse 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 binary blob, together with a
>> consensus constant NMU_DATA_HASH = SHA256d(NMU_DATA) which all compliant
>> implementations MUST verify before using it for consensus validation (see
>> §3.3).
>>
>>
>> Activation height (H_cat):
>>
>>
>> A consensus constant H_cat, the block height at which the NMU spending
>> rule in §4 first becomes eligible for enforcement. The exact value and
>> deployment mechanism for H_cat are out of scope for this draft and would be
>> specified in a formal BIP.
>>
>>
>> 2. NMU classification (reproducible list)
>>
>>
>> The normative consensus object introduced by this BIP is the set
>> NMUSet_snap: a fixed set of outpoints classified as non-monetary at
>> snapshot height H_snap on the best chain, after applying the value and
>> height restrictions in §1 and §2.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 particular node
>> obtained that set.
>>
>>
>> To define NMUSet_snap in a precise and reproducible way, this BIP
>> specifies two reference classification rule sets that operate purely on
>> Bitcoin chain data, as implemented in:
>>
>>
>>
>> -
>>
>> Ord 0.24.0 at commit 5d2fbbe64b362cd6c30d6901e50cbe80084761f8
>>
>>
>>
>> -
>>
>> Stamps - [exact version/commit to be pinned before any activation]
>>
>>
>> These reference implementations define the inscription-style and
>> stamp-style classification rules in terms of Bitcoin chain data. They are
>> cited here as normative descriptions of how to decide whether a given
>> outpoint carries an inscription or a stamp at height H_snap.
>>
>>
>> Implementations that wish to independently 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 or Stamps is not required for ordinary full-node operation
>> under this BIP; they are simply the canonical specification of the
>> classification logic.
>>
>>
>> This section uses the consensus constants H_cat, H_snap, and H_min_NMU as
>> defined in §1.
>>
>>
>> 2.1 Ord NMU set
>>
>>
>> According to the classification rules implemented in Ord 0.24.0 at commit
>> 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is parsed for
>> “inscription envelopes” and each recognized inscription is associated with
>> 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
>> rules are applied to the best chain up to H_snap, are classified as
>> carrying inscriptions at H_snap. Concretely, for each inscription that Ord
>> 0.24.0 would associate with a specific outpoint (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 “NMU” if they meet the value and height thresholds in §2.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 classification rules implemented in the specified BTC
>> Stamps indexer (version/commit TBD), Counterparty metadata and Bitcoin
>> transactions are parsed to identify “stamp-style” embedded assets and
>> associate them with one or more bare multisig outputs on the best chain at
>> height H_snap.
>>
>>
>> Define StampsNMUSet as the set of all outpoints that, when those Stamps
>> rules are applied 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 associate with a specific outpoint (txid, vout) on
>> that chain, that outpoint is included in StampsNMUSet.
>>
>>
>> As with Ord, an implementation may obtain StampsNMUSet either by running
>> the reference Stamps indexer or by independently implementing the same
>> 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 = OrdNMUSet ∪ StampsNMUSet
>>
>>
>> Apply both the NMU value threshold and the creation-height window:
>>
>>
>> NMUSet_snap = { u ∈ NMUSet_raw | value(u) < VALUE_MAX_NMU and H_min_NMU ≤
>> height(u) ≤ H_snap }
>>
>>
>> where value(u) is the number of satoshis in UTXO u, and height(u) is the
>> height of the block that created that UTXO.
>>
>>
>> Every UTXO in NMUSet_snap MUST be treated as having NMU = 1 under the new
>> consensus rule (see §4). Nodes MAY realize this either by pre-seeding an
>> NMU bit in their UTXO database or by computing it dynamically via the
>> membership query in §3.3.
>>
>>
>> Notes:
>>
>>
>> Running Ord or Stamps is only required for those who wish to
>> independently derive and verify NMUSet_snap; it is not a requirement for
>> ordinary full node operation under The Cat.
>>
>>
>> The value threshold is intended to avoid classifying large, mixed-use
>> UTXOs as NMUs when a small number of inscribed satoshis have been combined
>> with otherwise monetary funds.
>>
>>
>> Restricting to height(u) ≥ H_min_NMU reflects the historical fact that
>> these protocols appeared only after a certain point, and it trivially
>> avoids misclassification of very old UTXOs.
>>
>>
>> This proposal intentionally does not specify any new in-client
>> classification rule for discovering future NMU formats. It explicitly
>> targets non-monetary UTXOs identifiable via Ord 0.24.0 and Stamps at the
>> time of snapshot.
>>
>>
>> 2.4 Snapshot block commitment and reorg behaviour
>>
>>
>> This BIP commits to a specific chain history at the snapshot height
>> H_snap by introducing a new consensus constant:
>>
>>
>> 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 derived.
>>
>>
>> A node MUST only enforce the NMU consensus rule from §4 if, for its
>> 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’s current best chain, the block at height H_snap has a
>> different hash, the node MUST treat all UTXOs as monetary (NMU = 0) for the
>> purposes of consensus validation, and MUST NOT reject any transaction or
>> block on the basis of the NMU 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),
>> enforcement of The Cat is automatically disabled until and unless the best
>> chain once again has SNAP_BLOCK_HASH at height H_snap. Any desire to apply
>> NMU 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 activation
>>
>>
>> 3.1 NMU bit storage model
>>
>>
>> Consensus only cares about which UTXOs are NMU, not how the bit is stored
>> or computed. Implementations MAY:
>>
>>
>>
>> -
>>
>> Store the NMU bit as an extra bit in the UTXO database (e.g., in the
>> Coin structure).
>>
>>
>>
>> -
>>
>> Store NMUs in a separate structure keyed by outpoint.
>>
>>
>>
>> -
>>
>> Compute NMU on the fly at validation time using the NMU_DATA
>> membership structure from §3.3, optionally caching results.
>>
>>
>> The only consensus requirement is: given the same chain, compliant
>> implementations must converge on the same NMU classification for all UTXOs.
>> Conceptually, for a UTXO u with value(u) and height(u), NMU(u) is defined
>> as:
>>
>>
>>
>> -
>>
>> 1 if:
>>
>>
>>
>> -
>>
>> H_min_NMU ≤ height(u) ≤ H_snap, and
>>
>>
>>
>> -
>>
>> value(u) < VALUE_MAX_NMU, and
>>
>>
>>
>> -
>>
>> u ∈ NMUSet_snap (as tested via §3.3),
>>
>>
>>
>> -
>>
>> 0 otherwise.
>>
>>
>> 3.2 Activation
>>
>>
>> At activation height H_cat:
>>
>>
>> Nodes must have:
>>
>>
>>
>> -
>>
>> Fully validated the chain up to at least H_snap.
>>
>>
>>
>> -
>>
>> Loaded and verified NMU_DATA (see §3.3).
>>
>>
>> From the first block at or after H_cat for which the snapshot block
>> commitment condition in §2.4 holds, nodes MUST enforce the consensus rule
>> in §4, using the NMU classification defined above. No reindex or UTXO
>> rewrite is required for activation; NMU classification can be applied as an
>> overlay on top of the existing UTXO database.
>>
>>
>> Implementations MAY, as an optimization, perform a one-time pass over
>> their UTXO set after activation to:
>>
>>
>>
>> -
>>
>> Set Coin.NMU = 1 for all UTXOs that satisfy the NMU predicate; and/or
>>
>>
>>
>> -
>>
>> Physically delete such UTXOs from the UTXO database (see §5).
>>
>>
>> Such a pass is a local optimization and not required for 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 block download or reindex
>> the chain in order to enforce NMU classification. Instead, it commits to a
>> canonical membership structure NMU_DATA which encodes NMUSet_snap in a
>> compact form.
>>
>>
>> 3.3.1 Canonical outpoint encoding
>>
>>
>> For all purposes related to NMU_DATA (filter construction, querying, and
>> the exclusion list), an outpoint (txid, vout) is encoded as a fixed 36-byte
>> key.
>>
>>
>> txid_le (bytes 0–31): the 32-byte transaction ID in little-endian order,
>> matching the internal uint256 representation used by Bitcoin Core and
>> similar implementations.
>>
>> vout_le (bytes 32–35): 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 serialization
>>
>>
>> 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_snap.
>> -
>>
>> SNAP_HASH (32 bytes): block hash at H_snap (must match
>> SNAP_BLOCK_HASH from section §2.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 Filter data.
>> -
>>
>> FP_COUNT (4 bytes): number of false-positive entries.
>> -
>>
>> FP_ENTRIES (FP_COUNT × 36 bytes): lexicographically sorted array of
>> canonical 36-byte outpoint encodings that are not in NMUSet_snap but would
>> otherwise match the filter.
>> -
>>
>> CHECKSUM (32 bytes): SHA256d of all preceding bytes from MAGIC
>> through the last FP_ENTRY.
>>
>>
>> The SHA256d of the entire NMU_DATA blob is called NMU_DATA_HASH and is
>> treated as a consensus constant compiled into node software.
>>
>>
>> A node MUST NOT enforce the NMU consensus rule unless NMU_DATA passes its
>> 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
>> fingerprints, giving an approximate false-positive 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 “probably present”.
>>
>>
>> The exact mapping from a 36-byte key to three positions and an 8-bit
>> fingerprint, and the interpretation of FILTER_DATA, MUST follow a single,
>> fully specified algorithm (for example, a pinned “binary fuse filter”
>> 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 list
>>
>>
>> Because the Binary Fuse Filter is probabilistic, some UTXOs that are not
>> in NMUSet_snap will still be reported as present at H_snap. During snapshot
>> construction, the false positive exclusion list FP_EXCLUDE is computed by
>> enumerating all UTXOs at H_snap that are not in NMUSet_snap, testing each
>> with 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’s
>> canonical key appears in FP_EXCLUDE, that 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, vout), with value(u) and height(u),
>> 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
>> 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
>> greater than or equal to VALUE_MAX_NMU, is_nmu(u) is false.
>>
>>
>> For the remaining UTXOs, the node computes key = canonical_encode(txid,
>> vout) using the 36-byte 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. Otherwise, the node queries the Binary Fuse Filter with
>> key. If and only if the filter reports the key as present, is_nmu(u) is
>> true.
>>
>>
>> Within the domain H_min_NMU ≤ height(u) ≤ H_snap and value(u) <
>> VALUE_MAX_NMU, this predicate exactly matches membership in NMUSet_snap:
>> every UTXO in NMUSet_snap is reported as NMU, and every UTXO outside
>> NMUSet_snap is reported as 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 §2.4 holds and NMU_DATA has been successfully
>> 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, vout) such that the corresponding UTXO u satisfies is_nmu(u) = true
>> as defined in §3.3.5 (equivalently, has NMU = 1).
>>
>>
>> Formally, when validating a transaction input:
>>
>>
>>
>> -
>>
>> Let (txid, vout) be the input outpoint.
>>
>>
>>
>> -
>>
>> Let u = Coin(txid, vout) be the referenced UTXO as seen by the node
>> at the time of validation.
>>
>>
>>
>> -
>>
>> If u does not exist: reject as usual (unchanged behavior).
>>
>>
>>
>> -
>>
>> Otherwise, if is_nmu(u) = true, then the transaction MUST be rejected
>> as invalid.
>>
>>
>> This rule applies:
>>
>>
>>
>> -
>>
>> To mempool acceptance.
>>
>>
>>
>> -
>>
>> To block validation.
>>
>>
>>
>> -
>>
>> To all future reorg scenarios, provided the snapshot commitment in
>> §2.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) = true (or NMU = 1) as
>> non-existent for the purpose of:
>>
>>
>>
>> -
>>
>> Satisfying transaction inputs (they can never be used).
>>
>>
>>
>> -
>>
>> Fee calculations, coin selection, wallet balances, etc.
>>
>>
>> 5.2 Physical pruning (optional)
>>
>>
>> Nodes that operate with -prune=1 (or similar backwards-compatible pruning
>> configuration) MAY:
>>
>>
>>
>> -
>>
>> Omit NMUs from the on-disk UTXO set.
>>
>>
>>
>> -
>>
>> Remove any previously persisted NMUs during a compaction / cleanup
>> pass by running is_nmu(u) on each UTXO and deleting those that return true.
>>
>>
>> This proposal does not require pruned nodes to discard raw historical
>> blocks. It only authorizes pruning of UTXO entries that are permanently
>> unspendable due to the NMU rule.
>>
>>
>> Non-pruned nodes (full archival nodes) MAY continue to store historical
>> blocks and full transaction data as usual. This preserves archival access
>> to inscription / stamp data while still neutralizing it economically.
>>
>>
>> Rationale
>>
>>
>> This BIP makes minimal changes to the consensus surface. It adds no new
>> opcodes and does not expand Bitcoin’s scripting language or
>> programmability. Instead, it introduces a single new consensus concept: a
>> binary classification that marks some existing UTXOs as permanently
>> unspendable Non-Monetary UTXOs (NMUs). In that sense, it is closer to a
>> one-time reclassification of a subset of UTXOs than an ongoing change to
>> Bitcoin’s 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 are specified and pinned by commit so that their
>> behavior is deterministic. The NMU set is defined in terms of chain data as
>> seen through these specified indexers, rather than as an arbitrary
>> hard-coded list of UTXOs. This keeps the consensus rule grounded in
>> chain-derived information while avoiding the need to embed inscription
>> 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
>> pinned commit) can see at the snapshot height H_snap, this proposal
>> neutralizes the existing inscription and stamp economy on day one without
>> importing evolving, open-ended classification rules into consensus. It
>> treats the snapshot as a fixed historical boundary and leaves future NMU
>> formats and mitigation strategies as a separate question for policy or for
>> future BIPs. If further action is desired on post-snapshot NMU formats, the
>> community can consider additional updates or separate proposals 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
>> structure 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
>> order of 50 million, the filter occupies roughly 9 bits per element (≈ 56
>> MB), and the exclusion list adds around 15–20 MB before compression, for an
>> uncompressed size on the order of 70–80 MB and an expected compressed size
>> of roughly 40–50 MB.
>>
>>
>> This is small relative to typical UTXO set sizes and to the on-disk
>> savings from pruning tens of millions 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.
>>
>>
>> Censorship resistance and scope
>>
>>
>> Bitcoin’s censorship resistance is primarily concerned with the ability
>> to move monetary value without trusted intermediaries. This proposal
>> intentionally targets non-monetary uses of the chain (inscriptions, stamps,
>> 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
>> arbitrary 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 from users,
>> miners, and economic nodes. In other words, this mechanism does not lower
>> the technical or social barriers to censoring ordinary monetary activity;
>> any such censorship would still require its own explicit, contentious
>> 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-monetary artifact at
>> H_snap, (b) dust-sized, below the VALUE_MAX_NMU threshold, and (c) within
>> the defined height window. The intent is that no ordinary monetary UTXOs
>> fall into NMUSet_snap; any such inclusion would be treated as an error in
>> the snapshot construction and grounds to regenerate NMU_DATA before
>> activation, not as an acceptable trade-off. The 1,000-sat value limit
>> serves as an additional hard guardrail against accidentally classifying
>> normally-sized wallet outputs.
>>
>>
>> Centralization and trust model for NMU generation
>>
>>
>> Anyone can independently generate the list of NMUs. It is incumbent 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 open the
>> targeted data protocols are.
>>
>>
>> It is valid to worry that fewer than 100% of node runners will regenerate
>> the NMU list themselves, somewhat increasing the overall trust placed in
>> third parties compared to today. However, this concern applies specifically
>> to a “blacklist of UTXOs,” which is precisely the area where scrutiny is
>> highest. That scrutiny should help ensure that enough independent parties
>> index and attest to the contents of NMUSet_snap to exceed any reasonable
>> threshold of credulity.
>>
>>
>> A useful analogy 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 exist for Bitcoin to maintain decentralization in practice.
>> This is an aspect of trust inherent in Bitcoin: we accept some technical
>> limitations of users and employ a practical, trust-minimized workaround
>> that, while not perfect, is better than the alternative.
>>
>>
>> If there were to be an issue with widely used binaries, it would become
>> ubiquitously known very quickly. Similarly, if The Cat were flawed and
>> began targeting monetary UTXOs, this would be detected well before
>> activation, and the necessary fixes applied, with any distortion of its
>> motivation exposed and corrected.
>>
>>
>> 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.
>> As with any soft fork, activation requires clear opt-in from miners and
>> from economic nodes. After activation, miners and other block proposers
>> must avoid including transactions that spend NMUs, because such blocks will
>> be rejected by upgraded nodes. Wallets and applications that track
>> inscriptions, BRC-20 assets, and related schemes will observe that NMUs
>> become permanently unspendable under The Cat and that balances associated
>> 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, or to understand their rules in detail. Those indexers are cited as
>> normative references for the inscription and stamp classification logic
>> used to derive NMUSet_snap. In practice, nodes only need the canonical
>> 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
>> 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
>> are NMUs?
>>
>>
>> This BIP does not re-specify the full Ord and Stamps protocols, but in
>> broad terms:
>>
>>
>> Ord 0.24.0 (inscriptions).
>>
>> According to the classification rules implemented in Ord 0.24.0 at commit
>> 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is scanned for
>> “inscription envelopes” in Taproot script paths. An inscription envelope is
>> an OP_FALSE OP_IF … OP_ENDIF block containing data 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, each recognized inscription
>> is associated with a particular outpoint (txid, vout) (typically the first
>> satoshi of a reveal transaction input, or as directed by the pointer field
>> in the protocol). OrdNMUSet is defined as the set 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
>> STAMP:-prefixed base64 string in the description field, which encodes image
>> data. The Stamps rules then map this metadata to specific dust-sized bare
>> multisig outputs in the underlying Bitcoin transactions. When those rules
>> are applied to the best chain up to height H_snap, each recognized stamp is
>> associated with one or more outpoints (txid, vout). StampsNMUSet is defined
>> as the set of outpoints that this reference Stamps implementation would
>> classify as containing such stamp-style embedded assets at H_snap.
>>
>>
>> Won’t spammers just make workarounds and spam anyway?
>>
>>
>> The Cat targets the financial incentive to create spam. It is almost
>> impossible to stop a determined user from adding data to Bitcoin. The more
>> realistic mitigation is to remove the ability to reliably trade these
>> embedded assets as if they were durable, on-chain economic objects. Once
>> the existing inscription and stamp 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.
>>
>>
>> Can’t 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 outputs. It would be
>> extremely costly, in aggregate fees, to move them all. If large-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 “rare sats”? Won’t those get “Catted”?
>>
>>
>> In this BIP, “rare sats” can be understood as satoshis that Ord and
>> similar indexers are treating as non-monetary artifacts. The Cat does not
>> look at individual sat numbers or “rarity” directly; it only classifies
>> whole UTXOs via the is_nmu(u) predicate, using NMUSet_snap and a simple
>> value/height guardrail.
>>
>>
>> A UTXO can only be classified as an NMU if all of the following are true:
>>
>>
>>
>> -
>>
>> it falls inside the NMU height window,
>>
>>
>>
>> -
>>
>> its value is strictly below VALUE_MAX_NMU (currently 1,000 sats), and
>>
>>
>>
>> -
>>
>> its outpoint appears in NMUSet_snap as identified by Ord/Stamps at
>> the snapshot.
>>
>>
>> Anything at or above VALUE_MAX_NMU is always treated as a normal monetary
>> output, regardless of what Ord says about the sats inside it.
>>
>>
>> In practice, if you once interacted with Ord and those “rare sats” now
>> live inside a normal-sized wallet UTXO (1,000 sats or more), this proposal
>> does not touch that UTXO at all. It remains fully spendable under the
>> ordinary rules. The only “rare sats” that get Catted are those deliberately
>> parked in tiny dust outputs below the VALUE_MAX_NMU threshold, and that 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 fence
>> off from the monetary UTXO set.
>>
>>
>> --
>> 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
>> email to bitcoindev+...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/32f8c689-314d-4a5e-9af6-2e3e704582e6n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/32f8c689-314d-4a5e-9af6-2e3e704582e6n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2ebbf019-a562-427d-93af-b88f0cf5658an%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 129132 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [bitcoindev] Re: The Cat, BIP draft discussion.
[not found] <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com>
[not found] ` <CAAS2fgRR77nZj3-rJo70dnxe8Lma88-C9JqdVTYfXGHRgFu3pA@mail.gmail.com>
@ 2025-12-12 17:13 ` Jonathan Voss
2025-12-12 23:40 ` Greg Maxwell
1 sibling, 1 reply; 20+ messages in thread
From: Jonathan Voss @ 2025-12-12 17:13 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 40537 bytes --]
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
hand, are inherently spendable; freezing those outputs would be direct
confiscation, which is conceptually antithetical to the purpose of Bitcoin *per
se*. However, a transaction validation rule that requires that the number
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
unspendable Stamp outputs and the abusive spam Ordinal outputs; the latter
could be simplified by just specifying that any transaction containing an
input of less than 1,000 sats must have fewer outputs than inputs, greatly
reducing the complexity of the consensus change while still achieving
long-term UTXO set size reduction.
On Wednesday, December 10, 2025 at 1:12:31 PM 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 brief
> history of the problem; please skip to “The BIP” below 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
> design with no single authority maintaining its operation, we have to rely
> on incentives and culture for network stewardship. Historically, we saw
> many trends emerge which threatened Bitcoin’s primary use as a monetary
> network. They were successfully dealt with by introducing OP_Return with a
> small limit 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 and, importantly, not pollute the UTXO set.
>
> Legendary Bitcoin developer Gregory Maxwell said at the time, “Part of
> the idea here is shaping behavior towards conservative needs.”
> <https://github.com/bitcoin/bitcoin/pull/2738#issuecomment-25017368>
>
> This was enforced through standardness filters, which are a way of
> discouraging certain types of transactions that, while technically
> consensus valid, we have agreed as a community are usually not used in
> standard practice and are potentially harmful.
>
> In recent years, these trends have come back into focus with the creation
> of schemes like Ordinal theory and its associated inscriptions, and Bitcoin
> Stamps, which are techniques for embedding non-monetary data (like images
> or tokens) into Bitcoin transactions. Ordinals typically hide data in the
> Taproot witness field (benefiting from a weight “discount”), while Stamps
> encode data in unspendable outputs (e.g., fake bare multisig addresses).
> These practices turn the blockchain into a data storage system rather than
> purely a payments network. As anyone familiar with basic economics knows,
> what you subsidize, you get more of.
>
> Critically, many Ordinal inscription and Stamp transactions create dust
> outputs (tiny UTXOs of only a few hundred sats) that remain unspent
> indefinitely, bloating the UTXO set. Because Stamp outputs are expected to
> remain unspent indefinitely, they persist in the UTXO set forever.
>
> Veteran Bitcoin developer Mark “Murch” Erhardt has described the stamps
> UTXO issue as “probably, from a technical perspective, one of the more
> egregious uses of blockchain."
> <https://bitcoinops.org/en/podcast/2023/12/21/>
>
> [image: Screenshot 2025-12-01 212654.png]
>
> Over roughly 14 years (2009-early 2023), Bitcoin’s UTXO set grew gradually
> to around 80-90 million 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 to Ordinal inscriptions. Nearly half of all UTXOs
> (around 49%) now contain less than 1,000 satoshis, strongly indicating they
> are spammy dust outputs used for data embedding rather than normal economic
> activity. Many of these are Taproot outputs or outputs sitting exactly at
> the standard dust threshold, consistent with algorithmic spam creation. In
> short, UTXO spam now accounts for tens of millions of entries and
> represents an unprecedented explosion of UTXO bloat.
>
> The UTXO database (chainstate) has ballooned 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 Ordinals and BRC-20 mania. Over the
> same period, the full blockchain grew by about 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, must remain in the chainstate until
> it is spent or explicitly removed by a protocol 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 under current rules.
>
> Bitcoin’s design includes some anti-spam measures, but spammers have
> continually evolved “cat-and-mouse” tactics to bypass them.
>
> This is where our proposal comes in.
>
> THE BIP: The Cat.
>
>
> Recent attempts to reduce spam have focused on the supply side, trying to
> stop spam through policy and standardness rules. These efforts have had
> limited success. The Cat instead looks to economics, removing or reducing
> the financial incentive for creating spam outputs in the first place. It
> targets the demand side by making designated Non-Monetary UTXOs (NMUs)
> permanently unspendable, which in turn reduces market demand for those
> assets.
>
>
> The Cat defines a fixed, reproducible set of “NMUs” using established
> external indexers, and makes them permanently unspendable by consensus, so
> that such data cannot be monetized or transacted, only archived. Once
> rendered unspendable, we will be removing these UTXOs made unspendable by
> consensus under this proposal, from the UTXO set, materially reducing the
> current resource 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 plus a false-positive exclusion list) that ships with
> the binary and does not require any node to reindex or re-download the
> chain.
>
>
>
> Draft Specification
>
>
> Status: Discussion draft. A formal BIP, compliant with BIP 0003 and the
> usual BIP process, will be prepared if there is interest in pursuing this
> direction.
>
>
> 1. Definitions
>
>
> Non-Monetary UTXO (NMU):
>
>
> A UTXO that is classified as containing inscription-style or stamp-style
> data according to the procedure in §2 and that satisfies the value and
> creation-height constraints below.
>
>
> NMU bit:
>
>
> A single Boolean flag (0 or 1) stored alongside each UTXO in the node’s
> UTXO database:
>
>
>
> -
>
> NMU = 1 -> UTXO is non-monetary and may not be spent.
>
>
>
> -
>
> NMU = 0 -> UTXO is monetary (normal behavior).
>
>
> Conceptually, NMU = 1 means “this outpoint is in NMUSet_snap as defined by
> this BIP.” Implementations MAY choose to compute this bit on the fly from
> the membership structure rather than store it explicitly; see §3.
>
>
> NMU value threshold:
>
>
> A consensus constant VALUE_MAX_NMU = 1000 satoshis. Only UTXOs with value
> strictly less than VALUE_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 = 0) for all time under this BIP, even if external tools
> associate inscriptions or stamps with some of their satoshis.
>
>
> NMU creation-height window:
>
>
> This proposal intentionally restricts NMU classification to UTXOs created
> between:
>
>
> H_min_NMU: the earliest block height at which the reference indexers (Ord
> 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 §2.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 = 0) regardless of filter results.
>
>
> NMU membership structure (NMU_DATA):
>
>
> A static, exact membership structure that encodes NMUSet_snap using:
>
>
>
> -
>
> A Binary Fuse 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 binary blob, together with a consensus
> constant NMU_DATA_HASH = SHA256d(NMU_DATA) which all compliant
> implementations MUST verify before using it for consensus validation (see
> §3.3).
>
>
> Activation height (H_cat):
>
>
> A consensus constant H_cat, the block height at which the NMU spending
> rule in §4 first becomes eligible for enforcement. The exact value and
> deployment mechanism for H_cat are out of scope for this draft and would be
> specified in a formal BIP.
>
>
> 2. NMU classification (reproducible list)
>
>
> The normative consensus object introduced by this BIP is the set
> NMUSet_snap: a fixed set of outpoints classified as non-monetary at
> snapshot height H_snap on the best chain, after applying the value and
> height restrictions in §1 and §2.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 particular node obtained
> that set.
>
>
> To define NMUSet_snap in a precise and reproducible way, this BIP
> specifies two reference classification rule sets that operate purely on
> Bitcoin chain data, as implemented in:
>
>
>
> -
>
> Ord 0.24.0 at commit 5d2fbbe64b362cd6c30d6901e50cbe80084761f8
>
>
>
> -
>
> Stamps - [exact version/commit to be pinned before any activation]
>
>
> These reference implementations define the inscription-style and
> stamp-style classification rules in terms of Bitcoin chain data. They are
> cited here as normative descriptions of how to decide whether a given
> outpoint carries an inscription or a stamp at height H_snap.
>
>
> Implementations that wish to independently 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 or Stamps is not required for ordinary full-node operation
> under this BIP; they are simply the canonical specification of the
> classification logic.
>
>
> This section uses the consensus constants H_cat, H_snap, and H_min_NMU as
> defined in §1.
>
>
> 2.1 Ord NMU set
>
>
> According to the classification rules implemented in Ord 0.24.0 at commit
> 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is parsed for
> “inscription envelopes” and each recognized inscription is associated with
> 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
> rules are applied to the best chain up to H_snap, are classified as
> carrying inscriptions at H_snap. Concretely, for each inscription that Ord
> 0.24.0 would associate with a specific outpoint (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 “NMU” if they meet the value and height thresholds in §2.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 classification rules implemented in the specified BTC
> Stamps indexer (version/commit TBD), Counterparty metadata and Bitcoin
> transactions are parsed to identify “stamp-style” embedded assets and
> associate them with one or more bare multisig outputs on the best chain at
> height H_snap.
>
>
> Define StampsNMUSet as the set of all outpoints that, when those Stamps
> rules are applied 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 associate with a specific outpoint (txid, vout) on
> that chain, that outpoint is included in StampsNMUSet.
>
>
> As with Ord, an implementation may obtain StampsNMUSet either by running
> the reference Stamps indexer or by independently implementing the same
> 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 = OrdNMUSet ∪ StampsNMUSet
>
>
> Apply both the NMU value threshold and the creation-height window:
>
>
> NMUSet_snap = { u ∈ NMUSet_raw | value(u) < VALUE_MAX_NMU and H_min_NMU ≤
> height(u) ≤ H_snap }
>
>
> where value(u) is the number of satoshis in UTXO u, and height(u) is the
> height of the block that created that UTXO.
>
>
> Every UTXO in NMUSet_snap MUST be treated as having NMU = 1 under the new
> consensus rule (see §4). Nodes MAY realize this either by pre-seeding an
> NMU bit in their UTXO database or by computing it dynamically via the
> membership query in §3.3.
>
>
> Notes:
>
>
> Running Ord or Stamps is only required for those who wish to independently
> derive and verify NMUSet_snap; it is not a requirement for ordinary full
> node operation under The Cat.
>
>
> The value threshold is intended to avoid classifying large, mixed-use
> UTXOs as NMUs when a small number of inscribed satoshis have been combined
> with otherwise monetary funds.
>
>
> Restricting to height(u) ≥ H_min_NMU reflects the historical fact that
> these protocols appeared only after a certain point, and it trivially
> avoids misclassification of very old UTXOs.
>
>
> This proposal intentionally does not specify any new in-client
> classification rule for discovering future NMU formats. It explicitly
> targets non-monetary UTXOs identifiable via Ord 0.24.0 and Stamps at the
> time of snapshot.
>
>
> 2.4 Snapshot block commitment and reorg behaviour
>
>
> This BIP commits to a specific chain history at the snapshot height H_snap
> by introducing a new consensus constant:
>
>
> 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 derived.
>
>
> A node MUST only enforce the NMU consensus rule from §4 if, for its
> 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’s current best chain, the block at height H_snap has a
> different hash, the node MUST treat all UTXOs as monetary (NMU = 0) for the
> purposes of consensus validation, and MUST NOT reject any transaction or
> block on the basis of the NMU 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),
> enforcement of The Cat is automatically disabled until and unless the best
> chain once again has SNAP_BLOCK_HASH at height H_snap. Any desire to apply
> NMU 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 activation
>
>
> 3.1 NMU bit storage model
>
>
> Consensus only cares about which UTXOs are NMU, not how the bit is stored
> or computed. Implementations MAY:
>
>
>
> -
>
> Store the NMU bit as an extra bit in the UTXO database (e.g., in the
> Coin structure).
>
>
>
> -
>
> Store NMUs in a separate structure keyed by outpoint.
>
>
>
> -
>
> Compute NMU on the fly at validation time using the NMU_DATA
> membership structure from §3.3, optionally caching results.
>
>
> The only consensus requirement is: given the same chain, compliant
> implementations must converge on the same NMU classification for all UTXOs.
> Conceptually, for a UTXO u with value(u) and height(u), NMU(u) is defined
> as:
>
>
>
> -
>
> 1 if:
>
>
>
> -
>
> H_min_NMU ≤ height(u) ≤ H_snap, and
>
>
>
> -
>
> value(u) < VALUE_MAX_NMU, and
>
>
>
> -
>
> u ∈ NMUSet_snap (as tested via §3.3),
>
>
>
> -
>
> 0 otherwise.
>
>
> 3.2 Activation
>
>
> At activation height H_cat:
>
>
> Nodes must have:
>
>
>
> -
>
> Fully validated the chain up to at least H_snap.
>
>
>
> -
>
> Loaded and verified NMU_DATA (see §3.3).
>
>
> From the first block at or after H_cat for which the snapshot block
> commitment condition in §2.4 holds, nodes MUST enforce the consensus rule
> in §4, using the NMU classification defined above. No reindex or UTXO
> rewrite is required for activation; NMU classification can be applied as an
> overlay on top of the existing UTXO database.
>
>
> Implementations MAY, as an optimization, perform a one-time pass over
> their UTXO set after activation to:
>
>
>
> -
>
> Set Coin.NMU = 1 for all UTXOs that satisfy the NMU predicate; and/or
>
>
>
> -
>
> Physically delete such UTXOs from the UTXO database (see §5).
>
>
> Such a pass is a local optimization and not required for 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 block download or reindex
> the chain in order to enforce NMU classification. Instead, it commits to a
> canonical membership structure NMU_DATA which encodes NMUSet_snap in a
> compact form.
>
>
> 3.3.1 Canonical outpoint encoding
>
>
> For all purposes related to NMU_DATA (filter construction, querying, and
> the exclusion list), an outpoint (txid, vout) is encoded as a fixed 36-byte
> key.
>
>
> txid_le (bytes 0–31): the 32-byte transaction ID in little-endian order,
> matching the internal uint256 representation used by Bitcoin Core and
> similar implementations.
>
> vout_le (bytes 32–35): 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 serialization
>
>
> 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_snap.
> -
>
> SNAP_HASH (32 bytes): block hash at H_snap (must match SNAP_BLOCK_HASH
> from section §2.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 Filter data.
> -
>
> FP_COUNT (4 bytes): number of false-positive entries.
> -
>
> FP_ENTRIES (FP_COUNT × 36 bytes): lexicographically sorted array of
> canonical 36-byte outpoint encodings that are not in NMUSet_snap but would
> otherwise match the filter.
> -
>
> CHECKSUM (32 bytes): SHA256d of all preceding bytes from MAGIC through
> the last FP_ENTRY.
>
>
> The SHA256d of the entire NMU_DATA blob is called NMU_DATA_HASH and is
> treated as a consensus constant compiled into node software.
>
>
> A node MUST NOT enforce the NMU consensus rule unless NMU_DATA passes its
> 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
> fingerprints, giving an approximate false-positive 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 “probably present”.
>
>
> The exact mapping from a 36-byte key to three positions and an 8-bit
> fingerprint, and the interpretation of FILTER_DATA, MUST follow a single,
> fully specified algorithm (for example, a pinned “binary fuse filter”
> 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 list
>
>
> Because the Binary Fuse Filter is probabilistic, some UTXOs that are not
> in NMUSet_snap will still be reported as present at H_snap. During snapshot
> construction, the false positive exclusion list FP_EXCLUDE is computed by
> enumerating all UTXOs at H_snap that are not in NMUSet_snap, testing each
> with 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’s
> canonical key appears in FP_EXCLUDE, that 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, vout), with value(u) and height(u),
> 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
> 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
> greater than or equal to VALUE_MAX_NMU, is_nmu(u) is false.
>
>
> For the remaining UTXOs, the node computes key = canonical_encode(txid,
> vout) using the 36-byte 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. Otherwise, the node queries the Binary Fuse Filter with
> key. If and only if the filter reports the key as present, is_nmu(u) is
> true.
>
>
> Within the domain H_min_NMU ≤ height(u) ≤ H_snap and value(u) <
> VALUE_MAX_NMU, this predicate exactly matches membership in NMUSet_snap:
> every UTXO in NMUSet_snap is reported as NMU, and every UTXO outside
> NMUSet_snap is reported as 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 §2.4 holds and NMU_DATA has been successfully
> 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,
> vout) such that the corresponding UTXO u satisfies is_nmu(u) = true as
> defined in §3.3.5 (equivalently, has NMU = 1).
>
>
> Formally, when validating a transaction input:
>
>
>
> -
>
> Let (txid, vout) be the input outpoint.
>
>
>
> -
>
> Let u = Coin(txid, vout) be the referenced UTXO as seen by the node at
> the time of validation.
>
>
>
> -
>
> If u does not exist: reject as usual (unchanged behavior).
>
>
>
> -
>
> Otherwise, if is_nmu(u) = true, then the transaction MUST be rejected
> as invalid.
>
>
> This rule applies:
>
>
>
> -
>
> To mempool acceptance.
>
>
>
> -
>
> To block validation.
>
>
>
> -
>
> To all future reorg scenarios, provided the snapshot commitment in
> §2.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) = true (or NMU = 1) as
> non-existent for the purpose of:
>
>
>
> -
>
> Satisfying transaction inputs (they can never be used).
>
>
>
> -
>
> Fee calculations, coin selection, wallet balances, etc.
>
>
> 5.2 Physical pruning (optional)
>
>
> Nodes that operate with -prune=1 (or similar backwards-compatible pruning
> configuration) MAY:
>
>
>
> -
>
> Omit NMUs from the on-disk UTXO set.
>
>
>
> -
>
> Remove any previously persisted NMUs during a compaction / cleanup
> pass by running is_nmu(u) on each UTXO and deleting those that return true.
>
>
> This proposal does not require pruned nodes to discard raw historical
> blocks. It only authorizes pruning of UTXO entries that are permanently
> unspendable due to the NMU rule.
>
>
> Non-pruned nodes (full archival nodes) MAY continue to store historical
> blocks and full transaction data as usual. This preserves archival access
> to inscription / stamp data while still neutralizing it economically.
>
>
> Rationale
>
>
> This BIP makes minimal changes to the consensus surface. It adds no new
> opcodes and does not expand Bitcoin’s scripting language or
> programmability. Instead, it introduces a single new consensus concept: a
> binary classification that marks some existing UTXOs as permanently
> unspendable Non-Monetary UTXOs (NMUs). In that sense, it is closer to a
> one-time reclassification of a subset of UTXOs than an ongoing change to
> Bitcoin’s 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 are specified and pinned by commit so that their
> behavior is deterministic. The NMU set is defined in terms of chain data as
> seen through these specified indexers, rather than as an arbitrary
> hard-coded list of UTXOs. This keeps the consensus rule grounded in
> chain-derived information while avoiding the need to embed inscription
> 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
> pinned commit) can see at the snapshot height H_snap, this proposal
> neutralizes the existing inscription and stamp economy on day one without
> importing evolving, open-ended classification rules into consensus. It
> treats the snapshot as a fixed historical boundary and leaves future NMU
> formats and mitigation strategies as a separate question for policy or for
> future BIPs. If further action is desired on post-snapshot NMU formats, the
> community can consider additional updates or separate proposals 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
> structure 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
> order of 50 million, the filter occupies roughly 9 bits per element (≈ 56
> MB), and the exclusion list adds around 15–20 MB before compression, for an
> uncompressed size on the order of 70–80 MB and an expected compressed size
> of roughly 40–50 MB.
>
>
> This is small relative to typical UTXO set sizes and to the on-disk
> savings from pruning tens of millions 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.
>
>
> Censorship resistance and scope
>
>
> Bitcoin’s censorship resistance is primarily concerned with the ability to
> move monetary value without trusted intermediaries. This proposal
> intentionally targets non-monetary uses of the chain (inscriptions, stamps,
> 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
> arbitrary 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 from users,
> miners, and economic nodes. In other words, this mechanism does not lower
> the technical or social barriers to censoring ordinary monetary activity;
> any such censorship would still require its own explicit, contentious
> 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-monetary artifact at
> H_snap, (b) dust-sized, below the VALUE_MAX_NMU threshold, and (c) within
> the defined height window. The intent is that no ordinary monetary UTXOs
> fall into NMUSet_snap; any such inclusion would be treated as an error in
> the snapshot construction and grounds to regenerate NMU_DATA before
> activation, not as an acceptable trade-off. The 1,000-sat value limit
> serves as an additional hard guardrail against accidentally classifying
> normally-sized wallet outputs.
>
>
> Centralization and trust model for NMU generation
>
>
> Anyone can independently generate the list of NMUs. It is incumbent 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 open the
> targeted data protocols are.
>
>
> It is valid to worry that fewer than 100% of node runners will regenerate
> the NMU list themselves, somewhat increasing the overall trust placed in
> third parties compared to today. However, this concern applies specifically
> to a “blacklist of UTXOs,” which is precisely the area where scrutiny is
> highest. That scrutiny should help ensure that enough independent parties
> index and attest to the contents of NMUSet_snap to exceed any reasonable
> threshold of credulity.
>
>
> A useful analogy 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 exist for Bitcoin to maintain decentralization in practice.
> This is an aspect of trust inherent in Bitcoin: we accept some technical
> limitations of users and employ a practical, trust-minimized workaround
> that, while not perfect, is better than the alternative.
>
>
> If there were to be an issue with widely used binaries, it would become
> ubiquitously known very quickly. Similarly, if The Cat were flawed and
> began targeting monetary UTXOs, this would be detected well before
> activation, and the necessary fixes applied, with any distortion of its
> motivation exposed and corrected.
>
>
> 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.
> As with any soft fork, activation requires clear opt-in from miners and
> from economic nodes. After activation, miners and other block proposers
> must avoid including transactions that spend NMUs, because such blocks will
> be rejected by upgraded nodes. Wallets and applications that track
> inscriptions, BRC-20 assets, and related schemes will observe that NMUs
> become permanently unspendable under The Cat and that balances associated
> 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,
> or to understand their rules in detail. Those indexers are cited as
> normative references for the inscription and stamp classification logic
> used to derive NMUSet_snap. In practice, nodes only need the canonical
> 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
> 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
> are NMUs?
>
>
> This BIP does not re-specify the full Ord and Stamps protocols, but in
> broad terms:
>
>
> Ord 0.24.0 (inscriptions).
>
> According to the classification rules implemented in Ord 0.24.0 at commit
> 5d2fbbe64b362cd6c30d6901e50cbe80084761f8, witness data is scanned for
> “inscription envelopes” in Taproot script paths. An inscription envelope is
> an OP_FALSE OP_IF … OP_ENDIF block containing data 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, each recognized inscription
> is associated with a particular outpoint (txid, vout) (typically the first
> satoshi of a reveal transaction input, or as directed by the pointer field
> in the protocol). OrdNMUSet is defined as the set 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 STAMP:-prefixed
> base64 string in the description field, which encodes image data. The
> Stamps rules then map this metadata to specific dust-sized bare multisig
> outputs in the underlying Bitcoin transactions. When those rules are
> applied to the best chain up to height H_snap, each recognized stamp is
> associated with one or more outpoints (txid, vout). StampsNMUSet is defined
> as the set of outpoints that this reference Stamps implementation would
> classify as containing such stamp-style embedded assets at H_snap.
>
>
> Won’t spammers just make workarounds and spam anyway?
>
>
> The Cat targets the financial incentive to create spam. It is almost
> impossible to stop a determined user from adding data to Bitcoin. The more
> realistic mitigation is to remove the ability to reliably trade these
> embedded assets as if they were durable, on-chain economic objects. Once
> the existing inscription and stamp 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.
>
>
> Can’t 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 outputs. It would be
> extremely costly, in aggregate fees, to move them all. If large-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 “rare sats”? Won’t those get “Catted”?
>
>
> In this BIP, “rare sats” can be understood as satoshis that Ord and
> similar indexers are treating as non-monetary artifacts. The Cat does not
> look at individual sat numbers or “rarity” directly; it only classifies
> whole UTXOs via the is_nmu(u) predicate, using NMUSet_snap and a simple
> value/height guardrail.
>
>
> A UTXO can only be classified as an NMU if all of the following are true:
>
>
>
> -
>
> it falls inside the NMU height window,
>
>
>
> -
>
> its value is strictly below VALUE_MAX_NMU (currently 1,000 sats), and
>
>
>
> -
>
> its outpoint appears in NMUSet_snap as identified by Ord/Stamps at the
> snapshot.
>
>
> Anything at or above VALUE_MAX_NMU is always treated as a normal monetary
> output, regardless of what Ord says about the sats inside it.
>
>
> In practice, if you once interacted with Ord and those “rare sats” now
> live inside a normal-sized wallet UTXO (1,000 sats or more), this proposal
> does not touch that UTXO at all. It remains fully spendable under the
> ordinary rules. The only “rare sats” that get Catted are those deliberately
> parked in tiny dust outputs below the VALUE_MAX_NMU threshold, and that 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 fence
> off from the monetary UTXO set.
>
>
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e3658771-128f-4e45-9465-860baf466ee4n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 123547 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-12 17:13 ` [bitcoindev] " Jonathan Voss
@ 2025-12-12 23:40 ` Greg Maxwell
2025-12-13 3:54 ` Melvin Carvalho
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Greg Maxwell @ 2025-12-12 23:40 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98kurz@gmail.com> wrote:
> Since the Bitcoin Stamps outputs are already unspendable, it makes perfect
> sense to mark and drop them from the UTXO set.
There is no consensus change involved in not storing a provably unspendable
output, it's just an implementation detail with no interoperability
implications and doesn't need a BIP. Bitcoin core has long done so for
several types of unspendable outputs, e.g. outputs over 10kb and ones
starting with OP_RETURN.
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTjF_e5vLEzp672_jmF82jDUre0wcZKHB5my8kTdFOGgw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 1495 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-12 23:40 ` Greg Maxwell
@ 2025-12-13 3:54 ` Melvin Carvalho
2025-12-13 7:07 ` Ataraxia 009
2025-12-17 16:22 ` Jonathan Voss
2 siblings, 0 replies; 20+ messages in thread
From: Melvin Carvalho @ 2025-12-13 3:54 UTC (permalink / raw)
To: Greg Maxwell; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
so 13. 12. 2025 v 0:49 odesílatel Greg Maxwell <gmaxwell@gmail.com> napsal:
> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98kurz@gmail.com> wrote:
>
>> Since the Bitcoin Stamps outputs are already unspendable, it makes
>> perfect sense to mark and drop them from the UTXO set.
>
>
> There is no consensus change involved in not storing a provably
> unspendable output, it's just an implementation detail with no
> interoperability implications and doesn't need a BIP. Bitcoin core has
> long done so for several types of unspendable outputs, e.g. outputs over
> 10kb and ones starting with OP_RETURN.
>
Alternative to confiscation: what if miners simply required 100+ sats/vbyte
to include transactions spending inscription UTXOs?
>
> --
> 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
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTjF_e5vLEzp672_jmF82jDUre0wcZKHB5my8kTdFOGgw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTjF_e5vLEzp672_jmF82jDUre0wcZKHB5my8kTdFOGgw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKaEYh%2B9HFKVDXdkkgsBeW0aq7mWVvpzZ9iy%3DX8%2B%3D6t%2BiCswuA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2959 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-12 23:40 ` Greg Maxwell
2025-12-13 3:54 ` Melvin Carvalho
@ 2025-12-13 7:07 ` Ataraxia 009
2025-12-17 16:22 ` Jonathan Voss
2 siblings, 0 replies; 20+ messages in thread
From: Ataraxia 009 @ 2025-12-13 7:07 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
Yes there is no need to add consensus changes to filter out unspendable
outputs from the UTXO set, thats just a protocol upgrade.
The second point with the Ordinals:
Whether it's a transaction validation rule or not, what you're planning to
do is differentiate between utxos on a consensus level. Which is the worst
path that you could go down. This will break bitcoin more than any spam
ever will.
On Sat, Dec 13, 2025 at 5:19 AM Greg Maxwell <gmaxwell@gmail.com> wrote:
> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98kurz@gmail.com> wrote:
>
>> Since the Bitcoin Stamps outputs are already unspendable, it makes
>> perfect sense to mark and drop them from the UTXO set.
>
>
> There is no consensus change involved in not storing a provably
> unspendable output, it's just an implementation detail with no
> interoperability implications and doesn't need a BIP. Bitcoin core has
> long done so for several types of unspendable outputs, e.g. outputs over
> 10kb and ones starting with OP_RETURN.
>
> --
> 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
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTjF_e5vLEzp672_jmF82jDUre0wcZKHB5my8kTdFOGgw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTjF_e5vLEzp672_jmF82jDUre0wcZKHB5my8kTdFOGgw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAADX_vKftpgPfr7FgQGsQQ%2B6EtEdsZu-fUOWVq-ZQPoLoP8zkQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2981 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] The Cat, BIP draft discussion.
2025-12-12 1:49 ` TwoLargePizzas
@ 2025-12-13 15:02 ` Greg Maxwell
2025-12-14 1:51 ` Pepe Hodler
2025-12-15 10:35 ` Nona YoBidnes
0 siblings, 2 replies; 20+ messages in thread
From: Greg Maxwell @ 2025-12-13 15:02 UTC (permalink / raw)
To: TwoLargePizzas; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
On Sat, Dec 13, 2025 at 10:05 AM TwoLargePizzas <zarfius@gmail.com> wrote:
> If the rules don't matter, they won't be bothered if the rules change.
>
No, that kind of mutual exclusion is often not how things work and isn't
how they work here. They absolutely will be valued by this proposal
stealing their bitcoins, but their NFT grifting will not ultimately be
effected otherwise.
When you say "millions of dollars in funds" are you including the value of
> the NFTs tied to those sats
>
No, just the Bitcoin-- but you indirectly make a fine point that it
probably ought to be considered too. It's fine that you or I agree that
NFT crap isn't appropriate to bitcoin but those harmed aren't beholden to
your or my *opinion* and will absolutely seek redress through any and all
means for the damage caused to them.
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgR91F1-3HuQ16iVoT9XeyrFXtZ94_t6bWUL0QbLNRVhHw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2065 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] The Cat, BIP draft discussion.
2025-12-13 15:02 ` Greg Maxwell
@ 2025-12-14 1:51 ` Pepe Hodler
2025-12-15 10:35 ` Nona YoBidnes
1 sibling, 0 replies; 20+ messages in thread
From: Pepe Hodler @ 2025-12-14 1:51 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3422 bytes --]
>> The proposed gain is some negligible one time reduction in utxo disk
space.
The current UTXO set contains around 40-50% of dust outputs in spam UTXOs.
The Cat would remove all of them from the UTXO set. I hardly think that's
negligible. And The Cat would further signal to spammers we are no longer
tolerating them on bitcoin, which would further prevent future UTXO bloat.
>> Were such a proposal seriously 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
Yes indeed, that would not be convenient for spammers, which is the entire
point of The Cat. No one who is not a spammer would suffer.
>> And moreover the proposal would intentionally and knowingly confiscate
millions of dollars in funds.
Only spammy UTXOs with below dust limit sats would be affected. And that
you think it would result in millions of dollars lost to spammers speaks
volume to how bad a problem spam is becoming.
>> This is outright theft, and I believe it makes the idea a total
non-starter.
That is false. They would keep their precious spam intact on chain, they
just would not be able to move it or transfer it to anyone else, which
would severely diminish their profit incentives.
>> No, just the Bitcoin-- but you indirectly make a fine point that it
probably ought to be considered too.
I don't think we should be considering the value or price of this spam. I
don;t care if a jpeg is worth 1 cent or 1$ million, I don't want it on my
bitcoin. If spammers lose any profit, that's the entire point of The Cat.
>> It's fine that you or I agree that NFT crap isn't appropriate to bitcoin
but those harmed aren't beholden to your or my *opinion* and will
absolutely seek redress through any and all means for the damage caused to
them.
If you advocate that we should cater to spammers, and be 'nice' to them,
the problem will only get worth. Let them rage quit.
On Saturday, 13 December 2025 at 08:20:25 UTC-7 Greg Maxwell wrote:
> On Sat, Dec 13, 2025 at 10:05 AM TwoLargePizzas <zar...@gmail.com> wrote:
>
>> If the rules don't matter, they won't be bothered if the rules change.
>>
>
> No, that kind of mutual exclusion is often not how things work and isn't
> how they work here. They absolutely will be valued by this proposal
> stealing their bitcoins, but their NFT grifting will not ultimately be
> effected otherwise.
>
> When you say "millions of dollars in funds" are you including the value of
>> the NFTs tied to those sats
>>
>
> No, just the Bitcoin-- but you indirectly make a fine point that it
> probably ought to be considered too. It's fine that you or I agree that
> NFT crap isn't appropriate to bitcoin but those harmed aren't beholden to
> your or my *opinion* and will absolutely seek redress through any and all
> means for the damage caused to them.
>
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/46652fac-ca26-4103-8ce4-67356f21adcan%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4848 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] The Cat, BIP draft discussion.
2025-12-13 15:02 ` Greg Maxwell
2025-12-14 1:51 ` Pepe Hodler
@ 2025-12-15 10:35 ` Nona YoBidnes
2025-12-15 16:04 ` Greg Maxwell
1 sibling, 1 reply; 20+ messages in thread
From: Nona YoBidnes @ 2025-12-15 10:35 UTC (permalink / raw)
To: Greg Maxwell, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 5151 bytes --]
Hi Greg and list,
Techniques to minimize usage are well understood, widely deployed,
and the cost of storing data that way is very high so none happens
except by those who are very motivated and financially capable (and
that 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 their tokens).
Here, your argument runs completely opposite of the claim that "the
miner fees are the filter". You appear to be claiming that dping nothing
about spam, making it easier for spammers and being more accommodating
to them is the way to go. Unfortunately, that's the approach we have
taken for the last 3 years while spam only gets worst.
The reality is that making it harder, more costly, and less convenient
for spammers to keep going will result in less spam, not more. While
it's possible that the remaining spam might be valued higher by the
market, I don't really care about the price of spam, I only care to
reduce the amount of it, not the price. Less spam is the objective here.
I'm not concerned with the price of spam, only the quantity of spam.
You seem to approach spam like a bullied kid, afraid that if we fight
back against spam, the big mean spam bully might spam us harder. I can't
accept this kind of approach. Bitcoin requires and adversarial mindset,
not one of compliance and submission when faced with an attacker.
The proposed gain is some negligible one time reduction in utxo disk
space.
Between 40 and 50% of the UTXO set is comprised of spam UTXOs with dust
amounts. Even more conservative estimates put it at 30%. The Cat would
remove those spam NMUs from the UTXO set. I hardly view that as
negligible. Furthermore, The Cat would send a strong signal to spammers:
you are not welcomed on Bitcoin, we are rugging you, and we might do it
again. This likely would reduce future spam activity on Bitcoin, further
protecting the UTXO set.
Were such a proposal seriously 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 marketing opportunity for the NFT
gifters).
As Claire already explained, with millions of cases of spam, this would
cause a massive block space demand increase and a large fee spike which
would prove very costly to spammers. And retaking a new snapshot would
force them to do it again. Someone needs to feed the poor miners!
> NFTs are just an imaginary parallel world that don't depend on the
> network to validate their activity, so they don't really care about
> the network's rules, and as such the network's rules have pretty
> limited effect.
So here, you are saying The Cat would be noneffective at reducing spam.
> And moreover the proposal would intentionally and knowingly confiscate
> millions of dollars in funds.
You just finished telling us "the network rules have a pretty limited
effect" and now you tell us The Cat would result in the confiscation of
millions of dollars in funds. That sounds conflicting and contradictory
to me. Furthermore, dropping the spam UTXOs from the UTXO set would not
delete any spam, they still would have ownership of it, they just
wouldn't be able to sell it or transfer it to anyone else on L1.
Furthermore, those are all dust UTXOs. An unbelievably high amount of
them would have to be on chain to amount to "millions of dollars in
funds". This should give us a clue about the scale of the problem. I
hope you get on board with The Cat now, not in a few years when it will
be a much bigger problem in the billions of dollars in funds, not mere
millions.
> This is outright theft, and I believe it makes the idea a total
> non-starter.
Not confiscation, not theft, as they spam would remain on chain, they
simply would not be able to sell their spam on Bitcoin, therefore The
Cat would deincintivize them from profiting on Bitcoin. Furthermore,
they could opt to consolidate they multiple dust UTXOs and avoid losing
their bitcoin, prior to activation of The Cat.
> They absolutely will be valued by this proposal stealing their
> bitcoins, but their NFT grifting will not ultimately be effected
> otherwise.
If they lose "millions of dollars in funds" as you claim, thus making
their business must less profitable, I would call that a success, not
ineffective at all.
Thank you, I am the founder and CEO of Opsosoft S.A de S.V. , coder, and
bitcoiner since 2016.
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ae116ad9-1295-4220-891c-12ec9969ca05%40gmail.com.
[-- Attachment #2: Type: text/html, Size: 7893 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] The Cat, BIP draft discussion.
2025-12-15 10:35 ` Nona YoBidnes
@ 2025-12-15 16:04 ` Greg Maxwell
0 siblings, 0 replies; 20+ messages in thread
From: Greg Maxwell @ 2025-12-15 16:04 UTC (permalink / raw)
To: Nona YoBidnes; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 8747 bytes --]
On Mon, Dec 15, 2025 at 10:35 AM Nona YoBidnes <pepehodler@gmail.com> wrote:
> Here, your argument runs completely opposite of the claim that "the miner
> fees are the filter". You appear to be claiming that dping nothing about
> spam, making it easier for spammers and being more accommodating to them is
> the way to go. Unfortunately, that's the approach we have taken for the
> last 3 years while spam only gets worst.
>
On what basis do you claim that spam has 'only gotten worse'-- the
existing setup is incredibly effective against spam, essentially blocking
all forms of pointless data storage that aren't made more valuable by the
limitations. What does go in, goes in at extremely high costs to the
spammer.
Of what concern is this residual traffic to Bitcoin use? It doesn't
increase node resource use as that's governed by the capacity limits, in
fact because it's generally much easier to process it speeds up block
processing. It's substantially a non-issue.
The proposed gain is some negligible one time reduction in utxo disk space.
>
>
> Between 40 and 50% of the UTXO set is comprised of spam UTXOs with dust
> amounts. Even more conservative estimates put it at 30%. The Cat would
> remove those spam NMUs from the UTXO set. I hardly view that as negligible.
>
It is negligible-- it's just a one time constant fraction. It will not
increase the set of devices that can run a node in any meaningful sense.
What improvement it provides could also be alternatively achieved through
local only technical changes like changing how the data is stored.
Furthermore, The Cat would send a strong signal to spammers: you are not
> welcomed on Bitcoin, we are rugging you, and we might do it again. This
> likely would reduce future spam activity on Bitcoin, further protecting the
> UTXO set.
>
As I've pointed out, it won't stop their NFTs. They'll simply make a new
rule in their NFT indexers that says that deleted NFT X will be owned by
the first output created with the same (or cryptographically related)
scriptPubKey. Doing so will give them free press-- probably the most
valuable thing that could possibly be done for them--, cause them to make
additional txn, and send a message that their NFTs are _unblockable_
because they are.
Moreover, it would send a message to the whole world that your Bitcoin
aren't safe. That an angry mob might confiscate them from you if you
became unpopular enough in their eyes. That would be entirely at odds with
the ethos of Bitcoin-- Bitcoin is money for enemies. Your ownership of
Bitcoin shouldn't be up to popular vote-- if you're okay with money that
operates at popular whim then you're better off with the fiat of a major
democracy. Because of this this proposal just won't fly and this
discussion is a waste of time and energy that could be otherwise used to
actually improve Bitcoin.
> Were such a proposal seriously 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 marketing opportunity for the NFT gifters).
>
>
> As Claire already explained, with millions of cases of spam, this would
> cause a massive block space demand increase and a large fee spike which
> would prove very costly to spammers. And retaking a new snapshot would
> force them to do it again. Someone needs to feed the poor miners!
>
Existing data embedding traffic is already definitionally the tiny residual
interest which is not particularly price sensitive or they wouldn't be on
Bitcoin at all. In the case of NFTs the limitation makes their tokens more
valuable by creating a limited supply or an otherwise endless asset class.
"Claire"'s explanation is just false as it assumes they'd reembed the NFTs,
but there is no reason for them to do that as the existence of an NFT isn't
governed by Bitcoin's consensus rules but rather by the behavior of NFT
indexers-- and they don't pay any attention to the UTXO set at all but
rather watch the blockchain and maintain their own indexes. So post this
proposal when you want to transfer your 'deleted' NFT you simply make one
transaction paying your old scriptPubKey (or some related one, as per the
revised NFT spec) and then pay that output to the new owner-- the extra
cost to the NFT jockie is one extra in/out pair at their first transfer
post 'deletion'. And god knows they may find a way to even reduce that
further, my example is just the extremely obvious response and not whatever
improved idea someone would come up with after actually thinking about it.
> NFTs are just an imaginary parallel world that don't depend on the network
> to validate their activity, so they don't really care about the network's
> rules, and as such the network's rules have pretty limited effect.
>
> So here, you are saying The Cat would be noneffective at reducing spam.
>
> And moreover the proposal would intentionally and knowingly confiscate
> millions of dollars in funds.
>
>
> You just finished telling us "the network rules have a pretty limited
> effect" and now you tell us The Cat would result in the confiscation of
> millions of dollars in funds. That sounds conflicting and contradictory to
> me.
>
The consensus rules govern the operations of *bitcoins* not NFTs. This
proposal would delete their Bitcoins, based on the published figures (and
the percentages in your post) it would be confiscate on the order of 358
Bitcoin.
It wouldn't, however, confiscate their NFTs.
Furthermore, dropping the spam UTXOs from the UTXO set would not delete any
> spam, they still would have ownership of it, they just wouldn't be able to
> sell it or transfer it to anyone else on L1.
>
It would steal their Bitcoin's but leave them able to continue transferring
their NFTs.
> Furthermore, those are all dust UTXOs. An unbelievably high amount of them
> would have to be on chain to amount to "millions of dollars in funds".
>
Yes, but that is exactly what this proposal is claiming-- They're almost
all >=546 satoshi in value. There are 164 million txouts, you and the
proposals are saying 40-50% would be confiscated. Do the math.
If they lose "millions of dollars in funds" as you claim, thus making their
> business must less profitable, I would call that a success, not ineffective
> at all.
>
I hope you step back and think carefully about what you're saying here.
I, and many others, consider the aggressive anti-'spammers' to be a threat
to Bitcoin in a way that some NFT nuisance traffic could never be due to
the quick recourse to confiscation and censorship and the constant baiting
of government interference by proposing technical means for transaction
censorship and confiscation. Should I propose to confiscate the funds of
Opsosoft and Ocean Mining (and you personally, of course) in order to
discourage the continued efforts to screw with Bitcoin's central properties?
It would be much more effective against you than it is against the NFT
jockeys because at least the NFT degens would get to keep and continue to
trade their NFTs.
Fortunately for you (and everyone!) that just isn't how Bitcoin works:
confiscation proposals are non-starters. But it says something significant
about the level of derangement suffered by its advocates that someone had
to tell someone who isn't a total Bitcoin newbie that it was a non-starter.
You, presumably, do not consider yourself and your comrades a threat to
Bitcoin, but nor do the NFT degens. Such determinations are highly
subjective, and Bitcoins design and purpose was to minimize human judgement
over how people get to store and use their own coins. An inherent
consequence of that is that there will always be users and users we
strongly disapprove of personally. Having seen the alternative in dollars
and paypal and whatnot this is an acceptable cost.
We should all still feel empowered to fight that which we think harms the
world-- but the place for that kind of battle is outside of the Bitcoin
protocol. Bitcoin is valuable because it strives to eliminate third party
judgement from the ownership and usage by consenting parties.
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQLKD1-DomvniTHLTvw52yeaKmOG-K__TnZeYJ%2Bc2hYFA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 12167 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-12 23:40 ` Greg Maxwell
2025-12-13 3:54 ` Melvin Carvalho
2025-12-13 7:07 ` Ataraxia 009
@ 2025-12-17 16:22 ` Jonathan Voss
2025-12-19 3:31 ` Greg Maxwell
2 siblings, 1 reply; 20+ messages in thread
From: Jonathan Voss @ 2025-12-17 16:22 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1614 bytes --]
This is my third attempt to respond to this. Idk what is going wrong here.
The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without a
consensus change is that a clever use of steganography could cause one of
those otherwise unspendable outputs to be spendable, thus causing a fork
between those nodes that adopted the Stamp pruning method and those that
did not once one of those steganographic Stamps is spent. Though this is
unlikely, it is still technically possible, and I would not put it past the
denizens of the Internet to stir up trouble just for its own sake.
On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com> wrote:
>
>> Since the Bitcoin Stamps outputs are already unspendable, it makes
>> perfect sense to mark and drop them from the UTXO set.
>
>
> There is no consensus change involved in not storing a provably
> unspendable output, it's just an implementation detail with no
> interoperability implications and doesn't need a BIP. Bitcoin core has
> long done so for several types of unspendable outputs, e.g. outputs over
> 10kb and ones starting with OP_RETURN.
>
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2436 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-17 16:22 ` Jonathan Voss
@ 2025-12-19 3:31 ` Greg Maxwell
2025-12-21 5:07 ` John
0 siblings, 1 reply; 20+ messages in thread
From: Greg Maxwell @ 2025-12-19 3:31 UTC (permalink / raw)
To: Jonathan Voss; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3224 bytes --]
I received no prior response from you, so I suspect the issue is on your
end-- since if you sent one I would normally have been directly copied.
In any case, your message makes no sense. If an output is provably
unspendable then it is unspendable. No amount of "clever steganography"
can change that. If you're imagining that perhaps they are *presumed* to
be unspendable but actually *are* spendable, then sure that would be an
issue but with any change to consensus relevant code great care must be
taken to not introduce errors. Actually *making* a consensus change would
only increase the potential for mistakes.
These costs are just another reason why this hysteria over a non-issue is
misplaced.
But in any case it is better that (any) implementations that care about
stamps put in the effort to define their exclusions in ways that are safe
than to burden everyone with a consensus change that doesn't care about it.
On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98kurz@gmail.com> wrote:
> This is my third attempt to respond to this. Idk what is going wrong here.
>
> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without a
> consensus change is that a clever use of steganography could cause one of
> those otherwise unspendable outputs to be spendable, thus causing a fork
> between those nodes that adopted the Stamp pruning method and those that
> did not once one of those steganographic Stamps is spent. Though this is
> unlikely, it is still technically possible, and I would not put it past the
> denizens of the Internet to stir up trouble just for its own sake.
>
> On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
>
>> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com> wrote:
>>
>>> Since the Bitcoin Stamps outputs are already unspendable, it makes
>>> perfect sense to mark and drop them from the UTXO set.
>>
>>
>> There is no consensus change involved in not storing a provably
>> unspendable output, it's just an implementation detail with no
>> interoperability implications and doesn't need a BIP. Bitcoin core has
>> long done so for several types of unspendable outputs, e.g. outputs over
>> 10kb and ones starting with OP_RETURN.
>>
>> --
> 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
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSEX0dcg73qnrj5uP64Xaw%3Dukj7fhzng_1gT3BntjocNQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4529 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-19 3:31 ` Greg Maxwell
@ 2025-12-21 5:07 ` John
2025-12-23 19:12 ` Greg Maxwell
0 siblings, 1 reply; 20+ messages in thread
From: John @ 2025-12-21 5:07 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 13327 bytes --]
Good evening all,
Here is a related proposal by Matteo Pellegrini
@matteopelleg
Lynx.
Abstract
This proposal introduces a periodic, consensus-enforced mechanism for
rendering UTXOs below the network's dust threshold permanently unspendable.
At each halving block, UTXOs that have remained below the dust threshold
since the previous halving become unspendable. These UTXOs become
unspendable and may be pruned from the UTXO set entirely, reducing node
storage requirements and eliminating the economic model that incentivizes
their creation.
Motivation
The Bitcoin UTXO set has grown substantially due to various factors,
including inscription protocols, spam attacks, and general dust
accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO
Cleanup) by @ostrom72158
have attempted to address this by creating lists of specific UTXOs to
render unspendable, identified by external protocol indexers.
The Cat's approach has a fatal flaw: it relies on a list.
Using a curated list of "non-monetary UTXOs" introduces several problems:
1) External dependency: The Cat requires reference indexers (Ord, Stamps,
etc.) to define which UTXOs qualify. This introduces consensus-level
dependency on external, non-Bitcoin software that can change, have bugs, or
interpret protocols differently.
2) Protocol targeting: By specifically identifying inscription and stamp
outputs, the proposal makes subjective judgments about which Bitcoin uses
are legitimate. This sets a precedent for protocol-level discrimination.
3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes
workarounds. If Ordinals dust is targeted, protocols will adapt to create
dust that doesn't match the list criteria.
4) Static snapshot: A one-time list cleanup provides temporary relief but
does nothing for future UTXO accumulation.
5) Political vulnerability: Any list-based approach requires ongoing
governance decisions about what belongs on the list, creating a permanent
political attack surface.
A better approach targets the economic reality, not the use case.
UTXOs below the dust threshold are, by definition, economically irrational
to spend under normal fee conditions. The dust limit exists precisely
because spending these outputs costs more in fees than the output is worth.
These UTXOs are already "dead" in practice; this proposal simply makes that
reality explicit at the consensus layer.
By using a threshold rather than a list, Lynx:
- Requires no external indexers
- Makes no judgment about why a UTXO is small
- Applies equally to all participants
- Provides ongoing, predictable maintenance
- Removes political discretion from the process
Impact on Inscription Protocols
The typical Ordinals inscription is stored in a UTXO containing exactly 546
sats; the minimum required to meet the dust limit for P2PKH addresses and
ensure transferability across all address types. This "postage" amount is
standard across inscription tooling and marketplaces.
A threshold of 999 sats captures the vast majority of inscription UTXOs
without requiring any protocol-specific targeting. The economic model of
inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks
that model through neutral, threshold-based rules rather than list-based
discrimination.
Specification
Definitions
- Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is
subject to Lynx enforcement.
- Halving block: A block at height N * 210,000 where N ≥ 1.
- Snapshot block: A halving block at which the current dust threshold and
qualifying UTXOs are recorded.
- Enforcement block: The halving block following a snapshot block (i.e.,
snapshot block + 210,000 blocks).
Lynx UTXOs:
- Existed at the snapshot block
- Had a value less than 999 sats
- Remained unspent through the enforcement period (~4 years)
Consensus Rules
After activation, the following rules apply:
1) Snapshot: At each halving block H, record the set of all UTXOs with
value < 999 sats.
2) Enforcement: At halving block H + 210,000:
- Any UTXO that was in the snapshot set and remains unspent becomes
permanently unspendable
- Transactions attempting to spend these UTXOs are invalid
3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their local
UTXO set. Transactions referencing unknown outpoints are already rejected
as invalid; pruned Lynx UTXOs are simply treated as if they were already
spent.
4) Grace period: The ~4 year window between snapshot and enforcement
provides ample time for holders to consolidate sub-dust UTXOs if they wish
to preserve the value.
Activation
Activation method: TBD (Speedy Trial, BIP8, or other mechanism as
determined by community consensus)
Recommended first snapshot: The halving following activation lock-in
Rationale
Why a fixed threshold?
Using a fixed threshold of 999 sats rather than referencing the dynamic
relay dust limit provides:
- Simplicity: One number, no script-type variations, no need to query
policy settings
- Predictability: Everyone knows exactly what qualifies, forever
- Consensus clarity: No ambiguity about which outputs are affected.
Why tie to the halving?
The halving is Bitcoin's most recognized Schelling point, using it provides:
- Predictability: Everyone knows exactly when halvings occur
- Sufficient notice: ~4 years is generous warning for any cleanup action
- Aligned incentives: As block rewards decrease, fee revenue and UTXO
efficiency become more critical to network sustainability
- Natural cadence: The halving already represents a moment of network-wide
coordination
Why not a one-time cleanup?
A one-time cleanup (as proposed by The Cat) provides temporary relief but
creates no ongoing pressure against dust accumulation. Periodic enforcement:
- Establishes a permanent, predictable norm
- Removes any expectation that dust UTXOs have indefinite longevity
- Discourages business models built on dust creation
- Provides continuous UTXO set maintenance
Why pruning works without a list
A key insight enables pruning without maintaining a separate list: Bitcoin
nodes already reject transactions that reference unknown outpoints. When a
node receives a transaction spending an outpoint not in its UTXO set, it
rejects it as invalid — the node doesn't need to know why the outpoint is
missing (spent? never existed? pruned?).
After enforcement, a Lynx UTXO is functionally equivalent to a spent
output. Nodes can simply delete it from the UTXO set. Any future
transaction attempting to spend it will reference an outpoint the node
doesn't recognize, and will be rejected through existing validation logic.
This means:
- No separate "Lynx list" is required
- No new validation logic is needed
- Pruning is optional; nodes MAY keep Lynx UTXOs if they wish
- The UTXO set shrinks naturally as nodes prune
Why 999 sats?
The threshold of 999 sats is chosen because:
- Above all dust limits: Captures UTXOs at or below the dust limit for all
script types (P2PKH: 546, P2TR: 330, etc.)
- Captures all standard inscriptions: Typical inscription UTXOs contain
exactly 546 sats as "postage"; well under 999
- Simple and memorable: A clean number that's easy to communicate and
reason about
Backward Compatibility
This is a soft fork. Nodes that do not upgrade will:
- Continue to consider all historical transactions valid
- Accept blocks that exclude spends of Lynx UTXOs
- Eventually converge with upgraded nodes (as upgraded miners will not
include invalid spends)
Wallets & Services should:
- Warn users holding sub-threshold UTXOs after a snapshot block
- Provide consolidation tools during the grace period
- Update UTXO selection algorithms to deprioritize or exclude sub-threshold
outputs approaching a snapshot
Security Considerations
No confiscation
This proposal does not transfer value to any party. Sub-threshold UTXOs
become unspendable, similar to:
- Lost private keys
- Provably unspendable OP_RETURN outputs
- Satoshi's untouched coinbase rewards
The bitcoin supply cap remains unchanged; the affected outputs simply
become irrecoverable. Holders receive ~4 years notice to consolidate if
they value the sats.
Lightning Network
Some Lightning implementations create small HTLCs and dust outputs during
channel operations. Analysis is needed to determine:
- Whether current dust thresholds affect normal LN operations
- If LN implementations need adjustment before activation
- Whether channel close scenarios create sub-threshold outputs
Preliminary assessment: LN dust limits are already set conservatively above
relay dust limits, so impact should be minimal. However, this requires
verification from LN implementers.
Fixed threshold vs. future fee markets
The 999 satoshi threshold is fixed in consensus rules and does not adjust
based on fee market conditions.
This is intentional:
- A fixed threshold provides certainty for users and developers
- If fee markets change dramatically, a future soft fork could adjust the
threshold
- The ~4 year grace period allows the community to observe and adapt
If Bitcoin's fee market evolves such that 999 sats becomes economically
significant to spend, this would indicate broader success of the network;
and the community could choose to lower or eliminate the threshold through
a subsequent proposal.
Acknowledgments
This proposal builds on the problem identification in "The Cat"
(Non-monetary UTXO Cleanup) while proposing a list-free alternative
mechanism. The Cat correctly identifies UTXO bloat as a problem worth
solving; Lynx offers a more neutral solution.
https://x.com/matteopelleg/status/2000602318346334449
On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
> I received no prior response from you, so I suspect the issue is on your
> end-- since if you sent one I would normally have been directly copied.
>
> In any case, your message makes no sense. If an output is provably
> unspendable then it is unspendable. No amount of "clever steganography"
> can change that. If you're imagining that perhaps they are *presumed* to
> be unspendable but actually *are* spendable, then sure that would be an
> issue but with any change to consensus relevant code great care must be
> taken to not introduce errors. Actually *making* a consensus change would
> only increase the potential for mistakes.
>
> These costs are just another reason why this hysteria over a non-issue is
> misplaced.
>
> But in any case it is better that (any) implementations that care about
> stamps put in the effort to define their exclusions in ways that are safe
> than to burden everyone with a consensus change that doesn't care about it.
>
>
> On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98...@gmail.com> wrote:
>
>> This is my third attempt to respond to this. Idk what is going wrong here.
>>
>> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without
>> a consensus change is that a clever use of steganography could cause one of
>> those otherwise unspendable outputs to be spendable, thus causing a fork
>> between those nodes that adopted the Stamp pruning method and those that
>> did not once one of those steganographic Stamps is spent. Though this is
>> unlikely, it is still technically possible, and I would not put it past the
>> denizens of the Internet to stir up trouble just for its own sake.
>>
>> On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
>>
>>> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com> wrote:
>>>
>>>> Since the Bitcoin Stamps outputs are already unspendable, it makes
>>>> perfect sense to mark and drop them from the UTXO set.
>>>
>>>
>>> There is no consensus change involved in not storing a provably
>>> unspendable output, it's just an implementation detail with no
>>> interoperability implications and doesn't need a BIP. Bitcoin core has
>>> long done so for several types of unspendable outputs, e.g. outputs over
>>> 10kb and ones starting with OP_RETURN.
>>>
>>> --
>> 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
>> email to bitcoindev+...@googlegroups.com.
>>
> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 16058 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-21 5:07 ` John
@ 2025-12-23 19:12 ` Greg Maxwell
2025-12-24 17:19 ` waxwing/ AdamISZ
0 siblings, 1 reply; 20+ messages in thread
From: Greg Maxwell @ 2025-12-23 19:12 UTC (permalink / raw)
To: John; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 16493 bytes --]
The 'dust threshold' isn't a consensus parameter, it's just a number pulled
out of the air that didn't seem unreasonable based on average fee
behavior. But in any particular block transactions may need no particular
fee level at all, including zero fees. And in some cases it may be very
economically advantageous to spend an output even if its face value doesn't
support it, NFT's being a one such example (although one I consider pretty
dumb).
This proposal also appears to have ignored the prior discussion
particularly where it was pointed out that 'deleting' outputs will not
achieve the goal of deleting the tokens connected to them (so won't
eliminate the incentive), or that txouts which are predictably not going to
be accessed (as this proposal claims applies to the txouts it targets)
don't have as significant performance implications (because they don't need
to be cached in ram). It also appears to be uninformed by advances like
utxotree which makes the absolute size of the txout set much less
important, but would make mass removals such as that described
here expensive. Nor has it considered that given the level of fee spending
on NFT traffic a requirement to keep it over some (reasonable) threshold
would not likely discourage it, or the fact that existent NFT outputs are
generally over the dust limit in any case (so the proposals failure to meet
the opcat proponents' delusional goals is already clear).
I think the list should adopt a 1 year ban on parties *and their*
employer(s) (if known) for any coin confiscation proposal on the list going
forward (after, of course, making the rule clear on the signup page). It's
tiresome and beyond being a waste of time risks undermining public
confidence in Bitcoin to see the constant trickle of these
outrageous proposals in venues where they previously understood that
serious discussions were to be had. People are, of course, free to discuss
whatever ill-founded concepts they want but they're not entitled to the
time and the reputation of the participants here for offensively misguided
proposals.
On Tue, Dec 23, 2025 at 6:27 PM John <johnpenner151516@gmail.com> wrote:
> Good evening all,
>
> Here is a related proposal by Matteo Pellegrini
> @matteopelleg
>
>
>
> Lynx.
>
> Abstract
> This proposal introduces a periodic, consensus-enforced mechanism for
> rendering UTXOs below the network's dust threshold permanently unspendable.
> At each halving block, UTXOs that have remained below the dust threshold
> since the previous halving become unspendable. These UTXOs become
> unspendable and may be pruned from the UTXO set entirely, reducing node
> storage requirements and eliminating the economic model that incentivizes
> their creation.
>
> Motivation
> The Bitcoin UTXO set has grown substantially due to various factors,
> including inscription protocols, spam attacks, and general dust
> accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO
> Cleanup) by @ostrom72158
> have attempted to address this by creating lists of specific UTXOs to
> render unspendable, identified by external protocol indexers.
>
> The Cat's approach has a fatal flaw: it relies on a list.
>
> Using a curated list of "non-monetary UTXOs" introduces several problems:
>
> 1) External dependency: The Cat requires reference indexers (Ord, Stamps,
> etc.) to define which UTXOs qualify. This introduces consensus-level
> dependency on external, non-Bitcoin software that can change, have bugs, or
> interpret protocols differently.
>
> 2) Protocol targeting: By specifically identifying inscription and stamp
> outputs, the proposal makes subjective judgments about which Bitcoin uses
> are legitimate. This sets a precedent for protocol-level discrimination.
>
> 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes
> workarounds. If Ordinals dust is targeted, protocols will adapt to create
> dust that doesn't match the list criteria.
>
> 4) Static snapshot: A one-time list cleanup provides temporary relief but
> does nothing for future UTXO accumulation.
>
> 5) Political vulnerability: Any list-based approach requires ongoing
> governance decisions about what belongs on the list, creating a permanent
> political attack surface.
>
> A better approach targets the economic reality, not the use case.
>
> UTXOs below the dust threshold are, by definition, economically irrational
> to spend under normal fee conditions. The dust limit exists precisely
> because spending these outputs costs more in fees than the output is worth.
> These UTXOs are already "dead" in practice; this proposal simply makes that
> reality explicit at the consensus layer.
>
> By using a threshold rather than a list, Lynx:
>
> - Requires no external indexers
> - Makes no judgment about why a UTXO is small
> - Applies equally to all participants
> - Provides ongoing, predictable maintenance
> - Removes political discretion from the process
>
> Impact on Inscription Protocols
>
> The typical Ordinals inscription is stored in a UTXO containing exactly
> 546 sats; the minimum required to meet the dust limit for P2PKH addresses
> and ensure transferability across all address types. This "postage" amount
> is standard across inscription tooling and marketplaces.
>
> A threshold of 999 sats captures the vast majority of inscription UTXOs
> without requiring any protocol-specific targeting. The economic model of
> inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks
> that model through neutral, threshold-based rules rather than list-based
> discrimination.
>
> Specification
>
> Definitions
>
> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is
> subject to Lynx enforcement.
>
> - Halving block: A block at height N * 210,000 where N ≥ 1.
>
> - Snapshot block: A halving block at which the current dust threshold and
> qualifying UTXOs are recorded.
>
> - Enforcement block: The halving block following a snapshot block (i.e.,
> snapshot block + 210,000 blocks).
>
> Lynx UTXOs:
> - Existed at the snapshot block
> - Had a value less than 999 sats
> - Remained unspent through the enforcement period (~4 years)
>
> Consensus Rules
> After activation, the following rules apply:
>
> 1) Snapshot: At each halving block H, record the set of all UTXOs with
> value < 999 sats.
>
> 2) Enforcement: At halving block H + 210,000:
> - Any UTXO that was in the snapshot set and remains unspent becomes
> permanently unspendable
> - Transactions attempting to spend these UTXOs are invalid
>
> 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their local
> UTXO set. Transactions referencing unknown outpoints are already rejected
> as invalid; pruned Lynx UTXOs are simply treated as if they were already
> spent.
>
> 4) Grace period: The ~4 year window between snapshot and enforcement
> provides ample time for holders to consolidate sub-dust UTXOs if they wish
> to preserve the value.
>
> Activation
>
> Activation method: TBD (Speedy Trial, BIP8, or other mechanism as
> determined by community consensus)
>
> Recommended first snapshot: The halving following activation lock-in
>
> Rationale
>
> Why a fixed threshold?
>
> Using a fixed threshold of 999 sats rather than referencing the dynamic
> relay dust limit provides:
>
> - Simplicity: One number, no script-type variations, no need to query
> policy settings
>
> - Predictability: Everyone knows exactly what qualifies, forever
>
> - Consensus clarity: No ambiguity about which outputs are affected.
>
> Why tie to the halving?
>
> The halving is Bitcoin's most recognized Schelling point, using it
> provides:
>
> - Predictability: Everyone knows exactly when halvings occur
> - Sufficient notice: ~4 years is generous warning for any cleanup action
> - Aligned incentives: As block rewards decrease, fee revenue and UTXO
> efficiency become more critical to network sustainability
> - Natural cadence: The halving already represents a moment of network-wide
> coordination
>
> Why not a one-time cleanup?
>
> A one-time cleanup (as proposed by The Cat) provides temporary relief but
> creates no ongoing pressure against dust accumulation. Periodic enforcement:
>
> - Establishes a permanent, predictable norm
> - Removes any expectation that dust UTXOs have indefinite longevity
> - Discourages business models built on dust creation
> - Provides continuous UTXO set maintenance
>
> Why pruning works without a list
>
> A key insight enables pruning without maintaining a separate list: Bitcoin
> nodes already reject transactions that reference unknown outpoints. When a
> node receives a transaction spending an outpoint not in its UTXO set, it
> rejects it as invalid — the node doesn't need to know why the outpoint is
> missing (spent? never existed? pruned?).
>
> After enforcement, a Lynx UTXO is functionally equivalent to a spent
> output. Nodes can simply delete it from the UTXO set. Any future
> transaction attempting to spend it will reference an outpoint the node
> doesn't recognize, and will be rejected through existing validation logic.
>
> This means:
>
> - No separate "Lynx list" is required
> - No new validation logic is needed
> - Pruning is optional; nodes MAY keep Lynx UTXOs if they wish
> - The UTXO set shrinks naturally as nodes prune
>
> Why 999 sats?
>
> The threshold of 999 sats is chosen because:
>
> - Above all dust limits: Captures UTXOs at or below the dust limit for all
> script types (P2PKH: 546, P2TR: 330, etc.)
> - Captures all standard inscriptions: Typical inscription UTXOs contain
> exactly 546 sats as "postage"; well under 999
> - Simple and memorable: A clean number that's easy to communicate and
> reason about
>
> Backward Compatibility
>
> This is a soft fork. Nodes that do not upgrade will:
>
> - Continue to consider all historical transactions valid
> - Accept blocks that exclude spends of Lynx UTXOs
> - Eventually converge with upgraded nodes (as upgraded miners will not
> include invalid spends)
>
> Wallets & Services should:
>
> - Warn users holding sub-threshold UTXOs after a snapshot block
> - Provide consolidation tools during the grace period
> - Update UTXO selection algorithms to deprioritize or exclude
> sub-threshold outputs approaching a snapshot
>
> Security Considerations
>
> No confiscation
>
> This proposal does not transfer value to any party. Sub-threshold UTXOs
> become unspendable, similar to:
>
> - Lost private keys
> - Provably unspendable OP_RETURN outputs
> - Satoshi's untouched coinbase rewards
>
> The bitcoin supply cap remains unchanged; the affected outputs simply
> become irrecoverable. Holders receive ~4 years notice to consolidate if
> they value the sats.
>
> Lightning Network
>
> Some Lightning implementations create small HTLCs and dust outputs during
> channel operations. Analysis is needed to determine:
>
> - Whether current dust thresholds affect normal LN operations
> - If LN implementations need adjustment before activation
> - Whether channel close scenarios create sub-threshold outputs
>
> Preliminary assessment: LN dust limits are already set conservatively
> above relay dust limits, so impact should be minimal. However, this
> requires verification from LN implementers.
>
> Fixed threshold vs. future fee markets
>
> The 999 satoshi threshold is fixed in consensus rules and does not adjust
> based on fee market conditions.
> This is intentional:
>
> - A fixed threshold provides certainty for users and developers
> - If fee markets change dramatically, a future soft fork could adjust the
> threshold
> - The ~4 year grace period allows the community to observe and adapt
>
> If Bitcoin's fee market evolves such that 999 sats becomes economically
> significant to spend, this would indicate broader success of the network;
> and the community could choose to lower or eliminate the threshold through
> a subsequent proposal.
>
> Acknowledgments
> This proposal builds on the problem identification in "The Cat"
> (Non-monetary UTXO Cleanup) while proposing a list-free alternative
> mechanism. The Cat correctly identifies UTXO bloat as a problem worth
> solving; Lynx offers a more neutral solution.
>
>
> https://x.com/matteopelleg/status/2000602318346334449
> On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
>
>> I received no prior response from you, so I suspect the issue is on your
>> end-- since if you sent one I would normally have been directly copied.
>>
>> In any case, your message makes no sense. If an output is provably
>> unspendable then it is unspendable. No amount of "clever steganography"
>> can change that. If you're imagining that perhaps they are *presumed* to
>> be unspendable but actually *are* spendable, then sure that would be an
>> issue but with any change to consensus relevant code great care must be
>> taken to not introduce errors. Actually *making* a consensus change would
>> only increase the potential for mistakes.
>>
>> These costs are just another reason why this hysteria over a non-issue is
>> misplaced.
>>
>> But in any case it is better that (any) implementations that care about
>> stamps put in the effort to define their exclusions in ways that are safe
>> than to burden everyone with a consensus change that doesn't care about it.
>>
>>
>> On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98...@gmail.com> wrote:
>>
>>> This is my third attempt to respond to this. Idk what is going wrong
>>> here.
>>>
>>> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without
>>> a consensus change is that a clever use of steganography could cause one of
>>> those otherwise unspendable outputs to be spendable, thus causing a fork
>>> between those nodes that adopted the Stamp pruning method and those that
>>> did not once one of those steganographic Stamps is spent. Though this is
>>> unlikely, it is still technically possible, and I would not put it past the
>>> denizens of the Internet to stir up trouble just for its own sake.
>>>
>>> On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
>>>
>>>> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com> wrote:
>>>>
>>>>> Since the Bitcoin Stamps outputs are already unspendable, it makes
>>>>> perfect sense to mark and drop them from the UTXO set.
>>>>
>>>>
>>>> There is no consensus change involved in not storing a provably
>>>> unspendable output, it's just an implementation detail with no
>>>> interoperability implications and doesn't need a BIP. Bitcoin core has
>>>> long done so for several types of unspendable outputs, e.g. outputs over
>>>> 10kb and ones starting with OP_RETURN.
>>>>
>>>> --
>>> 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 email to bitcoindev+...@googlegroups.com.
>>>
>> To view this discussion visit
>>> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSB9tymGr_cddWSRkg36NvQqoAq%2B7%3DXkpvkbP_VpuCLJg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 18843 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-23 19:12 ` Greg Maxwell
@ 2025-12-24 17:19 ` waxwing/ AdamISZ
2025-12-30 14:36 ` Antoine Riard
0 siblings, 1 reply; 20+ messages in thread
From: waxwing/ AdamISZ @ 2025-12-24 17:19 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 19415 bytes --]
Hi Greg, list:
> I think the list should adopt a 1 year ban on parties *and their*
employer(s) (if known) for any coin confiscation proposal on the list going
forward (after, of course, making the rule clear on the signup page). It's
tiresome and beyond being a waste of time risks undermining public
confidence in Bitcoin to see the constant trickle of these
outrageous proposals in venues where they previously understood that
serious discussions were to be had. People are, of course, free to discuss
whatever ill-founded concepts they want but they're not entitled to the
time and the reputation of the participants here for offensively misguided
proposals.
I'm a huge agree-er with the motivation of this comment and a huge
disagree-er with the suggestion itself.
Actual confiscation, whatever the reason, hugely undermines Bitcoin's value
to humanity - note I am not saying its financial value, but value as a
project (and if we didn't see such value what the hell are we doing here).
Of course those two types of value are very closely linked, but they are
still distinct. I hold that same belief even when we are talking about
other suggestions of confiscation, such as to address a quantum threat -
something that has recently been discussed here, extensively.
Which brings me to my disagreement, which I know is not shared by a number
of contributors here: just as it is hard to define spam on Bitcoin, it's
also very hard to define it in a discussion forum like this one. Making
suggestions which *I* think are terrible, or detrimental, on a list like
this, should never be disallowed here. Notions of motivation of
contributors (such as they are paid by such and such a company) should not
be relevant. Everything should be open to discussion which is
implementation-technical (so obviously not e.g. threats of violence or
things that bring legal liability to participants or have zero relevance to
Bitcoin's technical development) even if it's philosophy-motivated. And
blocking should be reserved either as an anti-DOS measure if volume gets
out of control, or if it brings dangers as per the previous parenthetical.
Just my opinion of course, I know that moderation of lists is not a simple
matter.
Cheers,
AdamISZ/waxwing
On Tuesday, December 23, 2025 at 10:26:16 PM UTC-3 Greg Maxwell wrote:
> The 'dust threshold' isn't a consensus parameter, it's just a number
> pulled out of the air that didn't seem unreasonable based on average fee
> behavior. But in any particular block transactions may need no particular
> fee level at all, including zero fees. And in some cases it may be very
> economically advantageous to spend an output even if its face value doesn't
> support it, NFT's being a one such example (although one I consider pretty
> dumb).
>
> This proposal also appears to have ignored the prior discussion
> particularly where it was pointed out that 'deleting' outputs will not
> achieve the goal of deleting the tokens connected to them (so won't
> eliminate the incentive), or that txouts which are predictably not going to
> be accessed (as this proposal claims applies to the txouts it targets)
> don't have as significant performance implications (because they don't need
> to be cached in ram). It also appears to be uninformed by advances like
> utxotree which makes the absolute size of the txout set much less
> important, but would make mass removals such as that described
> here expensive. Nor has it considered that given the level of fee spending
> on NFT traffic a requirement to keep it over some (reasonable) threshold
> would not likely discourage it, or the fact that existent NFT outputs are
> generally over the dust limit in any case (so the proposals failure to meet
> the opcat proponents' delusional goals is already clear).
>
> I think the list should adopt a 1 year ban on parties *and their*
> employer(s) (if known) for any coin confiscation proposal on the list going
> forward (after, of course, making the rule clear on the signup page). It's
> tiresome and beyond being a waste of time risks undermining public
> confidence in Bitcoin to see the constant trickle of these
> outrageous proposals in venues where they previously understood that
> serious discussions were to be had. People are, of course, free to discuss
> whatever ill-founded concepts they want but they're not entitled to the
> time and the reputation of the participants here for offensively misguided
> proposals.
>
>
> On Tue, Dec 23, 2025 at 6:27 PM John <johnpenn...@gmail.com> wrote:
>
>> Good evening all,
>>
>> Here is a related proposal by Matteo Pellegrini
>> @matteopelleg
>>
>>
>>
>> Lynx.
>>
>> Abstract
>> This proposal introduces a periodic, consensus-enforced mechanism for
>> rendering UTXOs below the network's dust threshold permanently unspendable.
>> At each halving block, UTXOs that have remained below the dust threshold
>> since the previous halving become unspendable. These UTXOs become
>> unspendable and may be pruned from the UTXO set entirely, reducing node
>> storage requirements and eliminating the economic model that incentivizes
>> their creation.
>>
>> Motivation
>> The Bitcoin UTXO set has grown substantially due to various factors,
>> including inscription protocols, spam attacks, and general dust
>> accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO
>> Cleanup) by @ostrom72158
>> have attempted to address this by creating lists of specific UTXOs to
>> render unspendable, identified by external protocol indexers.
>>
>> The Cat's approach has a fatal flaw: it relies on a list.
>>
>> Using a curated list of "non-monetary UTXOs" introduces several problems:
>>
>> 1) External dependency: The Cat requires reference indexers (Ord, Stamps,
>> etc.) to define which UTXOs qualify. This introduces consensus-level
>> dependency on external, non-Bitcoin software that can change, have bugs, or
>> interpret protocols differently.
>>
>> 2) Protocol targeting: By specifically identifying inscription and stamp
>> outputs, the proposal makes subjective judgments about which Bitcoin uses
>> are legitimate. This sets a precedent for protocol-level discrimination.
>>
>> 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes
>> workarounds. If Ordinals dust is targeted, protocols will adapt to create
>> dust that doesn't match the list criteria.
>>
>> 4) Static snapshot: A one-time list cleanup provides temporary relief but
>> does nothing for future UTXO accumulation.
>>
>> 5) Political vulnerability: Any list-based approach requires ongoing
>> governance decisions about what belongs on the list, creating a permanent
>> political attack surface.
>>
>> A better approach targets the economic reality, not the use case.
>>
>> UTXOs below the dust threshold are, by definition, economically
>> irrational to spend under normal fee conditions. The dust limit exists
>> precisely because spending these outputs costs more in fees than the output
>> is worth. These UTXOs are already "dead" in practice; this proposal simply
>> makes that reality explicit at the consensus layer.
>>
>> By using a threshold rather than a list, Lynx:
>>
>> - Requires no external indexers
>> - Makes no judgment about why a UTXO is small
>> - Applies equally to all participants
>> - Provides ongoing, predictable maintenance
>> - Removes political discretion from the process
>>
>> Impact on Inscription Protocols
>>
>> The typical Ordinals inscription is stored in a UTXO containing exactly
>> 546 sats; the minimum required to meet the dust limit for P2PKH addresses
>> and ensure transferability across all address types. This "postage" amount
>> is standard across inscription tooling and marketplaces.
>>
>> A threshold of 999 sats captures the vast majority of inscription UTXOs
>> without requiring any protocol-specific targeting. The economic model of
>> inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks
>> that model through neutral, threshold-based rules rather than list-based
>> discrimination.
>>
>> Specification
>>
>> Definitions
>>
>> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is
>> subject to Lynx enforcement.
>>
>> - Halving block: A block at height N * 210,000 where N ≥ 1.
>>
>> - Snapshot block: A halving block at which the current dust threshold
>> and qualifying UTXOs are recorded.
>>
>> - Enforcement block: The halving block following a snapshot block (i.e.,
>> snapshot block + 210,000 blocks).
>>
>> Lynx UTXOs:
>> - Existed at the snapshot block
>> - Had a value less than 999 sats
>> - Remained unspent through the enforcement period (~4 years)
>>
>> Consensus Rules
>> After activation, the following rules apply:
>>
>> 1) Snapshot: At each halving block H, record the set of all UTXOs with
>> value < 999 sats.
>>
>> 2) Enforcement: At halving block H + 210,000:
>> - Any UTXO that was in the snapshot set and remains unspent becomes
>> permanently unspendable
>> - Transactions attempting to spend these UTXOs are invalid
>>
>> 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their
>> local UTXO set. Transactions referencing unknown outpoints are already
>> rejected as invalid; pruned Lynx UTXOs are simply treated as if they were
>> already spent.
>>
>> 4) Grace period: The ~4 year window between snapshot and enforcement
>> provides ample time for holders to consolidate sub-dust UTXOs if they wish
>> to preserve the value.
>>
>> Activation
>>
>> Activation method: TBD (Speedy Trial, BIP8, or other mechanism as
>> determined by community consensus)
>>
>> Recommended first snapshot: The halving following activation lock-in
>>
>> Rationale
>>
>> Why a fixed threshold?
>>
>> Using a fixed threshold of 999 sats rather than referencing the dynamic
>> relay dust limit provides:
>>
>> - Simplicity: One number, no script-type variations, no need to query
>> policy settings
>>
>> - Predictability: Everyone knows exactly what qualifies, forever
>>
>> - Consensus clarity: No ambiguity about which outputs are affected.
>>
>> Why tie to the halving?
>>
>> The halving is Bitcoin's most recognized Schelling point, using it
>> provides:
>>
>> - Predictability: Everyone knows exactly when halvings occur
>> - Sufficient notice: ~4 years is generous warning for any cleanup action
>> - Aligned incentives: As block rewards decrease, fee revenue and UTXO
>> efficiency become more critical to network sustainability
>> - Natural cadence: The halving already represents a moment of
>> network-wide coordination
>>
>> Why not a one-time cleanup?
>>
>> A one-time cleanup (as proposed by The Cat) provides temporary relief but
>> creates no ongoing pressure against dust accumulation. Periodic enforcement:
>>
>> - Establishes a permanent, predictable norm
>> - Removes any expectation that dust UTXOs have indefinite longevity
>> - Discourages business models built on dust creation
>> - Provides continuous UTXO set maintenance
>>
>> Why pruning works without a list
>>
>> A key insight enables pruning without maintaining a separate list:
>> Bitcoin nodes already reject transactions that reference unknown outpoints.
>> When a node receives a transaction spending an outpoint not in its UTXO
>> set, it rejects it as invalid — the node doesn't need to know why the
>> outpoint is missing (spent? never existed? pruned?).
>>
>> After enforcement, a Lynx UTXO is functionally equivalent to a spent
>> output. Nodes can simply delete it from the UTXO set. Any future
>> transaction attempting to spend it will reference an outpoint the node
>> doesn't recognize, and will be rejected through existing validation logic.
>>
>> This means:
>>
>> - No separate "Lynx list" is required
>> - No new validation logic is needed
>> - Pruning is optional; nodes MAY keep Lynx UTXOs if they wish
>> - The UTXO set shrinks naturally as nodes prune
>>
>> Why 999 sats?
>>
>> The threshold of 999 sats is chosen because:
>>
>> - Above all dust limits: Captures UTXOs at or below the dust limit for
>> all script types (P2PKH: 546, P2TR: 330, etc.)
>> - Captures all standard inscriptions: Typical inscription UTXOs contain
>> exactly 546 sats as "postage"; well under 999
>> - Simple and memorable: A clean number that's easy to communicate and
>> reason about
>>
>> Backward Compatibility
>>
>> This is a soft fork. Nodes that do not upgrade will:
>>
>> - Continue to consider all historical transactions valid
>> - Accept blocks that exclude spends of Lynx UTXOs
>> - Eventually converge with upgraded nodes (as upgraded miners will not
>> include invalid spends)
>>
>> Wallets & Services should:
>>
>> - Warn users holding sub-threshold UTXOs after a snapshot block
>> - Provide consolidation tools during the grace period
>> - Update UTXO selection algorithms to deprioritize or exclude
>> sub-threshold outputs approaching a snapshot
>>
>> Security Considerations
>>
>> No confiscation
>>
>> This proposal does not transfer value to any party. Sub-threshold UTXOs
>> become unspendable, similar to:
>>
>> - Lost private keys
>> - Provably unspendable OP_RETURN outputs
>> - Satoshi's untouched coinbase rewards
>>
>> The bitcoin supply cap remains unchanged; the affected outputs simply
>> become irrecoverable. Holders receive ~4 years notice to consolidate if
>> they value the sats.
>>
>> Lightning Network
>>
>> Some Lightning implementations create small HTLCs and dust outputs during
>> channel operations. Analysis is needed to determine:
>>
>> - Whether current dust thresholds affect normal LN operations
>> - If LN implementations need adjustment before activation
>> - Whether channel close scenarios create sub-threshold outputs
>>
>> Preliminary assessment: LN dust limits are already set conservatively
>> above relay dust limits, so impact should be minimal. However, this
>> requires verification from LN implementers.
>>
>> Fixed threshold vs. future fee markets
>>
>> The 999 satoshi threshold is fixed in consensus rules and does not adjust
>> based on fee market conditions.
>> This is intentional:
>>
>> - A fixed threshold provides certainty for users and developers
>> - If fee markets change dramatically, a future soft fork could adjust the
>> threshold
>> - The ~4 year grace period allows the community to observe and adapt
>>
>> If Bitcoin's fee market evolves such that 999 sats becomes economically
>> significant to spend, this would indicate broader success of the network;
>> and the community could choose to lower or eliminate the threshold through
>> a subsequent proposal.
>>
>> Acknowledgments
>> This proposal builds on the problem identification in "The Cat"
>> (Non-monetary UTXO Cleanup) while proposing a list-free alternative
>> mechanism. The Cat correctly identifies UTXO bloat as a problem worth
>> solving; Lynx offers a more neutral solution.
>>
>>
>> https://x.com/matteopelleg/status/2000602318346334449
>> On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
>>
>>> I received no prior response from you, so I suspect the issue is on your
>>> end-- since if you sent one I would normally have been directly copied.
>>>
>>> In any case, your message makes no sense. If an output is provably
>>> unspendable then it is unspendable. No amount of "clever steganography"
>>> can change that. If you're imagining that perhaps they are *presumed* to
>>> be unspendable but actually *are* spendable, then sure that would be an
>>> issue but with any change to consensus relevant code great care must be
>>> taken to not introduce errors. Actually *making* a consensus change would
>>> only increase the potential for mistakes.
>>>
>>> These costs are just another reason why this hysteria over a non-issue
>>> is misplaced.
>>>
>>> But in any case it is better that (any) implementations that care about
>>> stamps put in the effort to define their exclusions in ways that are safe
>>> than to burden everyone with a consensus change that doesn't care about it.
>>>
>>>
>>> On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98...@gmail.com> wrote:
>>>
>>>> This is my third attempt to respond to this. Idk what is going wrong
>>>> here.
>>>>
>>>> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set
>>>> without a consensus change is that a clever use of steganography could
>>>> cause one of those otherwise unspendable outputs to be spendable, thus
>>>> causing a fork between those nodes that adopted the Stamp pruning method
>>>> and those that did not once one of those steganographic Stamps is spent.
>>>> Though this is unlikely, it is still technically possible, and I would not
>>>> put it past the denizens of the Internet to stir up trouble just for its
>>>> own sake.
>>>>
>>>> On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
>>>>
>>>>> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Since the Bitcoin Stamps outputs are already unspendable, it makes
>>>>>> perfect sense to mark and drop them from the UTXO set.
>>>>>
>>>>>
>>>>> There is no consensus change involved in not storing a provably
>>>>> unspendable output, it's just an implementation detail with no
>>>>> interoperability implications and doesn't need a BIP. Bitcoin core has
>>>>> long done so for several types of unspendable outputs, e.g. outputs over
>>>>> 10kb and ones starting with OP_RETURN.
>>>>>
>>>>> --
>>>> 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 email to bitcoindev+...@googlegroups.com.
>>>>
>>> To view this discussion visit
>>>> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>> 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
>> email to bitcoindev+...@googlegroups.com.
>>
> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/213ed021-c57e-40b6-8357-c797f52c7d34n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 22495 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-24 17:19 ` waxwing/ AdamISZ
@ 2025-12-30 14:36 ` Antoine Riard
2026-01-19 1:11 ` Pepe Hodler
2026-01-22 1:14 ` Claire Ostrom
0 siblings, 2 replies; 20+ messages in thread
From: Antoine Riard @ 2025-12-30 14:36 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 22054 bytes --]
Hi list,
> Which brings me to my disagreement, which I know is not shared by a
number of contributors here: just as it is hard to define spam on Bitcoin,
it's also very hard to define it in a discussion forum like this one.
Making suggestions which *I* think are terrible, or detrimental, on a list
like this, should never be disallowed here. Notions of motivation of
contributors (such as they are paid by such and such a company) should not
be relevant. Everything should be open to discussion which is
implementation-technical (so obviously not e.g. threats of violence or
things that bring legal liability to participants or have zero relevance to
Bitcoin's technical development) even if it's philosophy-motivated. And
blocking should be reserved either as an anti-DOS measure if volume gets
out of control, or if it brings dangers as per the previous parenthetical.
I'm fully sharing waxwing reasonable opinion. While I can understand gmax's
sentiment being fed
up with poor coin confiscation proposals again and again on the mailing
list, the cure would be
worst than the disease. Maybe, I'm very voltairean here, but you don't
fight ill-founded opinions.
by persecuting their authors (--otherwise, down the road you take the risk
of seeing the bastille
popped up). Rather than you fight them back by doing the work to persuade
and to convince those
ideas you find stupid are indeed *objectively* stupid.
To me, it's a sign of strength and confidence that Bitcoin and its
development process can
withstand and endure the most "outrageous" controversies. For sure, I have
been enough times
in the shoes of someone who has to champion controversial changes (cf.
`mempoolfullrbf`) to not
negate that the strength of the process is kinda traded on the back of the
devs, but this is not
altering my mind on what I think should be *ideally* the development
process in terms of openess
and publicity.
My humble opinion only, as we said.
Best,
Antoine
OTS hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1ce
Le mercredi 24 décembre 2025 à 17:23:48 UTC, waxwing/ AdamISZ a écrit :
> Hi Greg, list:
>
> > I think the list should adopt a 1 year ban on parties *and their*
> employer(s) (if known) for any coin confiscation proposal on the list going
> forward (after, of course, making the rule clear on the signup page). It's
> tiresome and beyond being a waste of time risks undermining public
> confidence in Bitcoin to see the constant trickle of these
> outrageous proposals in venues where they previously understood that
> serious discussions were to be had. People are, of course, free to discuss
> whatever ill-founded concepts they want but they're not entitled to the
> time and the reputation of the participants here for offensively misguided
> proposals.
>
> I'm a huge agree-er with the motivation of this comment and a huge
> disagree-er with the suggestion itself.
>
> Actual confiscation, whatever the reason, hugely undermines Bitcoin's
> value to humanity - note I am not saying its financial value, but value as
> a project (and if we didn't see such value what the hell are we doing
> here). Of course those two types of value are very closely linked, but they
> are still distinct. I hold that same belief even when we are talking about
> other suggestions of confiscation, such as to address a quantum threat -
> something that has recently been discussed here, extensively.
>
> Which brings me to my disagreement, which I know is not shared by a number
> of contributors here: just as it is hard to define spam on Bitcoin, it's
> also very hard to define it in a discussion forum like this one. Making
> suggestions which *I* think are terrible, or detrimental, on a list like
> this, should never be disallowed here. Notions of motivation of
> contributors (such as they are paid by such and such a company) should not
> be relevant. Everything should be open to discussion which is
> implementation-technical (so obviously not e.g. threats of violence or
> things that bring legal liability to participants or have zero relevance to
> Bitcoin's technical development) even if it's philosophy-motivated. And
> blocking should be reserved either as an anti-DOS measure if volume gets
> out of control, or if it brings dangers as per the previous parenthetical.
>
> Just my opinion of course, I know that moderation of lists is not a simple
> matter.
>
> Cheers,
> AdamISZ/waxwing
> On Tuesday, December 23, 2025 at 10:26:16 PM UTC-3 Greg Maxwell wrote:
>
>> The 'dust threshold' isn't a consensus parameter, it's just a number
>> pulled out of the air that didn't seem unreasonable based on average fee
>> behavior. But in any particular block transactions may need no particular
>> fee level at all, including zero fees. And in some cases it may be very
>> economically advantageous to spend an output even if its face value doesn't
>> support it, NFT's being a one such example (although one I consider pretty
>> dumb).
>>
>> This proposal also appears to have ignored the prior discussion
>> particularly where it was pointed out that 'deleting' outputs will not
>> achieve the goal of deleting the tokens connected to them (so won't
>> eliminate the incentive), or that txouts which are predictably not going to
>> be accessed (as this proposal claims applies to the txouts it targets)
>> don't have as significant performance implications (because they don't need
>> to be cached in ram). It also appears to be uninformed by advances like
>> utxotree which makes the absolute size of the txout set much less
>> important, but would make mass removals such as that described
>> here expensive. Nor has it considered that given the level of fee spending
>> on NFT traffic a requirement to keep it over some (reasonable) threshold
>> would not likely discourage it, or the fact that existent NFT outputs are
>> generally over the dust limit in any case (so the proposals failure to meet
>> the opcat proponents' delusional goals is already clear).
>>
>> I think the list should adopt a 1 year ban on parties *and their*
>> employer(s) (if known) for any coin confiscation proposal on the list going
>> forward (after, of course, making the rule clear on the signup page). It's
>> tiresome and beyond being a waste of time risks undermining public
>> confidence in Bitcoin to see the constant trickle of these
>> outrageous proposals in venues where they previously understood that
>> serious discussions were to be had. People are, of course, free to discuss
>> whatever ill-founded concepts they want but they're not entitled to the
>> time and the reputation of the participants here for offensively misguided
>> proposals.
>>
>>
>> On Tue, Dec 23, 2025 at 6:27 PM John <johnpenn...@gmail.com> wrote:
>>
>>> Good evening all,
>>>
>>> Here is a related proposal by Matteo Pellegrini
>>> @matteopelleg
>>>
>>>
>>>
>>> Lynx.
>>>
>>> Abstract
>>> This proposal introduces a periodic, consensus-enforced mechanism for
>>> rendering UTXOs below the network's dust threshold permanently unspendable.
>>> At each halving block, UTXOs that have remained below the dust threshold
>>> since the previous halving become unspendable. These UTXOs become
>>> unspendable and may be pruned from the UTXO set entirely, reducing node
>>> storage requirements and eliminating the economic model that incentivizes
>>> their creation.
>>>
>>> Motivation
>>> The Bitcoin UTXO set has grown substantially due to various factors,
>>> including inscription protocols, spam attacks, and general dust
>>> accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO
>>> Cleanup) by @ostrom72158
>>> have attempted to address this by creating lists of specific UTXOs to
>>> render unspendable, identified by external protocol indexers.
>>>
>>> The Cat's approach has a fatal flaw: it relies on a list.
>>>
>>> Using a curated list of "non-monetary UTXOs" introduces several problems:
>>>
>>> 1) External dependency: The Cat requires reference indexers (Ord,
>>> Stamps, etc.) to define which UTXOs qualify. This introduces
>>> consensus-level dependency on external, non-Bitcoin software that can
>>> change, have bugs, or interpret protocols differently.
>>>
>>> 2) Protocol targeting: By specifically identifying inscription and stamp
>>> outputs, the proposal makes subjective judgments about which Bitcoin uses
>>> are legitimate. This sets a precedent for protocol-level discrimination.
>>>
>>> 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes
>>> workarounds. If Ordinals dust is targeted, protocols will adapt to create
>>> dust that doesn't match the list criteria.
>>>
>>> 4) Static snapshot: A one-time list cleanup provides temporary relief
>>> but does nothing for future UTXO accumulation.
>>>
>>> 5) Political vulnerability: Any list-based approach requires ongoing
>>> governance decisions about what belongs on the list, creating a permanent
>>> political attack surface.
>>>
>>> A better approach targets the economic reality, not the use case.
>>>
>>> UTXOs below the dust threshold are, by definition, economically
>>> irrational to spend under normal fee conditions. The dust limit exists
>>> precisely because spending these outputs costs more in fees than the output
>>> is worth. These UTXOs are already "dead" in practice; this proposal simply
>>> makes that reality explicit at the consensus layer.
>>>
>>> By using a threshold rather than a list, Lynx:
>>>
>>> - Requires no external indexers
>>> - Makes no judgment about why a UTXO is small
>>> - Applies equally to all participants
>>> - Provides ongoing, predictable maintenance
>>> - Removes political discretion from the process
>>>
>>> Impact on Inscription Protocols
>>>
>>> The typical Ordinals inscription is stored in a UTXO containing exactly
>>> 546 sats; the minimum required to meet the dust limit for P2PKH addresses
>>> and ensure transferability across all address types. This "postage" amount
>>> is standard across inscription tooling and marketplaces.
>>>
>>> A threshold of 999 sats captures the vast majority of inscription UTXOs
>>> without requiring any protocol-specific targeting. The economic model of
>>> inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks
>>> that model through neutral, threshold-based rules rather than list-based
>>> discrimination.
>>>
>>> Specification
>>>
>>> Definitions
>>>
>>> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is
>>> subject to Lynx enforcement.
>>>
>>> - Halving block: A block at height N * 210,000 where N ≥ 1.
>>>
>>> - Snapshot block: A halving block at which the current dust threshold
>>> and qualifying UTXOs are recorded.
>>>
>>> - Enforcement block: The halving block following a snapshot block
>>> (i.e., snapshot block + 210,000 blocks).
>>>
>>> Lynx UTXOs:
>>> - Existed at the snapshot block
>>> - Had a value less than 999 sats
>>> - Remained unspent through the enforcement period (~4 years)
>>>
>>> Consensus Rules
>>> After activation, the following rules apply:
>>>
>>> 1) Snapshot: At each halving block H, record the set of all UTXOs with
>>> value < 999 sats.
>>>
>>> 2) Enforcement: At halving block H + 210,000:
>>> - Any UTXO that was in the snapshot set and remains unspent becomes
>>> permanently unspendable
>>> - Transactions attempting to spend these UTXOs are invalid
>>>
>>> 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their
>>> local UTXO set. Transactions referencing unknown outpoints are already
>>> rejected as invalid; pruned Lynx UTXOs are simply treated as if they were
>>> already spent.
>>>
>>> 4) Grace period: The ~4 year window between snapshot and enforcement
>>> provides ample time for holders to consolidate sub-dust UTXOs if they wish
>>> to preserve the value.
>>>
>>> Activation
>>>
>>> Activation method: TBD (Speedy Trial, BIP8, or other mechanism as
>>> determined by community consensus)
>>>
>>> Recommended first snapshot: The halving following activation lock-in
>>>
>>> Rationale
>>>
>>> Why a fixed threshold?
>>>
>>> Using a fixed threshold of 999 sats rather than referencing the dynamic
>>> relay dust limit provides:
>>>
>>> - Simplicity: One number, no script-type variations, no need to query
>>> policy settings
>>>
>>> - Predictability: Everyone knows exactly what qualifies, forever
>>>
>>> - Consensus clarity: No ambiguity about which outputs are affected.
>>>
>>> Why tie to the halving?
>>>
>>> The halving is Bitcoin's most recognized Schelling point, using it
>>> provides:
>>>
>>> - Predictability: Everyone knows exactly when halvings occur
>>> - Sufficient notice: ~4 years is generous warning for any cleanup action
>>> - Aligned incentives: As block rewards decrease, fee revenue and UTXO
>>> efficiency become more critical to network sustainability
>>> - Natural cadence: The halving already represents a moment of
>>> network-wide coordination
>>>
>>> Why not a one-time cleanup?
>>>
>>> A one-time cleanup (as proposed by The Cat) provides temporary relief
>>> but creates no ongoing pressure against dust accumulation. Periodic
>>> enforcement:
>>>
>>> - Establishes a permanent, predictable norm
>>> - Removes any expectation that dust UTXOs have indefinite longevity
>>> - Discourages business models built on dust creation
>>> - Provides continuous UTXO set maintenance
>>>
>>> Why pruning works without a list
>>>
>>> A key insight enables pruning without maintaining a separate list:
>>> Bitcoin nodes already reject transactions that reference unknown outpoints.
>>> When a node receives a transaction spending an outpoint not in its UTXO
>>> set, it rejects it as invalid — the node doesn't need to know why the
>>> outpoint is missing (spent? never existed? pruned?).
>>>
>>> After enforcement, a Lynx UTXO is functionally equivalent to a spent
>>> output. Nodes can simply delete it from the UTXO set. Any future
>>> transaction attempting to spend it will reference an outpoint the node
>>> doesn't recognize, and will be rejected through existing validation logic.
>>>
>>> This means:
>>>
>>> - No separate "Lynx list" is required
>>> - No new validation logic is needed
>>> - Pruning is optional; nodes MAY keep Lynx UTXOs if they wish
>>> - The UTXO set shrinks naturally as nodes prune
>>>
>>> Why 999 sats?
>>>
>>> The threshold of 999 sats is chosen because:
>>>
>>> - Above all dust limits: Captures UTXOs at or below the dust limit for
>>> all script types (P2PKH: 546, P2TR: 330, etc.)
>>> - Captures all standard inscriptions: Typical inscription UTXOs contain
>>> exactly 546 sats as "postage"; well under 999
>>> - Simple and memorable: A clean number that's easy to communicate and
>>> reason about
>>>
>>> Backward Compatibility
>>>
>>> This is a soft fork. Nodes that do not upgrade will:
>>>
>>> - Continue to consider all historical transactions valid
>>> - Accept blocks that exclude spends of Lynx UTXOs
>>> - Eventually converge with upgraded nodes (as upgraded miners will not
>>> include invalid spends)
>>>
>>> Wallets & Services should:
>>>
>>> - Warn users holding sub-threshold UTXOs after a snapshot block
>>> - Provide consolidation tools during the grace period
>>> - Update UTXO selection algorithms to deprioritize or exclude
>>> sub-threshold outputs approaching a snapshot
>>>
>>> Security Considerations
>>>
>>> No confiscation
>>>
>>> This proposal does not transfer value to any party. Sub-threshold UTXOs
>>> become unspendable, similar to:
>>>
>>> - Lost private keys
>>> - Provably unspendable OP_RETURN outputs
>>> - Satoshi's untouched coinbase rewards
>>>
>>> The bitcoin supply cap remains unchanged; the affected outputs simply
>>> become irrecoverable. Holders receive ~4 years notice to consolidate if
>>> they value the sats.
>>>
>>> Lightning Network
>>>
>>> Some Lightning implementations create small HTLCs and dust outputs
>>> during channel operations. Analysis is needed to determine:
>>>
>>> - Whether current dust thresholds affect normal LN operations
>>> - If LN implementations need adjustment before activation
>>> - Whether channel close scenarios create sub-threshold outputs
>>>
>>> Preliminary assessment: LN dust limits are already set conservatively
>>> above relay dust limits, so impact should be minimal. However, this
>>> requires verification from LN implementers.
>>>
>>> Fixed threshold vs. future fee markets
>>>
>>> The 999 satoshi threshold is fixed in consensus rules and does not
>>> adjust based on fee market conditions.
>>> This is intentional:
>>>
>>> - A fixed threshold provides certainty for users and developers
>>> - If fee markets change dramatically, a future soft fork could adjust
>>> the threshold
>>> - The ~4 year grace period allows the community to observe and adapt
>>>
>>> If Bitcoin's fee market evolves such that 999 sats becomes economically
>>> significant to spend, this would indicate broader success of the network;
>>> and the community could choose to lower or eliminate the threshold through
>>> a subsequent proposal.
>>>
>>> Acknowledgments
>>> This proposal builds on the problem identification in "The Cat"
>>> (Non-monetary UTXO Cleanup) while proposing a list-free alternative
>>> mechanism. The Cat correctly identifies UTXO bloat as a problem worth
>>> solving; Lynx offers a more neutral solution.
>>>
>>>
>>> https://x.com/matteopelleg/status/2000602318346334449
>>> On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
>>>
>>>> I received no prior response from you, so I suspect the issue is on
>>>> your end-- since if you sent one I would normally have been directly
>>>> copied.
>>>>
>>>> In any case, your message makes no sense. If an output is provably
>>>> unspendable then it is unspendable. No amount of "clever steganography"
>>>> can change that. If you're imagining that perhaps they are *presumed* to
>>>> be unspendable but actually *are* spendable, then sure that would be an
>>>> issue but with any change to consensus relevant code great care must be
>>>> taken to not introduce errors. Actually *making* a consensus change would
>>>> only increase the potential for mistakes.
>>>>
>>>> These costs are just another reason why this hysteria over a non-issue
>>>> is misplaced.
>>>>
>>>> But in any case it is better that (any) implementations that care about
>>>> stamps put in the effort to define their exclusions in ways that are safe
>>>> than to burden everyone with a consensus change that doesn't care about it.
>>>>
>>>>
>>>> On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98...@gmail.com> wrote:
>>>>
>>>>> This is my third attempt to respond to this. Idk what is going wrong
>>>>> here.
>>>>>
>>>>> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set
>>>>> without a consensus change is that a clever use of steganography could
>>>>> cause one of those otherwise unspendable outputs to be spendable, thus
>>>>> causing a fork between those nodes that adopted the Stamp pruning method
>>>>> and those that did not once one of those steganographic Stamps is spent.
>>>>> Though this is unlikely, it is still technically possible, and I would not
>>>>> put it past the denizens of the Internet to stir up trouble just for its
>>>>> own sake.
>>>>>
>>>>> On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
>>>>>
>>>>>> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Since the Bitcoin Stamps outputs are already unspendable, it makes
>>>>>>> perfect sense to mark and drop them from the UTXO set.
>>>>>>
>>>>>>
>>>>>> There is no consensus change involved in not storing a provably
>>>>>> unspendable output, it's just an implementation detail with no
>>>>>> interoperability implications and doesn't need a BIP. Bitcoin core has
>>>>>> long done so for several types of unspendable outputs, e.g. outputs over
>>>>>> 10kb and ones starting with OP_RETURN.
>>>>>>
>>>>>> --
>>>>> 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 email to bitcoindev+...@googlegroups.com.
>>>>>
>>>> To view this discussion visit
>>>>> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>> 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 email to bitcoindev+...@googlegroups.com.
>>>
>> To view this discussion visit
>>> https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c87a50a4-1a1b-4aee-bc1f-bd1c91d675d1n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 24895 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-30 14:36 ` Antoine Riard
@ 2026-01-19 1:11 ` Pepe Hodler
2026-01-23 3:45 ` Chris Riley
2026-01-23 13:55 ` Galois Field
2026-01-22 1:14 ` Claire Ostrom
1 sibling, 2 replies; 20+ messages in thread
From: Pepe Hodler @ 2026-01-19 1:11 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 26038 bytes --]
Hi list.
Which brings me to my disagreement, which I know is not shared by a number
of contributors here: just as it is hard to define spam on Bitcoin
I don't understand how anyone could be confused about the concept of spam
on bitcoin. Bitcoins is "A Peer-to-Peer Electronic Cash System" according
to the white paper. As such, anything not intended as a monetary
transaction is spam.
The use of fake pubkeys to store data on chain, that is an unsupported and
unsanctioned use of bitcoin. That is spam, and an attack, not a monetary
transaction.
Same with fake scripthash used to store arbitrary data, unsupported and
unsanctioned use of bitcoin. That is spam, and an attack, not a monetary
transaction.
And the same goes for the Segwit exploit and the Taproot exploit. That is
exploiting bitcoin to store arbitrary data in an unsanctioned way, spam, an
attack on bitcoin.
When Segwit and Taproot were implemented, nobody, absolutely nobody was
welcoming those upgrades as a way to store jpegs and other garbage on
chain. That is not what bitcoin, Segwit, and Taproot were built for.
If you are making use of OpenRelay and/or SlipStream to bypass the policy
of the majority of nodes, you are a spammer and an attacker, not a bitcoiner.
You are trying to skirt the only use case of bitcoin.
When there are blocks like this one:
https://mempool.space/block/00000000000000000000ed962f87a0c350b1401fe546db60e6d78e34ab549378 .
Over 60% of the transactions in that block are not sending or receiving a
single sat. It's all op_returns with no sats in them. That is not what
bitcoin was designed or sanctioned for.
These people are not users, they are attackers and spammers. How can you
look at inscriptions, runes, ordinals, fake pubkeys, fake scripthash,
stamps, and op_return with 0 sats in them and wonder if those are legit
bitcoin monetary transactions?
Now, some have tried to claim "My ordinal is a consensus valid
transaction". And of course it is, otherwise it would not have been added
to a block. But that's like saying the Nigerian prince email followed all
the SMTP and POP protocols of email, therefore it's not spam. Some spam
defenders have tried to claim they have paid their miner fee. Of course
they did, but that's like saying the sender of the Nigerian prince email
paid his internet, therefore it's not spam.
If you are confused about what constitutes spam on bitcoin, please explain.
While I'm sure there are some transactions that could be tricky and
controversial to identify as spam, I"m sure we can all agree that
inscriptions, stamps, jpegs, fake pubkeys, fake scripthash, unusually large
Segwit data, ordinals, runes, etc, are all clearly spam.
it's also very hard to define it in a discussion forum like this one.
I just did it, see above. It really wasn't that hard. How are you confused
about the definition of spam as it pertains to bitcoin? Because bitcoin is
money, they have to obfuscate their spam to make it look like a legitimate
monetary transaction to the system. So you could make the case that it's
harder to distinguish spam from a real monetary transaction. But defining
spam on it's own is pretty easy.
But ultimately, it does not belong to devs to decide what is spam. Don't
think that just because we know C++, that somehow gives us authority to
decide what direction bitcoin should be taking, and what spam is.
That decision belongs to the nodes. And it's clear that the nodes are not
given the tools to decide for themselves what spam is or what spam isn't,
with comprehensive user configurable spam filters.
Notions of motivation of contributors (such as they are paid by such and
such a company) should not be relevant.
Are you suggesting that conflict of interest is not a thing? If someone is
advocating against any and all measures against spam, I would really like
to know where their interests lie.
Everything should be open to discussion which is implementation-technical
(so obviously not e.g. threats of violence or things that bring legal
liability to participants or have zero relevance to Bitcoin's technical
development) even if it's philosophy-motivated. And blocking should be
reserved either as an anti-DOS measure if volume gets out of control, or if
it brings dangers as per the previous parenthetical.
This comes across as a thinly veiled attempt to censor anyone who wants to
combat spam, and their employees/employers. This idea of censoring
"confiscatory" proposals never came up when someone proposed confiscation
though what he called "demorage" or when someone proposed seizing Satoshi's
coin.
If you want to buy or sell pancakes, or JPEgs, or anything else for that
matter, bitcoin is here to serve you. But your pancakes and your JPEGs
don't belong on the bitcoin chain.
Disclaimer: I own bitcoin, I run a bitcoin business in El Salvador. I own
no inscriptions or spam of any kind, and I don't profit from any spam
related companies.
40% of the UTXO set is dust spam UTXOs that contains less than 0.0017% of
the total bitcoin issued. This constitutes an attack on bitcoin. I think we
all should start acknowledging the problem, and stop asking ourselves
dismissive questions like "What is spam anyways?" and use that question as
an excuse to pretend there is no problem.
Cheers, Pepe
On Tuesday, 30 December 2025 at 08:51:56 UTC-6 Antoine Riard wrote:
Hi list,
> Which brings me to my disagreement, which I know is not shared by a
number of contributors here: just as it is hard to define spam on Bitcoin,
it's also very hard to define it in a discussion forum like this one.
Making suggestions which *I* think are terrible, or detrimental, on a list
like this, should never be disallowed here. Notions of motivation of
contributors (such as they are paid by such and such a company) should not
be relevant. Everything should be open to discussion which is
implementation-technical (so obviously not e.g. threats of violence or
things that bring legal liability to participants or have zero relevance to
Bitcoin's technical development) even if it's philosophy-motivated. And
blocking should be reserved either as an anti-DOS measure if volume gets
out of control, or if it brings dangers as per the previous parenthetical.
I'm fully sharing waxwing reasonable opinion. While I can understand gmax's
sentiment being fed
up with poor coin confiscation proposals again and again on the mailing
list, the cure would be
worst than the disease. Maybe, I'm very voltairean here, but you don't
fight ill-founded opinions.
by persecuting their authors (--otherwise, down the road you take the risk
of seeing the bastille
popped up). Rather than you fight them back by doing the work to persuade
and to convince those
ideas you find stupid are indeed *objectively* stupid.
To me, it's a sign of strength and confidence that Bitcoin and its
development process can
withstand and endure the most "outrageous" controversies. For sure, I have
been enough times
in the shoes of someone who has to champion controversial changes (cf.
`mempoolfullrbf`) to not
negate that the strength of the process is kinda traded on the back of the
devs, but this is not
altering my mind on what I think should be *ideally* the development
process in terms of openess
and publicity.
My humble opinion only, as we said.
Best,
Antoine
OTS hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1ce
Le mercredi 24 décembre 2025 à 17:23:48 UTC, waxwing/ AdamISZ a écrit :
Hi Greg, list:
> I think the list should adopt a 1 year ban on parties *and their*
employer(s) (if known) for any coin confiscation proposal on the list going
forward (after, of course, making the rule clear on the signup page). It's
tiresome and beyond being a waste of time risks undermining public
confidence in Bitcoin to see the constant trickle of these
outrageous proposals in venues where they previously understood that
serious discussions were to be had. People are, of course, free to discuss
whatever ill-founded concepts they want but they're not entitled to the
time and the reputation of the participants here for offensively misguided
proposals.
I'm a huge agree-er with the motivation of this comment and a huge
disagree-er with the suggestion itself.
Actual confiscation, whatever the reason, hugely undermines Bitcoin's value
to humanity - note I am not saying its financial value, but value as a
project (and if we didn't see such value what the hell are we doing here).
Of course those two types of value are very closely linked, but they are
still distinct. I hold that same belief even when we are talking about
other suggestions of confiscation, such as to address a quantum threat -
something that has recently been discussed here, extensively.
Which brings me to my disagreement, which I know is not shared by a number
of contributors here: just as it is hard to define spam on Bitcoin, it's
also very hard to define it in a discussion forum like this one. Making
suggestions which *I* think are terrible, or detrimental, on a list like
this, should never be disallowed here. Notions of motivation of
contributors (such as they are paid by such and such a company) should not
be relevant. Everything should be open to discussion which is
implementation-technical (so obviously not e.g. threats of violence or
things that bring legal liability to participants or have zero relevance to
Bitcoin's technical development) even if it's philosophy-motivated. And
blocking should be reserved either as an anti-DOS measure if volume gets
out of control, or if it brings dangers as per the previous parenthetical.
Just my opinion of course, I know that moderation of lists is not a simple
matter.
Cheers,
AdamISZ/waxwing
On Tuesday, December 23, 2025 at 10:26:16 PM UTC-3 Greg Maxwell wrote:
The 'dust threshold' isn't a consensus parameter, it's just a number pulled
out of the air that didn't seem unreasonable based on average fee
behavior. But in any particular block transactions may need no particular
fee level at all, including zero fees. And in some cases it may be very
economically advantageous to spend an output even if its face value doesn't
support it, NFT's being a one such example (although one I consider pretty
dumb).
This proposal also appears to have ignored the prior discussion
particularly where it was pointed out that 'deleting' outputs will not
achieve the goal of deleting the tokens connected to them (so won't
eliminate the incentive), or that txouts which are predictably not going to
be accessed (as this proposal claims applies to the txouts it targets)
don't have as significant performance implications (because they don't need
to be cached in ram). It also appears to be uninformed by advances like
utxotree which makes the absolute size of the txout set much less
important, but would make mass removals such as that described
here expensive. Nor has it considered that given the level of fee spending
on NFT traffic a requirement to keep it over some (reasonable) threshold
would not likely discourage it, or the fact that existent NFT outputs are
generally over the dust limit in any case (so the proposals failure to meet
the opcat proponents' delusional goals is already clear).
I think the list should adopt a 1 year ban on parties *and their*
employer(s) (if known) for any coin confiscation proposal on the list going
forward (after, of course, making the rule clear on the signup page). It's
tiresome and beyond being a waste of time risks undermining public
confidence in Bitcoin to see the constant trickle of these
outrageous proposals in venues where they previously understood that
serious discussions were to be had. People are, of course, free to discuss
whatever ill-founded concepts they want but they're not entitled to the
time and the reputation of the participants here for offensively misguided
proposals.
On Tue, Dec 23, 2025 at 6:27 PM John <johnpenn...@gmail.com> wrote:
Good evening all,
Here is a related proposal by Matteo Pellegrini
@matteopelleg
Lynx.
Abstract
This proposal introduces a periodic, consensus-enforced mechanism for
rendering UTXOs below the network's dust threshold permanently unspendable.
At each halving block, UTXOs that have remained below the dust threshold
since the previous halving become unspendable. These UTXOs become
unspendable and may be pruned from the UTXO set entirely, reducing node
storage requirements and eliminating the economic model that incentivizes
their creation.
Motivation
The Bitcoin UTXO set has grown substantially due to various factors,
including inscription protocols, spam attacks, and general dust
accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO
Cleanup) by @ostrom72158
have attempted to address this by creating lists of specific UTXOs to
render unspendable, identified by external protocol indexers.
The Cat's approach has a fatal flaw: it relies on a list.
Using a curated list of "non-monetary UTXOs" introduces several problems:
1) External dependency: The Cat requires reference indexers (Ord, Stamps,
etc.) to define which UTXOs qualify. This introduces consensus-level
dependency on external, non-Bitcoin software that can change, have bugs, or
interpret protocols differently.
2) Protocol targeting: By specifically identifying inscription and stamp
outputs, the proposal makes subjective judgments about which Bitcoin uses
are legitimate. This sets a precedent for protocol-level discrimination.
3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes
workarounds. If Ordinals dust is targeted, protocols will adapt to create
dust that doesn't match the list criteria.
4) Static snapshot: A one-time list cleanup provides temporary relief but
does nothing for future UTXO accumulation.
5) Political vulnerability: Any list-based approach requires ongoing
governance decisions about what belongs on the list, creating a permanent
political attack surface.
A better approach targets the economic reality, not the use case.
UTXOs below the dust threshold are, by definition, economically irrational
to spend under normal fee conditions. The dust limit exists precisely
because spending these outputs costs more in fees than the output is worth.
These UTXOs are already "dead" in practice; this proposal simply makes that
reality explicit at the consensus layer.
By using a threshold rather than a list, Lynx:
- Requires no external indexers
- Makes no judgment about why a UTXO is small
- Applies equally to all participants
- Provides ongoing, predictable maintenance
- Removes political discretion from the process
Impact on Inscription Protocols
The typical Ordinals inscription is stored in a UTXO containing exactly 546
sats; the minimum required to meet the dust limit for P2PKH addresses and
ensure transferability across all address types. This "postage" amount is
standard across inscription tooling and marketplaces.
A threshold of 999 sats captures the vast majority of inscription UTXOs
without requiring any protocol-specific targeting. The economic model of
inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks
that model through neutral, threshold-based rules rather than list-based
discrimination.
Specification
Definitions
- Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is
subject to Lynx enforcement.
- Halving block: A block at height N * 210,000 where N ≥ 1.
- Snapshot block: A halving block at which the current dust threshold and
qualifying UTXOs are recorded.
- Enforcement block: The halving block following a snapshot block (i.e.,
snapshot block + 210,000 blocks).
Lynx UTXOs:
- Existed at the snapshot block
- Had a value less than 999 sats
- Remained unspent through the enforcement period (~4 years)
Consensus Rules
After activation, the following rules apply:
1) Snapshot: At each halving block H, record the set of all UTXOs with
value < 999 sats.
2) Enforcement: At halving block H + 210,000:
- Any UTXO that was in the snapshot set and remains unspent becomes
permanently unspendable
- Transactions attempting to spend these UTXOs are invalid
3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their local
UTXO set. Transactions referencing unknown outpoints are already rejected
as invalid; pruned Lynx UTXOs are simply treated as if they were already
spent.
4) Grace period: The ~4 year window between snapshot and enforcement
provides ample time for holders to consolidate sub-dust UTXOs if they wish
to preserve the value.
Activation
Activation method: TBD (Speedy Trial, BIP8, or other mechanism as
determined by community consensus)
Recommended first snapshot: The halving following activation lock-in
Rationale
Why a fixed threshold?
Using a fixed threshold of 999 sats rather than referencing the dynamic
relay dust limit provides:
- Simplicity: One number, no script-type variations, no need to query
policy settings
- Predictability: Everyone knows exactly what qualifies, forever
- Consensus clarity: No ambiguity about which outputs are affected.
Why tie to the halving?
The halving is Bitcoin's most recognized Schelling point, using it provides:
- Predictability: Everyone knows exactly when halvings occur
- Sufficient notice: ~4 years is generous warning for any cleanup action
- Aligned incentives: As block rewards decrease, fee revenue and UTXO
efficiency become more critical to network sustainability
- Natural cadence: The halving already represents a moment of network-wide
coordination
Why not a one-time cleanup?
A one-time cleanup (as proposed by The Cat) provides temporary relief but
creates no ongoing pressure against dust accumulation. Periodic enforcement:
- Establishes a permanent, predictable norm
- Removes any expectation that dust UTXOs have indefinite longevity
- Discourages business models built on dust creation
- Provides continuous UTXO set maintenance
Why pruning works without a list
A key insight enables pruning without maintaining a separate list: Bitcoin
nodes already reject transactions that reference unknown outpoints. When a
node receives a transaction spending an outpoint not in its UTXO set, it
rejects it as invalid — the node doesn't need to know why the outpoint is
missing (spent? never existed? pruned?).
After enforcement, a Lynx UTXO is functionally equivalent to a spent
output. Nodes can simply delete it from the UTXO set. Any future
transaction attempting to spend it will reference an outpoint the node
doesn't recognize, and will be rejected through existing validation logic.
This means:
- No separate "Lynx list" is required
- No new validation logic is needed
- Pruning is optional; nodes MAY keep Lynx UTXOs if they wish
- The UTXO set shrinks naturally as nodes prune
Why 999 sats?
The threshold of 999 sats is chosen because:
- Above all dust limits: Captures UTXOs at or below the dust limit for all
script types (P2PKH: 546, P2TR: 330, etc.)
- Captures all standard inscriptions: Typical inscription UTXOs contain
exactly 546 sats as "postage"; well under 999
- Simple and memorable: A clean number that's easy to communicate and
reason about
Backward Compatibility
This is a soft fork. Nodes that do not upgrade will:
- Continue to consider all historical transactions valid
- Accept blocks that exclude spends of Lynx UTXOs
- Eventually converge with upgraded nodes (as upgraded miners will not
include invalid spends)
Wallets & Services should:
- Warn users holding sub-threshold UTXOs after a snapshot block
- Provide consolidation tools during the grace period
- Update UTXO selection algorithms to deprioritize or exclude sub-threshold
outputs approaching a snapshot
Security Considerations
No confiscation
This proposal does not transfer value to any party. Sub-threshold UTXOs
become unspendable, similar to:
- Lost private keys
- Provably unspendable OP_RETURN outputs
- Satoshi's untouched coinbase rewards
The bitcoin supply cap remains unchanged; the affected outputs simply
become irrecoverable. Holders receive ~4 years notice to consolidate if
they value the sats.
Lightning Network
Some Lightning implementations create small HTLCs and dust outputs during
channel operations. Analysis is needed to determine:
- Whether current dust thresholds affect normal LN operations
- If LN implementations need adjustment before activation
- Whether channel close scenarios create sub-threshold outputs
Preliminary assessment: LN dust limits are already set conservatively above
relay dust limits, so impact should be minimal. However, this requires
verification from LN implementers.
Fixed threshold vs. future fee markets
The 999 satoshi threshold is fixed in consensus rules and does not adjust
based on fee market conditions.
This is intentional:
- A fixed threshold provides certainty for users and developers
- If fee markets change dramatically, a future soft fork could adjust the
threshold
- The ~4 year grace period allows the community to observe and adapt
If Bitcoin's fee market evolves such that 999 sats becomes economically
significant to spend, this would indicate broader success of the network;
and the community could choose to lower or eliminate the threshold through
a subsequent proposal.
Acknowledgments
This proposal builds on the problem identification in "The Cat"
(Non-monetary UTXO Cleanup) while proposing a list-free alternative
mechanism. The Cat correctly identifies UTXO bloat as a problem worth
solving; Lynx offers a more neutral solution.
https://x.com/matteopelleg/status/2000602318346334449
On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
I received no prior response from you, so I suspect the issue is on your
end-- since if you sent one I would normally have been directly copied.
In any case, your message makes no sense. If an output is provably
unspendable then it is unspendable. No amount of "clever steganography"
can change that. If you're imagining that perhaps they are *presumed* to
be unspendable but actually *are* spendable, then sure that would be an
issue but with any change to consensus relevant code great care must be
taken to not introduce errors. Actually *making* a consensus change would
only increase the potential for mistakes.
These costs are just another reason why this hysteria over a non-issue is
misplaced.
But in any case it is better that (any) implementations that care about
stamps put in the effort to define their exclusions in ways that are safe
than to burden everyone with a consensus change that doesn't care about it.
On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98...@gmail.com> wrote:
This is my third attempt to respond to this. Idk what is going wrong here.
The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without a
consensus change is that a clever use of steganography could cause one of
those otherwise unspendable outputs to be spendable, thus causing a fork
between those nodes that adopted the Stamp pruning method and those that
did not once one of those steganographic Stamps is spent. Though this is
unlikely, it is still technically possible, and I would not put it past the
denizens of the Internet to stir up trouble just for its own sake.
On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com> wrote:
Since the Bitcoin Stamps outputs are already unspendable, it makes perfect
sense to mark and drop them from the UTXO set.
There is no consensus change involved in not storing a provably unspendable
output, it's just an implementation detail with no interoperability
implications and doesn't need a BIP. Bitcoin core has long done so for
several types of unspendable outputs, e.g. outputs over 10kb and ones
starting with OP_RETURN.
--
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
email to bitcoindev+...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
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
email to bitcoindev+...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/cf39fdca-e996-43be-ab52-573aedd619d5n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 32530 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2025-12-30 14:36 ` Antoine Riard
2026-01-19 1:11 ` Pepe Hodler
@ 2026-01-22 1:14 ` Claire Ostrom
1 sibling, 0 replies; 20+ messages in thread
From: Claire Ostrom @ 2026-01-22 1:14 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 30685 bytes --]
Hi list,
I’m reposting the reply below that I wrote on Dec 11. I later discovered I
had accidentally emailed it directly to Greg instead of sending it to the
list, and I wrongly inferred that it was being blocked. I then made public
comments implying censorship, an embarrassing mistake that was entirely my
own.
My apologies to the moderators, Greg, and anyone misled by that. I’m
participating in good faith and want to keep the focus on the technical
merits.
Here is the message as originally sent:
Hi Greg,
When you say I misunderstood your quote, are you referring to the notion
that you thought we should try to shape behavior? You also said your reason
for caring about motivation in the first place was because you didn't want
to give the wrong impression about what was "kosher". Both you and Sipa
(who also stated in that thread "The problem is that people may see this as
a legitimation of the storage in the first place, and encourage doing so
even more.") seemed to be primarily motivated by the social signals that
would be sent by allowing even a small amount of data to be used
arbitrarily in the protocol, but felt (from my reading) that it may be
worth the trade-off for, as you said, shaping users to more conservative
needs.
I certainly appreciate your larger point here, where you state that current
use has nullified previously effective means of curbing this behavior, and
as you say, sometimes even further increasing it. This is precisely why my
proposal exists as it does. It acknowledges that these attempts to "stop"
the behavior are not effective against strong financial incentives to
overcome them. They would also eventually lead to more harmful abuse;
typically this filter discussion lands at the threat of fake pubkey use,
which has generally been seen as the most harmful way to include data in
the system.
My proposal attempts to destroy trust in those markets, to reduce the
desire to spam in the first place.
*"Were such a proposal seriously 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 marketing opportunity for the NFT gifters). NFTs are just an
imaginary parallel world that don't depend on the network to validate their
activity, so they don't really care about the network's rules, and as such
the network's rules have pretty limited effect. "*
I understand why you feel that way, but this is not the only way to look at
it, and I'm glad we're able to have this discussion. I am not so naive
about the behavior of these communities and have some experience with them
in the past. You're right: every crypto asset is essentially a narrative.
Where I feel you don't give me enough credit is when you dismiss that the
buyers of those narratives are apathetic towards them. One of the largest
debates in the ordinal world was the value that the actual numbering system
should have at all. The entire point of ordinal theory is that they number
and value specific satoshi as non-fungible assets themselves. To suggest
that they would be content to assign a new satoshi with their key, I think,
underestimates how sentimental they are about their rules. It may seem like
a silly delusion, but they obviously value them or they wouldn't spend so
much on them.
I think this would be a very effective measure against the types of trends
we are seeing today, and materially reduce the UTXO set either way.
*"The proposed gain is some negligible one time reduction in utxo disk
space. You motivated it by claiming this is a 'memory usage' reduction, but
it's not-- it's just full node storage in particular as the txouts in
question are normally sized and largely quiescent already-- so the savings
is pretty insignificant. "*
I have a lot to learn, because reading this is a significant challenge to
my worldview. I have been under the impression that bloat to the live state
(chainstate) is one of the most harmful aspects of things like the
fakepubkey threat. This becomes more nuanced when we think of future
implementations that don't have a separate chainstate at all, but ignoring
those, one of the central reasons stated for removing the recent OP_RETURN
limits was to reduce potential UTXO bloat from applications like Citrea.
There are several proposals now to address this bloat, and this is the
first time I'm hearing someone consider 40% of the current state to be a
*negligible *amount.
*"And moreover the proposal would intentionally and knowingly confiscate
millions of dollars in funds. This is outright theft, and I believe it
makes the idea a total non-starter."*
Millions of dollars certainly seems like a lot of money, but these UTXOs
are less than $1 on average. It is only due to the massive size of the
stated problem that they collectively represent such a significant amount
of funds. It's my contention that the users of these satoshi are not
intending to use them for their satoshi value whatsoever. They are simply
using these as data points tracked in a database to facilitate a gambling
trend.
I don't say that to judge the behavior for moral reasons, but to highlight
an abuse of the incentives in the Bitcoin network. The defense against dust
spam in Bitcoin is the use of a fee market. This is a very effective
incentive that makes it expensive and usually pointless to create a lot of
smaller UTXOs rather than a few large ones. The problem with the abuse we
see from schemes like ord is that they ignore this dynamic by adding an
external incentive that pays much more than the satoshi themselves are
worth, sidestepping the filter and creating a dynamic that was never
imagined by the design.
As an open system, this kind of abuse is hard to stop once it starts. My
proposal stands as a way to address it and add new dynamics that aim to
reduce the demand for such behavior by understanding it and addressing it
in a way specific to its creation, which is to destroy trust in the markets
that cause them. I presume you would not even be okay with the potential
burning of a single satoshi even if it meant clearing up something people
felt was a material problem to the network, so of course you'll certainly
take issue with this. It is thanks in part to your uncompromising culture
that protects what Bitcoin is in the first place.
*"As an aside, since the idea fails so easily on basic principled grounds
it's a disrespectful waste of participants time to advance a proposal at
such length and *technobabbly* depth 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 making
spending them consensus invalid?" or similar. Much 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 obscure 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."*
This is a very fair point; in hindsight I feel my proposal was much too
detailed for this stage of discussion. To be honest, I felt intimidated
proposing to this list and wanted to be sure that I had put in enough work
to demonstrate the seriousness of my idea. I think I could have done it
with a summary that linked to additional details instead.
I did not use an LLM to create my proposal, though I do use LLMs as a tool
for research and occasional formatting. I do not think LLMs should be used
in place of human ideas. My proposal was written by me (and the friends who
helped me) in every part, and only edited for style or grammar by a machine.
On Tuesday, December 30, 2025 at 9:51:56 AM UTC-5 Antoine Riard wrote:
> Hi list,
>
> > Which brings me to my disagreement, which I know is not shared by a
> number of contributors here: just as it is hard to define spam on Bitcoin,
> it's also very hard to define it in a discussion forum like this one.
> Making suggestions which *I* think are terrible, or detrimental, on a list
> like this, should never be disallowed here. Notions of motivation of
> contributors (such as they are paid by such and such a company) should not
> be relevant. Everything should be open to discussion which is
> implementation-technical (so obviously not e.g. threats of violence or
> things that bring legal liability to participants or have zero relevance to
> Bitcoin's technical development) even if it's philosophy-motivated. And
> blocking should be reserved either as an anti-DOS measure if volume gets
> out of control, or if it brings dangers as per the previous parenthetical.
>
> I'm fully sharing waxwing reasonable opinion. While I can understand
> gmax's sentiment being fed
> up with poor coin confiscation proposals again and again on the mailing
> list, the cure would be
> worst than the disease. Maybe, I'm very voltairean here, but you don't
> fight ill-founded opinions.
> by persecuting their authors (--otherwise, down the road you take the risk
> of seeing the bastille
> popped up). Rather than you fight them back by doing the work to persuade
> and to convince those
> ideas you find stupid are indeed *objectively* stupid.
>
> To me, it's a sign of strength and confidence that Bitcoin and its
> development process can
> withstand and endure the most "outrageous" controversies. For sure, I have
> been enough times
> in the shoes of someone who has to champion controversial changes (cf.
> `mempoolfullrbf`) to not
> negate that the strength of the process is kinda traded on the back of the
> devs, but this is not
> altering my mind on what I think should be *ideally* the development
> process in terms of openess
> and publicity.
>
> My humble opinion only, as we said.
>
> Best,
> Antoine
> OTS hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1ce
> Le mercredi 24 décembre 2025 à 17:23:48 UTC, waxwing/ AdamISZ a écrit :
>
>> Hi Greg, list:
>>
>> > I think the list should adopt a 1 year ban on parties *and their*
>> employer(s) (if known) for any coin confiscation proposal on the list going
>> forward (after, of course, making the rule clear on the signup page). It's
>> tiresome and beyond being a waste of time risks undermining public
>> confidence in Bitcoin to see the constant trickle of these
>> outrageous proposals in venues where they previously understood that
>> serious discussions were to be had. People are, of course, free to discuss
>> whatever ill-founded concepts they want but they're not entitled to the
>> time and the reputation of the participants here for offensively misguided
>> proposals.
>>
>> I'm a huge agree-er with the motivation of this comment and a huge
>> disagree-er with the suggestion itself.
>>
>> Actual confiscation, whatever the reason, hugely undermines Bitcoin's
>> value to humanity - note I am not saying its financial value, but value as
>> a project (and if we didn't see such value what the hell are we doing
>> here). Of course those two types of value are very closely linked, but they
>> are still distinct. I hold that same belief even when we are talking about
>> other suggestions of confiscation, such as to address a quantum threat -
>> something that has recently been discussed here, extensively.
>>
>> Which brings me to my disagreement, which I know is not shared by a
>> number of contributors here: just as it is hard to define spam on Bitcoin,
>> it's also very hard to define it in a discussion forum like this one.
>> Making suggestions which *I* think are terrible, or detrimental, on a list
>> like this, should never be disallowed here. Notions of motivation of
>> contributors (such as they are paid by such and such a company) should not
>> be relevant. Everything should be open to discussion which is
>> implementation-technical (so obviously not e.g. threats of violence or
>> things that bring legal liability to participants or have zero relevance to
>> Bitcoin's technical development) even if it's philosophy-motivated. And
>> blocking should be reserved either as an anti-DOS measure if volume gets
>> out of control, or if it brings dangers as per the previous parenthetical.
>>
>> Just my opinion of course, I know that moderation of lists is not a
>> simple matter.
>>
>> Cheers,
>> AdamISZ/waxwing
>> On Tuesday, December 23, 2025 at 10:26:16 PM UTC-3 Greg Maxwell wrote:
>>
>>> The 'dust threshold' isn't a consensus parameter, it's just a number
>>> pulled out of the air that didn't seem unreasonable based on average fee
>>> behavior. But in any particular block transactions may need no particular
>>> fee level at all, including zero fees. And in some cases it may be very
>>> economically advantageous to spend an output even if its face value doesn't
>>> support it, NFT's being a one such example (although one I consider pretty
>>> dumb).
>>>
>>> This proposal also appears to have ignored the prior discussion
>>> particularly where it was pointed out that 'deleting' outputs will not
>>> achieve the goal of deleting the tokens connected to them (so won't
>>> eliminate the incentive), or that txouts which are predictably not going to
>>> be accessed (as this proposal claims applies to the txouts it targets)
>>> don't have as significant performance implications (because they don't need
>>> to be cached in ram). It also appears to be uninformed by advances like
>>> utxotree which makes the absolute size of the txout set much less
>>> important, but would make mass removals such as that described
>>> here expensive. Nor has it considered that given the level of fee spending
>>> on NFT traffic a requirement to keep it over some (reasonable) threshold
>>> would not likely discourage it, or the fact that existent NFT outputs are
>>> generally over the dust limit in any case (so the proposals failure to meet
>>> the opcat proponents' delusional goals is already clear).
>>>
>>> I think the list should adopt a 1 year ban on parties *and their*
>>> employer(s) (if known) for any coin confiscation proposal on the list going
>>> forward (after, of course, making the rule clear on the signup page). It's
>>> tiresome and beyond being a waste of time risks undermining public
>>> confidence in Bitcoin to see the constant trickle of these
>>> outrageous proposals in venues where they previously understood that
>>> serious discussions were to be had. People are, of course, free to discuss
>>> whatever ill-founded concepts they want but they're not entitled to the
>>> time and the reputation of the participants here for offensively misguided
>>> proposals.
>>>
>>>
>>> On Tue, Dec 23, 2025 at 6:27 PM John <johnpenn...@gmail.com> wrote:
>>>
>>>> Good evening all,
>>>>
>>>> Here is a related proposal by Matteo Pellegrini
>>>> @matteopelleg
>>>>
>>>>
>>>>
>>>> Lynx.
>>>>
>>>> Abstract
>>>> This proposal introduces a periodic, consensus-enforced mechanism for
>>>> rendering UTXOs below the network's dust threshold permanently unspendable.
>>>> At each halving block, UTXOs that have remained below the dust threshold
>>>> since the previous halving become unspendable. These UTXOs become
>>>> unspendable and may be pruned from the UTXO set entirely, reducing node
>>>> storage requirements and eliminating the economic model that incentivizes
>>>> their creation.
>>>>
>>>> Motivation
>>>> The Bitcoin UTXO set has grown substantially due to various factors,
>>>> including inscription protocols, spam attacks, and general dust
>>>> accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO
>>>> Cleanup) by @ostrom72158
>>>> have attempted to address this by creating lists of specific UTXOs to
>>>> render unspendable, identified by external protocol indexers.
>>>>
>>>> The Cat's approach has a fatal flaw: it relies on a list.
>>>>
>>>> Using a curated list of "non-monetary UTXOs" introduces several
>>>> problems:
>>>>
>>>> 1) External dependency: The Cat requires reference indexers (Ord,
>>>> Stamps, etc.) to define which UTXOs qualify. This introduces
>>>> consensus-level dependency on external, non-Bitcoin software that can
>>>> change, have bugs, or interpret protocols differently.
>>>>
>>>> 2) Protocol targeting: By specifically identifying inscription and
>>>> stamp outputs, the proposal makes subjective judgments about which Bitcoin
>>>> uses are legitimate. This sets a precedent for protocol-level
>>>> discrimination.
>>>>
>>>> 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes
>>>> workarounds. If Ordinals dust is targeted, protocols will adapt to create
>>>> dust that doesn't match the list criteria.
>>>>
>>>> 4) Static snapshot: A one-time list cleanup provides temporary relief
>>>> but does nothing for future UTXO accumulation.
>>>>
>>>> 5) Political vulnerability: Any list-based approach requires ongoing
>>>> governance decisions about what belongs on the list, creating a permanent
>>>> political attack surface.
>>>>
>>>> A better approach targets the economic reality, not the use case.
>>>>
>>>> UTXOs below the dust threshold are, by definition, economically
>>>> irrational to spend under normal fee conditions. The dust limit exists
>>>> precisely because spending these outputs costs more in fees than the output
>>>> is worth. These UTXOs are already "dead" in practice; this proposal simply
>>>> makes that reality explicit at the consensus layer.
>>>>
>>>> By using a threshold rather than a list, Lynx:
>>>>
>>>> - Requires no external indexers
>>>> - Makes no judgment about why a UTXO is small
>>>> - Applies equally to all participants
>>>> - Provides ongoing, predictable maintenance
>>>> - Removes political discretion from the process
>>>>
>>>> Impact on Inscription Protocols
>>>>
>>>> The typical Ordinals inscription is stored in a UTXO containing exactly
>>>> 546 sats; the minimum required to meet the dust limit for P2PKH addresses
>>>> and ensure transferability across all address types. This "postage" amount
>>>> is standard across inscription tooling and marketplaces.
>>>>
>>>> A threshold of 999 sats captures the vast majority of inscription UTXOs
>>>> without requiring any protocol-specific targeting. The economic model of
>>>> inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks
>>>> that model through neutral, threshold-based rules rather than list-based
>>>> discrimination.
>>>>
>>>> Specification
>>>>
>>>> Definitions
>>>>
>>>> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats
>>>> is subject to Lynx enforcement.
>>>>
>>>> - Halving block: A block at height N * 210,000 where N ≥ 1.
>>>>
>>>> - Snapshot block: A halving block at which the current dust threshold
>>>> and qualifying UTXOs are recorded.
>>>>
>>>> - Enforcement block: The halving block following a snapshot block
>>>> (i.e., snapshot block + 210,000 blocks).
>>>>
>>>> Lynx UTXOs:
>>>> - Existed at the snapshot block
>>>> - Had a value less than 999 sats
>>>> - Remained unspent through the enforcement period (~4 years)
>>>>
>>>> Consensus Rules
>>>> After activation, the following rules apply:
>>>>
>>>> 1) Snapshot: At each halving block H, record the set of all UTXOs with
>>>> value < 999 sats.
>>>>
>>>> 2) Enforcement: At halving block H + 210,000:
>>>> - Any UTXO that was in the snapshot set and remains unspent becomes
>>>> permanently unspendable
>>>> - Transactions attempting to spend these UTXOs are invalid
>>>>
>>>> 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their
>>>> local UTXO set. Transactions referencing unknown outpoints are already
>>>> rejected as invalid; pruned Lynx UTXOs are simply treated as if they were
>>>> already spent.
>>>>
>>>> 4) Grace period: The ~4 year window between snapshot and enforcement
>>>> provides ample time for holders to consolidate sub-dust UTXOs if they wish
>>>> to preserve the value.
>>>>
>>>> Activation
>>>>
>>>> Activation method: TBD (Speedy Trial, BIP8, or other mechanism as
>>>> determined by community consensus)
>>>>
>>>> Recommended first snapshot: The halving following activation lock-in
>>>>
>>>> Rationale
>>>>
>>>> Why a fixed threshold?
>>>>
>>>> Using a fixed threshold of 999 sats rather than referencing the dynamic
>>>> relay dust limit provides:
>>>>
>>>> - Simplicity: One number, no script-type variations, no need to query
>>>> policy settings
>>>>
>>>> - Predictability: Everyone knows exactly what qualifies, forever
>>>>
>>>> - Consensus clarity: No ambiguity about which outputs are affected.
>>>>
>>>> Why tie to the halving?
>>>>
>>>> The halving is Bitcoin's most recognized Schelling point, using it
>>>> provides:
>>>>
>>>> - Predictability: Everyone knows exactly when halvings occur
>>>> - Sufficient notice: ~4 years is generous warning for any cleanup action
>>>> - Aligned incentives: As block rewards decrease, fee revenue and UTXO
>>>> efficiency become more critical to network sustainability
>>>> - Natural cadence: The halving already represents a moment of
>>>> network-wide coordination
>>>>
>>>> Why not a one-time cleanup?
>>>>
>>>> A one-time cleanup (as proposed by The Cat) provides temporary relief
>>>> but creates no ongoing pressure against dust accumulation. Periodic
>>>> enforcement:
>>>>
>>>> - Establishes a permanent, predictable norm
>>>> - Removes any expectation that dust UTXOs have indefinite longevity
>>>> - Discourages business models built on dust creation
>>>> - Provides continuous UTXO set maintenance
>>>>
>>>> Why pruning works without a list
>>>>
>>>> A key insight enables pruning without maintaining a separate list:
>>>> Bitcoin nodes already reject transactions that reference unknown outpoints.
>>>> When a node receives a transaction spending an outpoint not in its UTXO
>>>> set, it rejects it as invalid — the node doesn't need to know why the
>>>> outpoint is missing (spent? never existed? pruned?).
>>>>
>>>> After enforcement, a Lynx UTXO is functionally equivalent to a spent
>>>> output. Nodes can simply delete it from the UTXO set. Any future
>>>> transaction attempting to spend it will reference an outpoint the node
>>>> doesn't recognize, and will be rejected through existing validation logic.
>>>>
>>>> This means:
>>>>
>>>> - No separate "Lynx list" is required
>>>> - No new validation logic is needed
>>>> - Pruning is optional; nodes MAY keep Lynx UTXOs if they wish
>>>> - The UTXO set shrinks naturally as nodes prune
>>>>
>>>> Why 999 sats?
>>>>
>>>> The threshold of 999 sats is chosen because:
>>>>
>>>> - Above all dust limits: Captures UTXOs at or below the dust limit for
>>>> all script types (P2PKH: 546, P2TR: 330, etc.)
>>>> - Captures all standard inscriptions: Typical inscription UTXOs contain
>>>> exactly 546 sats as "postage"; well under 999
>>>> - Simple and memorable: A clean number that's easy to communicate and
>>>> reason about
>>>>
>>>> Backward Compatibility
>>>>
>>>> This is a soft fork. Nodes that do not upgrade will:
>>>>
>>>> - Continue to consider all historical transactions valid
>>>> - Accept blocks that exclude spends of Lynx UTXOs
>>>> - Eventually converge with upgraded nodes (as upgraded miners will not
>>>> include invalid spends)
>>>>
>>>> Wallets & Services should:
>>>>
>>>> - Warn users holding sub-threshold UTXOs after a snapshot block
>>>> - Provide consolidation tools during the grace period
>>>> - Update UTXO selection algorithms to deprioritize or exclude
>>>> sub-threshold outputs approaching a snapshot
>>>>
>>>> Security Considerations
>>>>
>>>> No confiscation
>>>>
>>>> This proposal does not transfer value to any party. Sub-threshold UTXOs
>>>> become unspendable, similar to:
>>>>
>>>> - Lost private keys
>>>> - Provably unspendable OP_RETURN outputs
>>>> - Satoshi's untouched coinbase rewards
>>>>
>>>> The bitcoin supply cap remains unchanged; the affected outputs simply
>>>> become irrecoverable. Holders receive ~4 years notice to consolidate if
>>>> they value the sats.
>>>>
>>>> Lightning Network
>>>>
>>>> Some Lightning implementations create small HTLCs and dust outputs
>>>> during channel operations. Analysis is needed to determine:
>>>>
>>>> - Whether current dust thresholds affect normal LN operations
>>>> - If LN implementations need adjustment before activation
>>>> - Whether channel close scenarios create sub-threshold outputs
>>>>
>>>> Preliminary assessment: LN dust limits are already set conservatively
>>>> above relay dust limits, so impact should be minimal. However, this
>>>> requires verification from LN implementers.
>>>>
>>>> Fixed threshold vs. future fee markets
>>>>
>>>> The 999 satoshi threshold is fixed in consensus rules and does not
>>>> adjust based on fee market conditions.
>>>> This is intentional:
>>>>
>>>> - A fixed threshold provides certainty for users and developers
>>>> - If fee markets change dramatically, a future soft fork could adjust
>>>> the threshold
>>>> - The ~4 year grace period allows the community to observe and adapt
>>>>
>>>> If Bitcoin's fee market evolves such that 999 sats becomes economically
>>>> significant to spend, this would indicate broader success of the network;
>>>> and the community could choose to lower or eliminate the threshold through
>>>> a subsequent proposal.
>>>>
>>>> Acknowledgments
>>>> This proposal builds on the problem identification in "The Cat"
>>>> (Non-monetary UTXO Cleanup) while proposing a list-free alternative
>>>> mechanism. The Cat correctly identifies UTXO bloat as a problem worth
>>>> solving; Lynx offers a more neutral solution.
>>>>
>>>>
>>>> https://x.com/matteopelleg/status/2000602318346334449
>>>> On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
>>>>
>>>>> I received no prior response from you, so I suspect the issue is on
>>>>> your end-- since if you sent one I would normally have been directly
>>>>> copied.
>>>>>
>>>>> In any case, your message makes no sense. If an output is provably
>>>>> unspendable then it is unspendable. No amount of "clever steganography"
>>>>> can change that. If you're imagining that perhaps they are *presumed* to
>>>>> be unspendable but actually *are* spendable, then sure that would be an
>>>>> issue but with any change to consensus relevant code great care must be
>>>>> taken to not introduce errors. Actually *making* a consensus change would
>>>>> only increase the potential for mistakes.
>>>>>
>>>>> These costs are just another reason why this hysteria over a non-issue
>>>>> is misplaced.
>>>>>
>>>>> But in any case it is better that (any) implementations that care
>>>>> about stamps put in the effort to define their exclusions in ways that are
>>>>> safe than to burden everyone with a consensus change that doesn't care
>>>>> about it.
>>>>>
>>>>>
>>>>> On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> This is my third attempt to respond to this. Idk what is going wrong
>>>>>> here.
>>>>>>
>>>>>> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set
>>>>>> without a consensus change is that a clever use of steganography could
>>>>>> cause one of those otherwise unspendable outputs to be spendable, thus
>>>>>> causing a fork between those nodes that adopted the Stamp pruning method
>>>>>> and those that did not once one of those steganographic Stamps is spent.
>>>>>> Though this is unlikely, it is still technically possible, and I would not
>>>>>> put it past the denizens of the Internet to stir up trouble just for its
>>>>>> own sake.
>>>>>>
>>>>>> On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
>>>>>>
>>>>>>> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Since the Bitcoin Stamps outputs are already unspendable, it makes
>>>>>>>> perfect sense to mark and drop them from the UTXO set.
>>>>>>>
>>>>>>>
>>>>>>> There is no consensus change involved in not storing a provably
>>>>>>> unspendable output, it's just an implementation detail with no
>>>>>>> interoperability implications and doesn't need a BIP. Bitcoin core has
>>>>>>> long done so for several types of unspendable outputs, e.g. outputs over
>>>>>>> 10kb and ones starting with OP_RETURN.
>>>>>>>
>>>>>>> --
>>>>>> 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 email to bitcoindev+...@googlegroups.com.
>>>>>>
>>>>> To view this discussion visit
>>>>>> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>> 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 email to bitcoindev+...@googlegroups.com.
>>>>
>>> To view this discussion visit
>>>> https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/521249b0-a9a8-4fc1-b975-c6c80b8ddb01n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 33778 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2026-01-19 1:11 ` Pepe Hodler
@ 2026-01-23 3:45 ` Chris Riley
2026-01-23 13:55 ` Galois Field
1 sibling, 0 replies; 20+ messages in thread
From: Chris Riley @ 2026-01-23 3:45 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 28809 bytes --]
Hi,
The issue with defining all non-monetary data as spam is that it eliminates
functionality Bitcoin has relied on since inception. Bitcoin was designed
from v0.1 as a distributed timestamp server and ordering system, not solely
as a payment processor. The genesis block contains non-monetary data, and
early Proof-of-Existence uses pre-dated OP_RETURN.
Time-locked contracts (nLockTime) have existed since v0.1 and underpin
CLTV/CSV-based constructions, including the Lightning Network, DLCs, and
off-chain adjudication. Sidechain anchoring and systems like
OpenTimestamps depend
on Bitcoin’s immutability as a distributed order of events. Protocol
upgrades themselves rely on non-monetary signaling via version bits and
miner flags.
As stated in the whitepaper, the proof-of-work chain is a solution to
distributed timestamping and majority decision-making. Monetary
transactions depend on this ordering. If all non-monetary data is defined
as spam, Bitcoin cannot function as Bitcoin. The opcodes in v0.1 clearly
show that it was intended to do more than "Send X from A->B"-and they
weren't disabled due to philosophical opposition, but DOS, consensus etc
concerns. Please note, this does not imply that bulk data storage belongs
on L1, merely that "spam is easy to define as anything non-monetary" isn't
as easy as one might think.
Have a good one :-)
On Thu, Jan 22, 2026 at 4:54 PM Pepe Hodler <pepehodler@gmail.com> wrote:
> Hi list.
>
> Which brings me to my disagreement, which I know is not shared by a number
> of contributors here: just as it is hard to define spam on Bitcoin
>
> I don't understand how anyone could be confused about the concept of spam
> on bitcoin. Bitcoins is "A Peer-to-Peer Electronic Cash System" according
> to the white paper. As such, anything not intended as a monetary
> transaction is spam.
>
> The use of fake pubkeys to store data on chain, that is an unsupported and
> unsanctioned use of bitcoin. That is spam, and an attack, not a monetary
> transaction.
>
> Same with fake scripthash used to store arbitrary data, unsupported and
> unsanctioned use of bitcoin. That is spam, and an attack, not a monetary
> transaction.
>
> And the same goes for the Segwit exploit and the Taproot exploit. That is
> exploiting bitcoin to store arbitrary data in an unsanctioned way, spam, an
> attack on bitcoin.
>
> When Segwit and Taproot were implemented, nobody, absolutely nobody was
> welcoming those upgrades as a way to store jpegs and other garbage on
> chain. That is not what bitcoin, Segwit, and Taproot were built for.
>
> If you are making use of OpenRelay and/or SlipStream to bypass the policy
> of the majority of nodes, you are a spammer and an attacker, not a bitcoiner.
> You are trying to skirt the only use case of bitcoin.
>
> When there are blocks like this one:
> https://mempool.space/block/00000000000000000000ed962f87a0c350b1401fe546db60e6d78e34ab549378 .
> Over 60% of the transactions in that block are not sending or receiving a
> single sat. It's all op_returns with no sats in them. That is not what
> bitcoin was designed or sanctioned for.
>
> These people are not users, they are attackers and spammers. How can you
> look at inscriptions, runes, ordinals, fake pubkeys, fake scripthash,
> stamps, and op_return with 0 sats in them and wonder if those are legit
> bitcoin monetary transactions?
> Now, some have tried to claim "My ordinal is a consensus valid
> transaction". And of course it is, otherwise it would not have been added
> to a block. But that's like saying the Nigerian prince email followed all
> the SMTP and POP protocols of email, therefore it's not spam. Some spam
> defenders have tried to claim they have paid their miner fee. Of course
> they did, but that's like saying the sender of the Nigerian prince email
> paid his internet, therefore it's not spam.
>
> If you are confused about what constitutes spam on bitcoin, please
> explain. While I'm sure there are some transactions that could be tricky
> and controversial to identify as spam, I"m sure we can all agree that
> inscriptions, stamps, jpegs, fake pubkeys, fake scripthash, unusually large
> Segwit data, ordinals, runes, etc, are all clearly spam.
>
> it's also very hard to define it in a discussion forum like this one.
>
>
> I just did it, see above. It really wasn't that hard. How are you confused
> about the definition of spam as it pertains to bitcoin? Because bitcoin is
> money, they have to obfuscate their spam to make it look like a legitimate
> monetary transaction to the system. So you could make the case that it's
> harder to distinguish spam from a real monetary transaction. But defining
> spam on it's own is pretty easy.
>
> But ultimately, it does not belong to devs to decide what is spam. Don't
> think that just because we know C++, that somehow gives us authority to
> decide what direction bitcoin should be taking, and what spam is.
>
> That decision belongs to the nodes. And it's clear that the nodes are not
> given the tools to decide for themselves what spam is or what spam isn't,
> with comprehensive user configurable spam filters.
>
> Notions of motivation of contributors (such as they are paid by such and
> such a company) should not be relevant.
>
>
> Are you suggesting that conflict of interest is not a thing? If someone is
> advocating against any and all measures against spam, I would really like
> to know where their interests lie.
>
> Everything should be open to discussion which is implementation-technical
> (so obviously not e.g. threats of violence or things that bring legal
> liability to participants or have zero relevance to Bitcoin's technical
> development) even if it's philosophy-motivated. And blocking should be
> reserved either as an anti-DOS measure if volume gets out of control, or if
> it brings dangers as per the previous parenthetical.
>
>
> This comes across as a thinly veiled attempt to censor anyone who wants to
> combat spam, and their employees/employers. This idea of censoring
> "confiscatory" proposals never came up when someone proposed confiscation
> though what he called "demorage" or when someone proposed seizing Satoshi's
> coin.
>
> If you want to buy or sell pancakes, or JPEgs, or anything else for that
> matter, bitcoin is here to serve you. But your pancakes and your JPEGs
> don't belong on the bitcoin chain.
>
> Disclaimer: I own bitcoin, I run a bitcoin business in El Salvador. I own
> no inscriptions or spam of any kind, and I don't profit from any spam
> related companies.
>
> 40% of the UTXO set is dust spam UTXOs that contains less than 0.0017% of
> the total bitcoin issued. This constitutes an attack on bitcoin. I think we
> all should start acknowledging the problem, and stop asking ourselves
> dismissive questions like "What is spam anyways?" and use that question as
> an excuse to pretend there is no problem.
>
> Cheers, Pepe
>
>
>
> On Tuesday, 30 December 2025 at 08:51:56 UTC-6 Antoine Riard wrote:
>
> Hi list,
>
> > Which brings me to my disagreement, which I know is not shared by a
> number of contributors here: just as it is hard to define spam on Bitcoin,
> it's also very hard to define it in a discussion forum like this one.
> Making suggestions which *I* think are terrible, or detrimental, on a list
> like this, should never be disallowed here. Notions of motivation of
> contributors (such as they are paid by such and such a company) should not
> be relevant. Everything should be open to discussion which is
> implementation-technical (so obviously not e.g. threats of violence or
> things that bring legal liability to participants or have zero relevance to
> Bitcoin's technical development) even if it's philosophy-motivated. And
> blocking should be reserved either as an anti-DOS measure if volume gets
> out of control, or if it brings dangers as per the previous parenthetical.
>
> I'm fully sharing waxwing reasonable opinion. While I can understand
> gmax's sentiment being fed
> up with poor coin confiscation proposals again and again on the mailing
> list, the cure would be
> worst than the disease. Maybe, I'm very voltairean here, but you don't
> fight ill-founded opinions.
> by persecuting their authors (--otherwise, down the road you take the risk
> of seeing the bastille
> popped up). Rather than you fight them back by doing the work to persuade
> and to convince those
> ideas you find stupid are indeed *objectively* stupid.
>
> To me, it's a sign of strength and confidence that Bitcoin and its
> development process can
> withstand and endure the most "outrageous" controversies. For sure, I have
> been enough times
> in the shoes of someone who has to champion controversial changes (cf.
> `mempoolfullrbf`) to not
> negate that the strength of the process is kinda traded on the back of the
> devs, but this is not
> altering my mind on what I think should be *ideally* the development
> process in terms of openess
> and publicity.
>
> My humble opinion only, as we said.
>
> Best,
> Antoine
> OTS hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1ce
> Le mercredi 24 décembre 2025 à 17:23:48 UTC, waxwing/ AdamISZ a écrit :
>
> Hi Greg, list:
>
> > I think the list should adopt a 1 year ban on parties *and their*
> employer(s) (if known) for any coin confiscation proposal on the list going
> forward (after, of course, making the rule clear on the signup page). It's
> tiresome and beyond being a waste of time risks undermining public
> confidence in Bitcoin to see the constant trickle of these
> outrageous proposals in venues where they previously understood that
> serious discussions were to be had. People are, of course, free to discuss
> whatever ill-founded concepts they want but they're not entitled to the
> time and the reputation of the participants here for offensively misguided
> proposals.
>
> I'm a huge agree-er with the motivation of this comment and a huge
> disagree-er with the suggestion itself.
>
> Actual confiscation, whatever the reason, hugely undermines Bitcoin's
> value to humanity - note I am not saying its financial value, but value as
> a project (and if we didn't see such value what the hell are we doing
> here). Of course those two types of value are very closely linked, but they
> are still distinct. I hold that same belief even when we are talking about
> other suggestions of confiscation, such as to address a quantum threat -
> something that has recently been discussed here, extensively.
>
> Which brings me to my disagreement, which I know is not shared by a number
> of contributors here: just as it is hard to define spam on Bitcoin, it's
> also very hard to define it in a discussion forum like this one. Making
> suggestions which *I* think are terrible, or detrimental, on a list like
> this, should never be disallowed here. Notions of motivation of
> contributors (such as they are paid by such and such a company) should not
> be relevant. Everything should be open to discussion which is
> implementation-technical (so obviously not e.g. threats of violence or
> things that bring legal liability to participants or have zero relevance to
> Bitcoin's technical development) even if it's philosophy-motivated. And
> blocking should be reserved either as an anti-DOS measure if volume gets
> out of control, or if it brings dangers as per the previous parenthetical.
>
> Just my opinion of course, I know that moderation of lists is not a simple
> matter.
>
> Cheers,
> AdamISZ/waxwing
> On Tuesday, December 23, 2025 at 10:26:16 PM UTC-3 Greg Maxwell wrote:
>
> The 'dust threshold' isn't a consensus parameter, it's just a number
> pulled out of the air that didn't seem unreasonable based on average fee
> behavior. But in any particular block transactions may need no particular
> fee level at all, including zero fees. And in some cases it may be very
> economically advantageous to spend an output even if its face value doesn't
> support it, NFT's being a one such example (although one I consider pretty
> dumb).
>
> This proposal also appears to have ignored the prior discussion
> particularly where it was pointed out that 'deleting' outputs will not
> achieve the goal of deleting the tokens connected to them (so won't
> eliminate the incentive), or that txouts which are predictably not going to
> be accessed (as this proposal claims applies to the txouts it targets)
> don't have as significant performance implications (because they don't need
> to be cached in ram). It also appears to be uninformed by advances like
> utxotree which makes the absolute size of the txout set much less
> important, but would make mass removals such as that described
> here expensive. Nor has it considered that given the level of fee spending
> on NFT traffic a requirement to keep it over some (reasonable) threshold
> would not likely discourage it, or the fact that existent NFT outputs are
> generally over the dust limit in any case (so the proposals failure to meet
> the opcat proponents' delusional goals is already clear).
>
> I think the list should adopt a 1 year ban on parties *and their*
> employer(s) (if known) for any coin confiscation proposal on the list going
> forward (after, of course, making the rule clear on the signup page). It's
> tiresome and beyond being a waste of time risks undermining public
> confidence in Bitcoin to see the constant trickle of these
> outrageous proposals in venues where they previously understood that
> serious discussions were to be had. People are, of course, free to discuss
> whatever ill-founded concepts they want but they're not entitled to the
> time and the reputation of the participants here for offensively misguided
> proposals.
>
>
> On Tue, Dec 23, 2025 at 6:27 PM John <johnpenn...@gmail.com> wrote:
>
> Good evening all,
>
> Here is a related proposal by Matteo Pellegrini
> @matteopelleg
>
>
>
> Lynx.
>
> Abstract
> This proposal introduces a periodic, consensus-enforced mechanism for
> rendering UTXOs below the network's dust threshold permanently unspendable.
> At each halving block, UTXOs that have remained below the dust threshold
> since the previous halving become unspendable. These UTXOs become
> unspendable and may be pruned from the UTXO set entirely, reducing node
> storage requirements and eliminating the economic model that incentivizes
> their creation.
>
> Motivation
> The Bitcoin UTXO set has grown substantially due to various factors,
> including inscription protocols, spam attacks, and general dust
> accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO
> Cleanup) by @ostrom72158
> have attempted to address this by creating lists of specific UTXOs to
> render unspendable, identified by external protocol indexers.
>
> The Cat's approach has a fatal flaw: it relies on a list.
>
> Using a curated list of "non-monetary UTXOs" introduces several problems:
>
> 1) External dependency: The Cat requires reference indexers (Ord, Stamps,
> etc.) to define which UTXOs qualify. This introduces consensus-level
> dependency on external, non-Bitcoin software that can change, have bugs, or
> interpret protocols differently.
>
> 2) Protocol targeting: By specifically identifying inscription and stamp
> outputs, the proposal makes subjective judgments about which Bitcoin uses
> are legitimate. This sets a precedent for protocol-level discrimination.
>
> 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes
> workarounds. If Ordinals dust is targeted, protocols will adapt to create
> dust that doesn't match the list criteria.
>
> 4) Static snapshot: A one-time list cleanup provides temporary relief but
> does nothing for future UTXO accumulation.
>
> 5) Political vulnerability: Any list-based approach requires ongoing
> governance decisions about what belongs on the list, creating a permanent
> political attack surface.
>
> A better approach targets the economic reality, not the use case.
>
> UTXOs below the dust threshold are, by definition, economically irrational
> to spend under normal fee conditions. The dust limit exists precisely
> because spending these outputs costs more in fees than the output is worth.
> These UTXOs are already "dead" in practice; this proposal simply makes that
> reality explicit at the consensus layer.
>
> By using a threshold rather than a list, Lynx:
>
> - Requires no external indexers
> - Makes no judgment about why a UTXO is small
> - Applies equally to all participants
> - Provides ongoing, predictable maintenance
> - Removes political discretion from the process
>
> Impact on Inscription Protocols
>
> The typical Ordinals inscription is stored in a UTXO containing exactly
> 546 sats; the minimum required to meet the dust limit for P2PKH addresses
> and ensure transferability across all address types. This "postage" amount
> is standard across inscription tooling and marketplaces.
>
> A threshold of 999 sats captures the vast majority of inscription UTXOs
> without requiring any protocol-specific targeting. The economic model of
> inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks
> that model through neutral, threshold-based rules rather than list-based
> discrimination.
>
> Specification
>
> Definitions
>
> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is
> subject to Lynx enforcement.
>
> - Halving block: A block at height N * 210,000 where N ≥ 1.
>
> - Snapshot block: A halving block at which the current dust threshold and
> qualifying UTXOs are recorded.
>
> - Enforcement block: The halving block following a snapshot block (i.e.,
> snapshot block + 210,000 blocks).
>
> Lynx UTXOs:
> - Existed at the snapshot block
> - Had a value less than 999 sats
> - Remained unspent through the enforcement period (~4 years)
>
> Consensus Rules
> After activation, the following rules apply:
>
> 1) Snapshot: At each halving block H, record the set of all UTXOs with
> value < 999 sats.
>
> 2) Enforcement: At halving block H + 210,000:
> - Any UTXO that was in the snapshot set and remains unspent becomes
> permanently unspendable
> - Transactions attempting to spend these UTXOs are invalid
>
> 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their local
> UTXO set. Transactions referencing unknown outpoints are already rejected
> as invalid; pruned Lynx UTXOs are simply treated as if they were already
> spent.
>
> 4) Grace period: The ~4 year window between snapshot and enforcement
> provides ample time for holders to consolidate sub-dust UTXOs if they wish
> to preserve the value.
>
> Activation
>
> Activation method: TBD (Speedy Trial, BIP8, or other mechanism as
> determined by community consensus)
>
> Recommended first snapshot: The halving following activation lock-in
>
> Rationale
>
> Why a fixed threshold?
>
> Using a fixed threshold of 999 sats rather than referencing the dynamic
> relay dust limit provides:
>
> - Simplicity: One number, no script-type variations, no need to query
> policy settings
>
> - Predictability: Everyone knows exactly what qualifies, forever
>
> - Consensus clarity: No ambiguity about which outputs are affected.
>
> Why tie to the halving?
>
> The halving is Bitcoin's most recognized Schelling point, using it
> provides:
>
> - Predictability: Everyone knows exactly when halvings occur
> - Sufficient notice: ~4 years is generous warning for any cleanup action
> - Aligned incentives: As block rewards decrease, fee revenue and UTXO
> efficiency become more critical to network sustainability
> - Natural cadence: The halving already represents a moment of network-wide
> coordination
>
> Why not a one-time cleanup?
>
> A one-time cleanup (as proposed by The Cat) provides temporary relief but
> creates no ongoing pressure against dust accumulation. Periodic enforcement:
>
> - Establishes a permanent, predictable norm
> - Removes any expectation that dust UTXOs have indefinite longevity
> - Discourages business models built on dust creation
> - Provides continuous UTXO set maintenance
>
> Why pruning works without a list
>
> A key insight enables pruning without maintaining a separate list: Bitcoin
> nodes already reject transactions that reference unknown outpoints. When a
> node receives a transaction spending an outpoint not in its UTXO set, it
> rejects it as invalid — the node doesn't need to know why the outpoint is
> missing (spent? never existed? pruned?).
>
> After enforcement, a Lynx UTXO is functionally equivalent to a spent
> output. Nodes can simply delete it from the UTXO set. Any future
> transaction attempting to spend it will reference an outpoint the node
> doesn't recognize, and will be rejected through existing validation logic.
>
> This means:
>
> - No separate "Lynx list" is required
> - No new validation logic is needed
> - Pruning is optional; nodes MAY keep Lynx UTXOs if they wish
> - The UTXO set shrinks naturally as nodes prune
>
> Why 999 sats?
>
> The threshold of 999 sats is chosen because:
>
> - Above all dust limits: Captures UTXOs at or below the dust limit for all
> script types (P2PKH: 546, P2TR: 330, etc.)
> - Captures all standard inscriptions: Typical inscription UTXOs contain
> exactly 546 sats as "postage"; well under 999
> - Simple and memorable: A clean number that's easy to communicate and
> reason about
>
> Backward Compatibility
>
> This is a soft fork. Nodes that do not upgrade will:
>
> - Continue to consider all historical transactions valid
> - Accept blocks that exclude spends of Lynx UTXOs
> - Eventually converge with upgraded nodes (as upgraded miners will not
> include invalid spends)
>
> Wallets & Services should:
>
> - Warn users holding sub-threshold UTXOs after a snapshot block
> - Provide consolidation tools during the grace period
> - Update UTXO selection algorithms to deprioritize or exclude
> sub-threshold outputs approaching a snapshot
>
> Security Considerations
>
> No confiscation
>
> This proposal does not transfer value to any party. Sub-threshold UTXOs
> become unspendable, similar to:
>
> - Lost private keys
> - Provably unspendable OP_RETURN outputs
> - Satoshi's untouched coinbase rewards
>
> The bitcoin supply cap remains unchanged; the affected outputs simply
> become irrecoverable. Holders receive ~4 years notice to consolidate if
> they value the sats.
>
> Lightning Network
>
> Some Lightning implementations create small HTLCs and dust outputs during
> channel operations. Analysis is needed to determine:
>
> - Whether current dust thresholds affect normal LN operations
> - If LN implementations need adjustment before activation
> - Whether channel close scenarios create sub-threshold outputs
>
> Preliminary assessment: LN dust limits are already set conservatively
> above relay dust limits, so impact should be minimal. However, this
> requires verification from LN implementers.
>
> Fixed threshold vs. future fee markets
>
> The 999 satoshi threshold is fixed in consensus rules and does not adjust
> based on fee market conditions.
> This is intentional:
>
> - A fixed threshold provides certainty for users and developers
> - If fee markets change dramatically, a future soft fork could adjust the
> threshold
> - The ~4 year grace period allows the community to observe and adapt
>
> If Bitcoin's fee market evolves such that 999 sats becomes economically
> significant to spend, this would indicate broader success of the network;
> and the community could choose to lower or eliminate the threshold through
> a subsequent proposal.
>
> Acknowledgments
> This proposal builds on the problem identification in "The Cat"
> (Non-monetary UTXO Cleanup) while proposing a list-free alternative
> mechanism. The Cat correctly identifies UTXO bloat as a problem worth
> solving; Lynx offers a more neutral solution.
>
>
> https://x.com/matteopelleg/status/2000602318346334449
> On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
>
> I received no prior response from you, so I suspect the issue is on your
> end-- since if you sent one I would normally have been directly copied.
>
> In any case, your message makes no sense. If an output is provably
> unspendable then it is unspendable. No amount of "clever steganography"
> can change that. If you're imagining that perhaps they are *presumed* to
> be unspendable but actually *are* spendable, then sure that would be an
> issue but with any change to consensus relevant code great care must be
> taken to not introduce errors. Actually *making* a consensus change would
> only increase the potential for mistakes.
>
> These costs are just another reason why this hysteria over a non-issue is
> misplaced.
>
> But in any case it is better that (any) implementations that care about
> stamps put in the effort to define their exclusions in ways that are safe
> than to burden everyone with a consensus change that doesn't care about it.
>
>
> On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98...@gmail.com> wrote:
>
> This is my third attempt to respond to this. Idk what is going wrong here.
>
> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without a
> consensus change is that a clever use of steganography could cause one of
> those otherwise unspendable outputs to be spendable, thus causing a fork
> between those nodes that adopted the Stamp pruning method and those that
> did not once one of those steganographic Stamps is spent. Though this is
> unlikely, it is still technically possible, and I would not put it past the
> denizens of the Internet to stir up trouble just for its own sake.
>
> On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
>
> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com> wrote:
>
> Since the Bitcoin Stamps outputs are already unspendable, it makes perfect
> sense to mark and drop them from the UTXO set.
>
>
> There is no consensus change involved in not storing a provably
> unspendable output, it's just an implementation detail with no
> interoperability implications and doesn't need a BIP. Bitcoin core has
> long done so for several types of unspendable outputs, e.g. outputs over
> 10kb and ones starting with OP_RETURN.
>
> --
> 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
> email to bitcoindev+...@googlegroups.com.
>
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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
> email to bitcoindev+...@googlegroups.com.
>
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/cf39fdca-e996-43be-ab52-573aedd619d5n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/cf39fdca-e996-43be-ab52-573aedd619d5n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAL5BAw0RV8A_Ny3GSoR1gCSEHxdfkWu%2BsLQCp7KJCet0Sf%3DJuQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 35987 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [bitcoindev] Re: The Cat, BIP draft discussion.
2026-01-19 1:11 ` Pepe Hodler
2026-01-23 3:45 ` Chris Riley
@ 2026-01-23 13:55 ` Galois Field
1 sibling, 0 replies; 20+ messages in thread
From: Galois Field @ 2026-01-23 13:55 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 28677 bytes --]
Hello everyone,
I don't respond regularly, but I can't let this go.
> I don't understand how anyone could be confused about the concept of spam
on bitcoin
The problem is that you're redefining "spam" to mean "transactions I don't
like" rather than using the technical definition: transactions that DoS the
network.
Inscriptions, ordinals, OP_RETURN: these are consensus-valid transactions
that pay fees. Miners choose to include them. That's not spam, that's the
fee market working. You can disagree with the use case, but calling it an
"attack" is disingenuous.
Your email spam analogy is backwards: email spam is unwanted by the
recipient. Here, miners ARE the recipients, and they're explicitly
accepting these transactions by including them in blocks.
Bitcoin is agnostic about UTXO content. It's not up to developers to decide
what's a "legitimate monetary transaction" based on the white paper. The
protocol is defined by consensus rules in the code, not by our
interpretation of Satoshi's intent.
Spam prevention in the codebase (like the witness data checks in
validation.cpp) exists to prevent DoS vectors, not to judge transaction
purpose. That's the actual definition of spam we should be using.
Filter whatever you want on your node. That's your right and policy rules
exist for this. But advocating for protocol-level censorship of
consensus-valid, fee-paying transactions because you don't like what
they're used for is far more dangerous than any jpeg in witness data.
Best,
Galois
Le jeudi 22 janvier 2026 à 22:54:24 UTC+1, Pepe Hodler a écrit :
> Hi list.
>
> Which brings me to my disagreement, which I know is not shared by a number
> of contributors here: just as it is hard to define spam on Bitcoin
>
> I don't understand how anyone could be confused about the concept of spam
> on bitcoin. Bitcoins is "A Peer-to-Peer Electronic Cash System" according
> to the white paper. As such, anything not intended as a monetary
> transaction is spam.
>
> The use of fake pubkeys to store data on chain, that is an unsupported and
> unsanctioned use of bitcoin. That is spam, and an attack, not a monetary
> transaction.
>
> Same with fake scripthash used to store arbitrary data, unsupported and
> unsanctioned use of bitcoin. That is spam, and an attack, not a monetary
> transaction.
>
> And the same goes for the Segwit exploit and the Taproot exploit. That is
> exploiting bitcoin to store arbitrary data in an unsanctioned way, spam, an
> attack on bitcoin.
>
> When Segwit and Taproot were implemented, nobody, absolutely nobody was
> welcoming those upgrades as a way to store jpegs and other garbage on
> chain. That is not what bitcoin, Segwit, and Taproot were built for.
>
> If you are making use of OpenRelay and/or SlipStream to bypass the policy
> of the majority of nodes, you are a spammer and an attacker, not a bitcoiner.
> You are trying to skirt the only use case of bitcoin.
>
> When there are blocks like this one:
> https://mempool.space/block/00000000000000000000ed962f87a0c350b1401fe546db60e6d78e34ab549378 .
> Over 60% of the transactions in that block are not sending or receiving a
> single sat. It's all op_returns with no sats in them. That is not what
> bitcoin was designed or sanctioned for.
>
> These people are not users, they are attackers and spammers. How can you
> look at inscriptions, runes, ordinals, fake pubkeys, fake scripthash,
> stamps, and op_return with 0 sats in them and wonder if those are legit
> bitcoin monetary transactions?
> Now, some have tried to claim "My ordinal is a consensus valid
> transaction". And of course it is, otherwise it would not have been added
> to a block. But that's like saying the Nigerian prince email followed all
> the SMTP and POP protocols of email, therefore it's not spam. Some spam
> defenders have tried to claim they have paid their miner fee. Of course
> they did, but that's like saying the sender of the Nigerian prince email
> paid his internet, therefore it's not spam.
>
> If you are confused about what constitutes spam on bitcoin, please
> explain. While I'm sure there are some transactions that could be tricky
> and controversial to identify as spam, I"m sure we can all agree that
> inscriptions, stamps, jpegs, fake pubkeys, fake scripthash, unusually large
> Segwit data, ordinals, runes, etc, are all clearly spam.
>
>
> it's also very hard to define it in a discussion forum like this one.
>
>
> I just did it, see above. It really wasn't that hard. How are you confused
> about the definition of spam as it pertains to bitcoin? Because bitcoin is
> money, they have to obfuscate their spam to make it look like a legitimate
> monetary transaction to the system. So you could make the case that it's
> harder to distinguish spam from a real monetary transaction. But defining
> spam on it's own is pretty easy.
>
> But ultimately, it does not belong to devs to decide what is spam. Don't
> think that just because we know C++, that somehow gives us authority to
> decide what direction bitcoin should be taking, and what spam is.
>
> That decision belongs to the nodes. And it's clear that the nodes are not
> given the tools to decide for themselves what spam is or what spam isn't,
> with comprehensive user configurable spam filters.
>
> Notions of motivation of contributors (such as they are paid by such and
> such a company) should not be relevant.
>
>
> Are you suggesting that conflict of interest is not a thing? If someone is
> advocating against any and all measures against spam, I would really like
> to know where their interests lie.
>
> Everything should be open to discussion which is implementation-technical
> (so obviously not e.g. threats of violence or things that bring legal
> liability to participants or have zero relevance to Bitcoin's technical
> development) even if it's philosophy-motivated. And blocking should be
> reserved either as an anti-DOS measure if volume gets out of control, or if
> it brings dangers as per the previous parenthetical.
>
>
> This comes across as a thinly veiled attempt to censor anyone who wants to
> combat spam, and their employees/employers. This idea of censoring
> "confiscatory" proposals never came up when someone proposed confiscation
> though what he called "demorage" or when someone proposed seizing Satoshi's
> coin.
>
> If you want to buy or sell pancakes, or JPEgs, or anything else for that
> matter, bitcoin is here to serve you. But your pancakes and your JPEGs
> don't belong on the bitcoin chain.
>
> Disclaimer: I own bitcoin, I run a bitcoin business in El Salvador. I own
> no inscriptions or spam of any kind, and I don't profit from any spam
> related companies.
>
> 40% of the UTXO set is dust spam UTXOs that contains less than 0.0017% of
> the total bitcoin issued. This constitutes an attack on bitcoin. I think we
> all should start acknowledging the problem, and stop asking ourselves
> dismissive questions like "What is spam anyways?" and use that question as
> an excuse to pretend there is no problem.
>
> Cheers, Pepe
>
>
>
> On Tuesday, 30 December 2025 at 08:51:56 UTC-6 Antoine Riard wrote:
>
> Hi list,
>
> > Which brings me to my disagreement, which I know is not shared by a
> number of contributors here: just as it is hard to define spam on Bitcoin,
> it's also very hard to define it in a discussion forum like this one.
> Making suggestions which *I* think are terrible, or detrimental, on a list
> like this, should never be disallowed here. Notions of motivation of
> contributors (such as they are paid by such and such a company) should not
> be relevant. Everything should be open to discussion which is
> implementation-technical (so obviously not e.g. threats of violence or
> things that bring legal liability to participants or have zero relevance to
> Bitcoin's technical development) even if it's philosophy-motivated. And
> blocking should be reserved either as an anti-DOS measure if volume gets
> out of control, or if it brings dangers as per the previous parenthetical.
>
> I'm fully sharing waxwing reasonable opinion. While I can understand
> gmax's sentiment being fed
> up with poor coin confiscation proposals again and again on the mailing
> list, the cure would be
> worst than the disease. Maybe, I'm very voltairean here, but you don't
> fight ill-founded opinions.
> by persecuting their authors (--otherwise, down the road you take the risk
> of seeing the bastille
> popped up). Rather than you fight them back by doing the work to persuade
> and to convince those
> ideas you find stupid are indeed *objectively* stupid.
>
> To me, it's a sign of strength and confidence that Bitcoin and its
> development process can
> withstand and endure the most "outrageous" controversies. For sure, I have
> been enough times
> in the shoes of someone who has to champion controversial changes (cf.
> `mempoolfullrbf`) to not
> negate that the strength of the process is kinda traded on the back of the
> devs, but this is not
> altering my mind on what I think should be *ideally* the development
> process in terms of openess
> and publicity.
>
> My humble opinion only, as we said.
>
> Best,
> Antoine
> OTS hash: 5c1c19f589a61787dbf483cd6814f094c3b24888d6d189c5f4d776bda558e1ce
> Le mercredi 24 décembre 2025 à 17:23:48 UTC, waxwing/ AdamISZ a écrit :
>
> Hi Greg, list:
>
> > I think the list should adopt a 1 year ban on parties *and their*
> employer(s) (if known) for any coin confiscation proposal on the list going
> forward (after, of course, making the rule clear on the signup page). It's
> tiresome and beyond being a waste of time risks undermining public
> confidence in Bitcoin to see the constant trickle of these
> outrageous proposals in venues where they previously understood that
> serious discussions were to be had. People are, of course, free to discuss
> whatever ill-founded concepts they want but they're not entitled to the
> time and the reputation of the participants here for offensively misguided
> proposals.
>
> I'm a huge agree-er with the motivation of this comment and a huge
> disagree-er with the suggestion itself.
>
> Actual confiscation, whatever the reason, hugely undermines Bitcoin's
> value to humanity - note I am not saying its financial value, but value as
> a project (and if we didn't see such value what the hell are we doing
> here). Of course those two types of value are very closely linked, but they
> are still distinct. I hold that same belief even when we are talking about
> other suggestions of confiscation, such as to address a quantum threat -
> something that has recently been discussed here, extensively.
>
> Which brings me to my disagreement, which I know is not shared by a number
> of contributors here: just as it is hard to define spam on Bitcoin, it's
> also very hard to define it in a discussion forum like this one. Making
> suggestions which *I* think are terrible, or detrimental, on a list like
> this, should never be disallowed here. Notions of motivation of
> contributors (such as they are paid by such and such a company) should not
> be relevant. Everything should be open to discussion which is
> implementation-technical (so obviously not e.g. threats of violence or
> things that bring legal liability to participants or have zero relevance to
> Bitcoin's technical development) even if it's philosophy-motivated. And
> blocking should be reserved either as an anti-DOS measure if volume gets
> out of control, or if it brings dangers as per the previous parenthetical.
>
> Just my opinion of course, I know that moderation of lists is not a simple
> matter.
>
> Cheers,
> AdamISZ/waxwing
> On Tuesday, December 23, 2025 at 10:26:16 PM UTC-3 Greg Maxwell wrote:
>
> The 'dust threshold' isn't a consensus parameter, it's just a number
> pulled out of the air that didn't seem unreasonable based on average fee
> behavior. But in any particular block transactions may need no particular
> fee level at all, including zero fees. And in some cases it may be very
> economically advantageous to spend an output even if its face value doesn't
> support it, NFT's being a one such example (although one I consider pretty
> dumb).
>
> This proposal also appears to have ignored the prior discussion
> particularly where it was pointed out that 'deleting' outputs will not
> achieve the goal of deleting the tokens connected to them (so won't
> eliminate the incentive), or that txouts which are predictably not going to
> be accessed (as this proposal claims applies to the txouts it targets)
> don't have as significant performance implications (because they don't need
> to be cached in ram). It also appears to be uninformed by advances like
> utxotree which makes the absolute size of the txout set much less
> important, but would make mass removals such as that described
> here expensive. Nor has it considered that given the level of fee spending
> on NFT traffic a requirement to keep it over some (reasonable) threshold
> would not likely discourage it, or the fact that existent NFT outputs are
> generally over the dust limit in any case (so the proposals failure to meet
> the opcat proponents' delusional goals is already clear).
>
> I think the list should adopt a 1 year ban on parties *and their*
> employer(s) (if known) for any coin confiscation proposal on the list going
> forward (after, of course, making the rule clear on the signup page). It's
> tiresome and beyond being a waste of time risks undermining public
> confidence in Bitcoin to see the constant trickle of these
> outrageous proposals in venues where they previously understood that
> serious discussions were to be had. People are, of course, free to discuss
> whatever ill-founded concepts they want but they're not entitled to the
> time and the reputation of the participants here for offensively misguided
> proposals.
>
>
> On Tue, Dec 23, 2025 at 6:27 PM John <johnpenn...@gmail.com> wrote:
>
> Good evening all,
>
> Here is a related proposal by Matteo Pellegrini
> @matteopelleg
>
>
>
> Lynx.
>
> Abstract
> This proposal introduces a periodic, consensus-enforced mechanism for
> rendering UTXOs below the network's dust threshold permanently unspendable.
> At each halving block, UTXOs that have remained below the dust threshold
> since the previous halving become unspendable. These UTXOs become
> unspendable and may be pruned from the UTXO set entirely, reducing node
> storage requirements and eliminating the economic model that incentivizes
> their creation.
>
> Motivation
> The Bitcoin UTXO set has grown substantially due to various factors,
> including inscription protocols, spam attacks, and general dust
> accumulation. Recent proposals such as "The Cat" (Non-monetary UTXO
> Cleanup) by @ostrom72158
> have attempted to address this by creating lists of specific UTXOs to
> render unspendable, identified by external protocol indexers.
>
> The Cat's approach has a fatal flaw: it relies on a list.
>
> Using a curated list of "non-monetary UTXOs" introduces several problems:
>
> 1) External dependency: The Cat requires reference indexers (Ord, Stamps,
> etc.) to define which UTXOs qualify. This introduces consensus-level
> dependency on external, non-Bitcoin software that can change, have bugs, or
> interpret protocols differently.
>
> 2) Protocol targeting: By specifically identifying inscription and stamp
> outputs, the proposal makes subjective judgments about which Bitcoin uses
> are legitimate. This sets a precedent for protocol-level discrimination.
>
> 3) Cat-and-mouse dynamics: Targeting specific protocols incentivizes
> workarounds. If Ordinals dust is targeted, protocols will adapt to create
> dust that doesn't match the list criteria.
>
> 4) Static snapshot: A one-time list cleanup provides temporary relief but
> does nothing for future UTXO accumulation.
>
> 5) Political vulnerability: Any list-based approach requires ongoing
> governance decisions about what belongs on the list, creating a permanent
> political attack surface.
>
> A better approach targets the economic reality, not the use case.
>
> UTXOs below the dust threshold are, by definition, economically irrational
> to spend under normal fee conditions. The dust limit exists precisely
> because spending these outputs costs more in fees than the output is worth.
> These UTXOs are already "dead" in practice; this proposal simply makes that
> reality explicit at the consensus layer.
>
> By using a threshold rather than a list, Lynx:
>
> - Requires no external indexers
> - Makes no judgment about why a UTXO is small
> - Applies equally to all participants
> - Provides ongoing, predictable maintenance
> - Removes political discretion from the process
>
> Impact on Inscription Protocols
>
> The typical Ordinals inscription is stored in a UTXO containing exactly
> 546 sats; the minimum required to meet the dust limit for P2PKH addresses
> and ensure transferability across all address types. This "postage" amount
> is standard across inscription tooling and marketplaces.
>
> A threshold of 999 sats captures the vast majority of inscription UTXOs
> without requiring any protocol-specific targeting. The economic model of
> inscriptions depends on these dust-level UTXOs being spendable; Lynx breaks
> that model through neutral, threshold-based rules rather than list-based
> discrimination.
>
> Specification
>
> Definitions
>
> - Dust threshold: 999 sats. Any UTXO with a value less than 999 sats is
> subject to Lynx enforcement.
>
> - Halving block: A block at height N * 210,000 where N ≥ 1.
>
> - Snapshot block: A halving block at which the current dust threshold and
> qualifying UTXOs are recorded.
>
> - Enforcement block: The halving block following a snapshot block (i.e.,
> snapshot block + 210,000 blocks).
>
> Lynx UTXOs:
> - Existed at the snapshot block
> - Had a value less than 999 sats
> - Remained unspent through the enforcement period (~4 years)
>
> Consensus Rules
> After activation, the following rules apply:
>
> 1) Snapshot: At each halving block H, record the set of all UTXOs with
> value < 999 sats.
>
> 2) Enforcement: At halving block H + 210,000:
> - Any UTXO that was in the snapshot set and remains unspent becomes
> permanently unspendable
> - Transactions attempting to spend these UTXOs are invalid
>
> 3) Pruning: After enforcement, nodes MAY prune Lynx UTXOs from their local
> UTXO set. Transactions referencing unknown outpoints are already rejected
> as invalid; pruned Lynx UTXOs are simply treated as if they were already
> spent.
>
> 4) Grace period: The ~4 year window between snapshot and enforcement
> provides ample time for holders to consolidate sub-dust UTXOs if they wish
> to preserve the value.
>
> Activation
>
> Activation method: TBD (Speedy Trial, BIP8, or other mechanism as
> determined by community consensus)
>
> Recommended first snapshot: The halving following activation lock-in
>
> Rationale
>
> Why a fixed threshold?
>
> Using a fixed threshold of 999 sats rather than referencing the dynamic
> relay dust limit provides:
>
> - Simplicity: One number, no script-type variations, no need to query
> policy settings
>
> - Predictability: Everyone knows exactly what qualifies, forever
>
> - Consensus clarity: No ambiguity about which outputs are affected.
>
> Why tie to the halving?
>
> The halving is Bitcoin's most recognized Schelling point, using it
> provides:
>
> - Predictability: Everyone knows exactly when halvings occur
> - Sufficient notice: ~4 years is generous warning for any cleanup action
> - Aligned incentives: As block rewards decrease, fee revenue and UTXO
> efficiency become more critical to network sustainability
> - Natural cadence: The halving already represents a moment of network-wide
> coordination
>
> Why not a one-time cleanup?
>
> A one-time cleanup (as proposed by The Cat) provides temporary relief but
> creates no ongoing pressure against dust accumulation. Periodic enforcement:
>
> - Establishes a permanent, predictable norm
> - Removes any expectation that dust UTXOs have indefinite longevity
> - Discourages business models built on dust creation
> - Provides continuous UTXO set maintenance
>
> Why pruning works without a list
>
> A key insight enables pruning without maintaining a separate list: Bitcoin
> nodes already reject transactions that reference unknown outpoints. When a
> node receives a transaction spending an outpoint not in its UTXO set, it
> rejects it as invalid — the node doesn't need to know why the outpoint is
> missing (spent? never existed? pruned?).
>
> After enforcement, a Lynx UTXO is functionally equivalent to a spent
> output. Nodes can simply delete it from the UTXO set. Any future
> transaction attempting to spend it will reference an outpoint the node
> doesn't recognize, and will be rejected through existing validation logic.
>
> This means:
>
> - No separate "Lynx list" is required
> - No new validation logic is needed
> - Pruning is optional; nodes MAY keep Lynx UTXOs if they wish
> - The UTXO set shrinks naturally as nodes prune
>
> Why 999 sats?
>
> The threshold of 999 sats is chosen because:
>
> - Above all dust limits: Captures UTXOs at or below the dust limit for all
> script types (P2PKH: 546, P2TR: 330, etc.)
> - Captures all standard inscriptions: Typical inscription UTXOs contain
> exactly 546 sats as "postage"; well under 999
> - Simple and memorable: A clean number that's easy to communicate and
> reason about
>
> Backward Compatibility
>
> This is a soft fork. Nodes that do not upgrade will:
>
> - Continue to consider all historical transactions valid
> - Accept blocks that exclude spends of Lynx UTXOs
> - Eventually converge with upgraded nodes (as upgraded miners will not
> include invalid spends)
>
> Wallets & Services should:
>
> - Warn users holding sub-threshold UTXOs after a snapshot block
> - Provide consolidation tools during the grace period
> - Update UTXO selection algorithms to deprioritize or exclude
> sub-threshold outputs approaching a snapshot
>
> Security Considerations
>
> No confiscation
>
> This proposal does not transfer value to any party. Sub-threshold UTXOs
> become unspendable, similar to:
>
> - Lost private keys
> - Provably unspendable OP_RETURN outputs
> - Satoshi's untouched coinbase rewards
>
> The bitcoin supply cap remains unchanged; the affected outputs simply
> become irrecoverable. Holders receive ~4 years notice to consolidate if
> they value the sats.
>
> Lightning Network
>
> Some Lightning implementations create small HTLCs and dust outputs during
> channel operations. Analysis is needed to determine:
>
> - Whether current dust thresholds affect normal LN operations
> - If LN implementations need adjustment before activation
> - Whether channel close scenarios create sub-threshold outputs
>
> Preliminary assessment: LN dust limits are already set conservatively
> above relay dust limits, so impact should be minimal. However, this
> requires verification from LN implementers.
>
> Fixed threshold vs. future fee markets
>
> The 999 satoshi threshold is fixed in consensus rules and does not adjust
> based on fee market conditions.
> This is intentional:
>
> - A fixed threshold provides certainty for users and developers
> - If fee markets change dramatically, a future soft fork could adjust the
> threshold
> - The ~4 year grace period allows the community to observe and adapt
>
> If Bitcoin's fee market evolves such that 999 sats becomes economically
> significant to spend, this would indicate broader success of the network;
> and the community could choose to lower or eliminate the threshold through
> a subsequent proposal.
>
> Acknowledgments
> This proposal builds on the problem identification in "The Cat"
> (Non-monetary UTXO Cleanup) while proposing a list-free alternative
> mechanism. The Cat correctly identifies UTXO bloat as a problem worth
> solving; Lynx offers a more neutral solution.
>
>
> https://x.com/matteopelleg/status/2000602318346334449
> On Thursday, 18 December 2025 at 21:36:14 UTC-6 Greg Maxwell wrote:
>
> I received no prior response from you, so I suspect the issue is on your
> end-- since if you sent one I would normally have been directly copied.
>
> In any case, your message makes no sense. If an output is provably
> unspendable then it is unspendable. No amount of "clever steganography"
> can change that. If you're imagining that perhaps they are *presumed* to
> be unspendable but actually *are* spendable, then sure that would be an
> issue but with any change to consensus relevant code great care must be
> taken to not introduce errors. Actually *making* a consensus change would
> only increase the potential for mistakes.
>
> These costs are just another reason why this hysteria over a non-issue is
> misplaced.
>
> But in any case it is better that (any) implementations that care about
> stamps put in the effort to define their exclusions in ways that are safe
> than to burden everyone with a consensus change that doesn't care about it.
>
>
> On Fri, Dec 19, 2025 at 1:49 AM Jonathan Voss <k98...@gmail.com> wrote:
>
> This is my third attempt to respond to this. Idk what is going wrong here.
>
> The problem with dropping Bitcoin Stamps UTXOs from the UTXO set without a
> consensus change is that a clever use of steganography could cause one of
> those otherwise unspendable outputs to be spendable, thus causing a fork
> between those nodes that adopted the Stamp pruning method and those that
> did not once one of those steganographic Stamps is spent. Though this is
> unlikely, it is still technically possible, and I would not put it past the
> denizens of the Internet to stir up trouble just for its own sake.
>
> On Friday, December 12, 2025 at 6:49:41 PM UTC-5 Greg Maxwell wrote:
>
> On Fri, Dec 12, 2025 at 9:26 PM Jonathan Voss <k98...@gmail.com> wrote:
>
> Since the Bitcoin Stamps outputs are already unspendable, it makes perfect
> sense to mark and drop them from the UTXO set.
>
>
> There is no consensus change involved in not storing a provably
> unspendable output, it's just an implementation detail with no
> interoperability implications and doesn't need a BIP. Bitcoin core has
> long done so for several types of unspendable outputs, e.g. outputs over
> 10kb and ones starting with OP_RETURN.
>
> --
> 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
> email to bitcoindev+...@googlegroups.com.
>
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/4e947f47-b43d-4ec3-ac6a-aa66ea0cfb79n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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
> email to bitcoindev+...@googlegroups.com.
>
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/959c8b53-2055-4de2-8a93-1fd169f1a159n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f66300d3-1606-41ec-9530-30a3731ea045n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 35328 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2026-01-23 14:03 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <32f8c689-314d-4a5e-9af6-2e3e704582e6n@googlegroups.com>
[not found] ` <CAAS2fgRR77nZj3-rJo70dnxe8Lma88-C9JqdVTYfXGHRgFu3pA@mail.gmail.com>
2025-12-11 20:54 ` [bitcoindev] The Cat, BIP draft discussion Bitcoin Mechanic
2025-12-12 1:49 ` TwoLargePizzas
2025-12-13 15:02 ` Greg Maxwell
2025-12-14 1:51 ` Pepe Hodler
2025-12-15 10:35 ` Nona YoBidnes
2025-12-15 16:04 ` Greg Maxwell
2025-12-12 17:13 ` [bitcoindev] " Jonathan Voss
2025-12-12 23:40 ` Greg Maxwell
2025-12-13 3:54 ` Melvin Carvalho
2025-12-13 7:07 ` Ataraxia 009
2025-12-17 16:22 ` Jonathan Voss
2025-12-19 3:31 ` Greg Maxwell
2025-12-21 5:07 ` John
2025-12-23 19:12 ` Greg Maxwell
2025-12-24 17:19 ` waxwing/ AdamISZ
2025-12-30 14:36 ` Antoine Riard
2026-01-19 1:11 ` Pepe Hodler
2026-01-23 3:45 ` Chris Riley
2026-01-23 13:55 ` Galois Field
2026-01-22 1:14 ` Claire Ostrom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox