BIP Draft · 2026 · No Fork Required

Bitcoin is money.
Run a node that treats it that way.

A sly, roundabout way of fighting spam.

A Monetary Node validates every consensus rule a full node does — and refuses to store or relay anything else. The spam is deleted; the hashes are saved. Half the chainstate. Zero consensus changes.

The essence

The spam is deleted; the hashes are saved.

A Monetary Node discards the content of spam outputs from its working database the moment each block is validated — while permanently keeping every block hash, a compact record of what was removed, and two cryptographic fingerprints of the ledger: one of the full state, one of the clean state, bound together so neither can be faked without the other. Full historical blocks remain available for the rare cases the deleted data is ever needed again. Same chain. Same rules. Same proof-of-work.

The problem

90MUTXO entries accumulated 2009 → early 2023
173M+UTXO entries today
40–50%estimated spam — inscriptions, stamps, token dust

Every unspent output — including spam that will never be spent — must be held in the working database of every full node, forever. Inscriptions, stamps, and token protocols embed data in outputs that node operators must store, index, and verify while receiving nothing in return. The burden is permanent, compounding, and unbounded.

Spam node chainstate (today)~173M entries
Monetary Node chainstate~95M entries
Solid — monetary outputs. Hatched — data-embedding outputs a Monetary Node never stores. Gap widens every year spam persists.

The trajectory

UTXO set growth — and where it goes from here

Fourteen years to reach ~85 million entries. One year of inscriptions to nearly double it. Solid lines are history; dashed lines project the current trend.

0 50M 100M 150M 200M 250M 2021 2023 2025 2027 2029 block 680,000 inscriptions begin spam node monetary node today

A monetary node tracks the same money the whole time — its growth is Bitcoin's actual economic activity. The gap between the lines is pure spam, and it compounds forever on every node that stores it.

What that means for disk and memory

Chainstate (the working database every node must keep hot) roughly tripled since inscriptions began. Hatched bars are projections at the current trend.

0 5 GB 10 GB 15 GB 20 GB 44 116.5 137 ~16~7.5 ~19~8 2021 2024 2026 2028* 2030* spam node chainstate monetary node chainstate * projected at current trend

The working database must stay fast — ideally in memory (dbcache). A monetary node's chainstate still fits comfortably in the RAM of a Raspberry-Pi-class machine at the end of the decade; a spam node's increasingly does not. That widening gap is the adoption mechanism: the cheapest fully validating node wins, and it is the one that deletes spam. Figures approximate; sources and assumptions in the BIP draft.

One chain, two views

The monetary view grows out of the legacy blockchain, block by block. Every block is fully validated as mined — then spam is discarded before it ever touches the working database.

THE BLOCKCHAIN — blocks as mined, fully validated, unchanged 680,001 680,002 680,003 680,004 680,005 spam deleted at validation — hashed into the legacy root first, then discarded THE MONETARY VIEW — chainstate grows only with money legacy hash monetary hash + commitment C computed at every block · married to the block hash · tamper-evident, no fork

Same blocks, same order, same proof-of-work — the top row is the blockchain as everyone sees it. A Monetary Node simply refuses to let the red squares into its working database, and fingerprints both views at every step so nothing can be misrepresented. Spends of deleted outputs remain fully valid: the original data is always recoverable from block files.

How it works

  1. Full validation, filtered storage

    Every block is validated under unchanged consensus rules. Then spam outputs are deleted from the working database as each block connects — during initial sync and forever after. Chainstate is never dirtied in the first place. Detection is deterministic and syntactic; no external indexers.

  2. No spam relay

    Spam transactions never enter the mempool and are never relayed. Blocks always relay in full, byte-identical to any archival node. OP_RETURN stays capped at 83 bytes, as in Bitcoin Knots.

  3. Two fingerprints, married together

    From block 680,000, each node computes two state hashes per block — full state and clean state — bound with the block hash into a single paired commitment. Neither view can be faked or mismatched without detection. Miners can voluntarily notarize it under proof-of-work. No fork needed for any of it.

  4. Fast bootstrap, verified in the background

    New nodes can start from a snapshot verified against a hash committed in the software release (the same trust model as Bitcoin Core's assumeutxo) — then download and fully validate the entire chain in the background, from monetary peers or any full node. Eventually every node has checked everything itself.

  5. Everything stays spendable

    Spends of deleted outputs are fully validated by reconstructing the original from local block files, or fetching the old block over the existing P2P protocol and checking it against the block hash already validated. Nothing confiscated, nothing frozen, no new infrastructure assumed.

What this is — and is not

Not

  • Not a fork. Hard or soft. No consensus rule changes, block hashes unchanged, one chain.
  • Not confiscation. Every output valid today remains spendable. No coins frozen.
  • Not coordination-dependent. Each operator adopts unilaterally and can revert at any time.
  • Not censorship. Any miner may include any valid transaction; all blocks relay in full.

You get

  • ~Half the chainstate of a standard node — several GB smaller today, widening every year.
  • Faster sync and startup. Smaller working set fits in memory; validation accelerates.
  • Lower hardware floor for running a fully validating, fully sovereign node.
  • A relay network where spam faces ever-increasing friction — and block space returns to money.

The long game

The cheapest fully validating node wins. No prohibition, no fork — just attrition, until running a spam node is a costly eccentricity.

As Monetary Nodes spread — adopted for the disk savings alone — unconfirmed spam propagates through a shrinking subgraph of the network. And in the endgame, Monetary Nodes inherit the archival role: history is preserved in the block archives, spam survives only in the history books, and no working database anywhere carries it again. Bitcoin remains money because its node operators choose, one by one, to run it as money.

Technical details

The full design in plain language. Everything here is also specified formally in the BIP draft.

1. What gets classified as spam

Detection is purely mechanical — no external services, no indexers, no judgment calls. Three rules, applied to raw transaction data:

Inscriptions. Ordinals hide data inside a script branch that provably never executes: a false value followed by OP_IF ... OP_ENDIF. Since the branch can never run, it has exactly one purpose — smuggling data. The rule catches any encoding of "false" (checked by script semantics, not byte matching), so trivial evasions don't work.

Stamps. Bitcoin Stamps abuse bare multisig outputs by stuffing data where public keys should be. The rule catches keys that aren't valid points or match known data-encoding patterns.

Token markers. OP_RETURN outputs carrying registered token-protocol identifiers (BRC-20 JSON, Runes markers), from a versioned list.

Any two implementations applying these rules to the same block must reach identical answers — that determinism is what makes everything downstream possible. Operators can add stricter local filters for relay, but those never affect the shared rules. Ordinary OP_RETURN up to 83 bytes is left alone: it's already provably unspendable and never enters the UTXO set.

2. What is deleted, what is kept

A Monetary Node validates every block completely — every signature, every amount, every rule, identical to Bitcoin Core. Then, as each block connects:

Deleted: the content of spam outputs (the embedded data and its script) is removed from chainstate, the node's working database of spendable coins. This happens continuously, including during initial sync — spam never accumulates at any point in the node's life.

Kept forever: every block header (which contains every block hash — about 70MB for the whole chain, same as any node); a compact filter index recording each deleted output's ID, amount, and location (~48 bytes instead of up to tens of kilobytes); and the two state fingerprints described next.

Kept by default, prunable by choice: full block files, byte-identical to any archival node's. Filtering never touches blocks — only the working database.

3. The two fingerprints, and why they're married

Deleting spam creates two legitimate views of the ledger's state: the full view (what a legacy node holds) and the clean view (what a Monetary Node holds). From block 680,000 — which predates inscriptions — every Monetary Node computes a running cryptographic fingerprint of each: the legacy state root and the monetary state root, using the same incremental hashing (MuHash) that Bitcoin Core already ships.

A subtle point: the node maintains the legacy fingerprint without storing the spam. Each spam output is hashed into the legacy accumulator at validation time, an instant before deletion. The fingerprint of the full state survives even though the full state isn't kept — and it stays maintainable even in a future with no legacy nodes at all.

The two roots are then bound together with the block hash into a single paired commitment: C = SHA256d(block hash ‖ legacy root ‖ monetary root). This marriage means no one can present a clean-state fingerprint that doesn't correspond to the real full state of the real chain — mix-and-match is detectable with one 32-byte comparison.

Optional proof-of-work notarization. Miners can voluntarily embed the paired commitment in their coinbase (the same structural trick as SegWit's witness commitment — no rule change involved). Nodes never reject blocks over it, but wherever it appears, a miner has notarized the clean state under proof-of-work, creating a hardened audit trail that grows with adoption.

3b. The whole pipeline, in one picture

BLOCKS AS MINED — one chain, unchanged, same PoW FULL CONSENSUS VALIDATION — every signature, every rule, identical to a full node money outputs spam: hashed, then deleted ✕ — 48 B kept whole block MONETARY CHAINSTATE spendable money only · ~half the size FILTER INDEX outpoint · amount · location outpoint · amount · location outpoint · amount · location ~48 bytes per deleted output BLOCK FILES byte-identical archive · serves peers monetary root M (MuHash) legacy root L (MuHash) spam hashed in before deletion — L stays correct without the data C = SHA256d(block hash ‖ L ‖ M) computed every block · audited between peers · committed in snapshots · minable in coinbase spend of a deleted output? reconstruct the original from block files (or any peer, checked against the header chain) → validate fully

Reading the picture top to bottom: blocks arrive and are validated in full; money outputs flow into the monetary chainstate, spam is hashed into the legacy root and then deleted (leaving a 48-byte index entry), and the whole block is archived unmodified. Both roots are folded into commitment C every block. The dashed loop on the right is the rare path: someone spends a deleted output, the original is reconstructed from the archive, and the spend is validated exactly like any other. An existing node can adopt all of this via a reindex — replaying its own block files to rebuild the filtered chainstate and both hashes.

4. Spending a deleted output

Deleted outputs remain spendable — deletion is a storage decision, never a validity decision. When a block spends one, the node reconstructs the original output and validates the spend completely:

First choice: read it from local block files (the default, since blocks are kept). Fallback: request the old block from any peer using the standard getdata message that has existed since 2009, verify it against the block hash already sitting in the node's validated header chain, and extract the output. Fully trustless, no new infrastructure.

To keep block processing fast, nodes pre-fetch the needed data when they first see the spend in a transaction (before it's mined), and cap concurrent historical fetches per block so a malicious block full of ancient spam spends can only slow one node's local timing — never affect validity.

5. How new nodes join

Default path — full sync. Download every block from any peer, validate everything, delete spam as you go, compute both fingerprints and the paired commitment at every height. Monetary Nodes that keep block files serve them exactly like archival nodes, so a network of mostly Monetary Nodes syncs its own newcomers. Along the way, a syncing node can compare its paired commitments against other monetary peers — a divergence exposes a bug or a liar, but peer values are advisory only and never override local computation.

Fast path — snapshot. Modeled on Bitcoin Core's shipped assumeutxo feature, with the identical trust model. Each software release can commit to the hash of a clean-state snapshot at a checkpoint height — a hash anyone can independently recompute and audit, since the software is open source. A new node fetches the snapshot from any monetary peer, checks it against the release-committed hash (which includes the paired commitment, so a fabricated clean state can't masquerade as real), and is operational in minutes. Then, mandatorily, it downloads and fully validates the whole chain in the background — from monetary peers or any archival full node — and confirms the snapshot was honest. A bad snapshot cannot survive this. Until verification completes, the node doesn't serve snapshots to others.

6. What happens to proof-of-work

Nothing. There is one chain. Monetary Nodes accept every block a Core node accepts, follow the same most-work chain selection, and never reject a block for containing spam. The full hashrate of the network secures a Monetary Node exactly as much as it secures any other node. The two fingerprints are bookkeeping over the same chain — not competing chains.

7. The monetary endgame: spam extinction

TODAY AS SPAM COMPOUNDS ENDGAME $ $ legacy node monetary node $$$ $ heavier · pricier same lean node $$$$$ $ abandoned the archival layer REACHABLE NODES more spam → heavier legacy node → operators switch → monetary share grows → spam starved of relay the loop runs until the red is gone

The friction on spam is designed to increase with every operator who switches. Each new Monetary Node is one less machine relaying spam, one less mempool accepting it, one more peer that syncs newcomers without it. Meanwhile legacy nodes grow steadily more cumbersome to run — their chainstate bloating with every inscription, their sync times lengthening, their hardware demands climbing — while the monetary alternative gets comparatively cheaper every year. The economics compound in one direction: Monetary Nodes make up more and more of the network not because anyone mandates it, but because running the heavier node buys the operator nothing.

Alongside the economics runs the social layer. Bitcoin has always been governed, in the last instance, by what its node operators collectively refuse to subsidize — that is how every contentious era has ultimately been settled. As monetary policy becomes the network's default posture, the social consensus hardens with it: spam is not attacked, not confiscated, not forbidden — it is soundly rejected by the culture, starved of relay, starved of storage, and faded out into oblivion.

The endgame still has to keep two things alive: validating spends of long-deleted outputs, and syncing new nodes from genesis. Both need full historical blocks, so Monetary Nodes inherit the archival role. Block-file retention is the default configuration; pruning warns the operator of network-level consequences; the population of block-serving peers is monitored. The legacy fingerprint needs no legacy nodes at all — it's maintained by the monetary network itself, forever.

The end state: spam is preserved in the history books, because Bitcoin's history is immutable — but no working database anywhere carries it again, and no one is left who will carry it forward.

8. Known costs, stated honestly

Compact block relay: because spam never sits in a Monetary Node's mempool, relaying a spam-bearing block requires one extra round trip to fetch the missing transactions — tens of milliseconds, already borne by filtering nodes today.

Miners follow fees: this proposal doesn't bind miners, and direct-to-miner submission bypasses relay filtering entirely. What it changes is what every sovereign node operator subsidizes with their own disk and bandwidth — and it makes the refusal costless. The friction on spam grows with adoption; it is attrition, not prohibition.

Classification maintenance: the token-marker list is versioned and will need updates as protocols evolve. The inscription and stamp rules are structural and evasion-resistant by design.

9. Implementation

Reference implementation planned as a Bitcoin Knots patchset — Knots already ships the datacarrier limits and inscription filters this design extends. Changes touch policy, indexing, and peer services only; consensus code is untouched. A Bitcoin Core port is invited. Test vectors for classification and state fingerprints will be published alongside.

Full BIP draft · "The Cat" discussion · @marketanarchy21

Read more