97% of This Bitcoin Fork's Transactions Are Someone Else's Chain

I’ve been building a research database for an obscure Bitcoin fork — BLAKE2b proof-of-work, same address format as Bitcoin, same transaction format, same keys. The kind of chain that lives on one small exchange and gets talked about on three Telegram channels. I wanted to see what the on-chain activity actually looked like.

So I pointed a scanner at a single day of blocks — October 11, nothing special about it — and counted transactions. 9,160 of them. Then I filtered for ones that were actually fork transactions. 136.

The other 9,024 weren’t fork users at all. They were Bitcoin spenders moving coins on the main chain, and because this fork never shipped mandatory replay protection, the exact bytes they signed were also valid on the fork. So the fork mined them too. The coins’ fork twins moved as a side effect that nobody involved asked for.

Every “transactions per day” number on every explorer for this chain is lying. By about 60x.

Why the fork sees Bitcoin’s traffic

A chain fork at a specific block height inherits every address and every unspent output that existed up to that point. If you held 1 BTC pre-fork, you now hold 1 BTC on Bitcoin and 1 of whatever-the-fork-called-its-coin on the fork. Same key spends both.

That’s fine. The problem is what happens when you spend only one of them.

Bitcoin’s transaction format doesn’t commit to which chain the transaction is for. It commits to inputs, outputs, and a signature over those. The chain id lives in the mind of the person broadcasting it. If a wallet signs a Bitcoin transaction the ordinary way and someone — anyone — copies those bytes and submits them to a fork node, the fork is going to look at the signature, check it, see that it’s valid for the pre-fork UTXO it still remembers, and mine the transaction.

Nobody attacked anybody. The transaction was always valid on both chains. The fork just gets to witness every Bitcoin spend from any pre-fork address and tag along.

The cure is replay protection — making the fork’s signatures not valid on Bitcoin, so a wallet has to deliberately opt into fork spends. I wrote about the one-byte trick that implements it in a wallet last week: the fork uses a reserved sighash flag 0x21 that Bitcoin rejects outright. If the signature carries that flag, you know a human running a fork-aware wallet signed it on purpose. If it doesn’t, you’re just watching Bitcoin.

The scanner

Here’s the entire native-vs-replay detector:

That’s it. Walk every input of a transaction, pull out every DER or Schnorr signature in its witness and scriptSig, read the last byte, check whether bit 0x20 is set. If any signature has it, this is a native fork transaction. If none do, you’re looking at a Bitcoin spend that got mirrored.

I validated the test on 14 random Bitcoin transactions. None of them had the bit set. All 14 confirmed to the Bitcoin chain too — meaning they were, in fact, replays. Boring, but it’s the kind of boring you need before you trust the filter.

The result goes into one column:

ALTER TABLE txs ADD COLUMN native INTEGER;

And now every query against transaction data has a WHERE native = 1 clause or it’s wrong.

What this breaks

Every public stat about this fork is actually a measurement of Bitcoin plus a sliver of fork activity, with the sliver un-separated. Which means:

• The two biggest explorer sites both show “transactions per day” counts that are almost entirely Bitcoin. Their “largest transaction today” is almost always a Bitcoin exchange hot wallet rotation that happens to touch pre-fork coins.
• One of them has a “pre-fork coins moved” alert. On October 12 it fired for a 4,582-coin transaction, a 2,259-coin transaction, and a 1,469-coin transaction. All three were Bitcoin spends. The fork twins of those coins moved, yes, but then landed in change outputs and have sat there untouched ever since. Nobody sold anything. The alert looked like whales dumping and it was office furniture moving.
• A third site shows a “total claimed” number pushing 1.6 million coins. “Claimed” implies deliberate action. The number is almost entirely replays — coins that landed at a new address because their Bitcoin twin got spent to that address, and the fork copied the move. The holder didn’t claim anything. They don’t know they received anything.

Once you have native = 1 and you re-pull every stat, the chain looks completely different. The real activity is about 2 user-initiated transactions per block. The real “pre-fork spenders” are two sellers quietly paying 50 coins a day each to the exchange’s deposit address. The real whale is still sitting on 11,720 coins and hasn’t moved them since the fork happened.

That’s a chain. The thing the explorers show you is a lie-shaped shadow of a different chain.

The lesson that generalises

The specific finding is about one small fork. The general shape shows up anywhere you process a stream of events and the stream has two source populations mixed together.

You’ll find versions of this everywhere once you look. Google Analytics sessions include a lot of bot sessions. Error logs include a lot of health-check failures. Signup funnels include a lot of password-reset emails. A chart that goes up looks the same whether the thing you care about is growing or the noise around the thing is growing. The gap between them is one well-chosen filter column and about three hours of writing the filter.

The cheapest superpower in data work is deciding, early, which rows in your table are the thing and which rows are the thing’s shadow. On this chain the filter is one bit in one byte. On your product it’s probably a couple of columns. Write the filter before you write the dashboard, or you’ll be making decisions on a 97% lie.