I stripped every spam carrier out of 194,863 Bitcoin blocks, wrote the result to disk, then re-verified all 194,863 against their own headers reading nothing but the stripped store.
Zero failures. No fork. No confiscation. Nobody's permission.
Here's the mechanism and what fell out of it.
—
WHY A BLOCK SURVIVES LOSING ITS DATA
A block's merkle root is computed over txids. Store the 32-byte txid of every transaction you modify or discard, and nothing downstream ever needs to re-derive it from transaction data.
So the data can go and the block still verifies against its header — against real proof-of-work.
The stored txids are self-verifying. Fabricate one and the merkle root stops matching the header. The list can't be forged.
Transactions you don't touch cost nothing extra; the reader computes those txids itself. Only modified transactions pay 32 bytes.
This is what the standard objection misses. "You can't remove OP_RETURN, it's committed inside the txid" is true only for designs that *recompute* txids. It doesn't apply when the txid is stored.
—
WHAT CAME OUT
Blocks 767,430–962,292 on a fully synced Knots node:
Inscription envelopes (taproot witness): 37.1 GB
Stamp-style bare multisig: 77.5 MB
OP_RETURN over 83 bytes: 12.3 MB
Oversized scriptSig: 13.8 KB
Total spam: 37.2 GB — 12.56% of block bytes in that era.
80.66% of transactions were left completely untouched.
—
THE DETECTOR THAT LIED TO ME
My first run reported 0 bytes of stamp-style bare multisig. I published that.
It was wrong. The detector flagged keys whose first byte wasn't 02, 03 or 04 — but Stamps deliberately use those prefixes so their outputs pass standardness. It caught nothing and returned a clean zero, which is the worst possible failure, because a zero reads as a finding.
The fix: check whether each key is actually a point on secp256k1. Compute y² = x³ + 7 mod p, test quadratic residuosity by Euler's criterion. A real pubkey always passes. Arbitrary data passes about half the time, so one key proves little — but a bare multisig carries several and the odds halve with each one.
Real figure: 77.5 MB. Cross-checked against an independent UTXO-set scan that found 2.6M unspent bare multisig outputs.
—
THE FINDING I DIDN'T EXPECT
806,626 outputs were dropped from block storage. Each kept a filter entry — outpoint, amount, scriptPubKey, height — so a future spend could still be validated locally, with no peer involved.
How many of those 806,626 were ever spent?
Seven.
One in 115,000. Monetary outputs get spent because someone wants the coins. Data carriers sit forever because nobody ever wanted the coins, only the bytes.
That's a measured distinction between money and data, not an opinion about it.
All seven had their filter entry. Six had their ECDSA signatures re-verified against scriptPubKeys recovered from the index — one a 2-of-2 requiring both keys. Cryptographic proof that deleting an output doesn't strand it.
—
AND THE SEVENTH
The seventh failed verification, and the reason is more interesting than the six successes.
SIGHASH_ALL signs the spending transaction's outputs, not just its inputs. That transaction spent a bare multisig output *and created another one* — which my stripper removed. The signature is valid; the preimage it committed to no longer exists.
Stamps transactions consume and produce bare multisig by design, so they're precisely the transactions this hits.
The precise statement: transactions retained whole (80.66%) keep full signature re-verifiability. Modified ones (19.34%) don't. All were validated in full, once, by Knots, when the block was connected.
I'd previously written "stripped transactions cannot be re-verified." Too loose. This is narrower and it's the correct claim.
—
WALLETS STILL WORK
Balances and transaction history computed from the stripped store, diffed against an independent Electrum server reading complete blocks.
32 of 32 completed comparisons identical. Zero invented transactions.
—
WHAT'S NOT BUILT
Monetary IBD is design only and has never been adversarially reviewed. The daemon isn't built. There's no alpha.
A stripped block can't be served to a legacy node. If monetary nodes ever became a large share of the network, who serves the chain is an open question I don't have a good answer to.
Three published figures from this project have been wrong and retracted. Probably more to come.
—
WHAT I NEED
Rerun the measurements on your own node and tell me where we disagree.
Attack the IBD design. Every earlier version of this failed on second inspection, and this one hasn't been inspected.
Argue about the classification boundaries. Where should the line sit for OP_RETURN? For dust? Runes mostly fall under 83 bytes and currently pass — is that right?
Tools are standard-library Python, no dependencies. Every raw log is in the repo. If a number in a write-up disagrees with a log, the log is right.
github.com/sambitcoin/Bitcoi…