Replay attacks, explained: how one signature can spend your coins on two chains
Signal21 Editorial Desk
Readers send us questions, and last week one of them asked about replay attacks and what they would mean for the BLAKE2b chain. It is a technical subject that turns out to concern anyone holding coins through a fork, so it is worth taking apart in plain terms. Start with what a split leaves behind. Suppose Bitcoin genuinely separates into two chains. Before the split you hold one bitcoin; after it, both chains carry the same history up to the fork point, so the unspent output that was yours is now yours on each side. That alone causes no trouble. The trouble begins if both networks still accept the same transactions. You decide to sell your coin on the first chain, so you sign a transaction and broadcast it, and from the moment it is public anyone can take that exact transaction and rebroadcast it on the other network. If it is valid there too, it confirms there too. That is a replay attack, and the important part is what it is not: nobody has taken your private key, and nobody can change where the money goes. What executes on the second chain is the transaction you signed yourself, down to the byte. You believed you were moving coins on one branch, and you moved them on both.
This is why a hard fork can ship replay protection, and the idea behind it is simple: make a transaction signed for one chain technically invalid on the other. Bitcoin Cash did exactly that in 2017 with a fork-specific signature digest, SIGHASH_FORKID, which changes the message a signature commits to, and which the new chain then required from every transaction once the fork activated. Transactions built for one network therefore failed on the other, and the separation ran in both directions. The second method belongs to the holder rather than to the protocol, and it consists of splitting your coins: you first make a transaction that can only be valid on one of the two chains. From that point the histories diverge, the unspent outputs are no longer the same on each side, and later transactions can no longer simply be copied from one network to the other.
Which brings us back to the BLAKE2b chain that activated at block 961,640 on August 30. It does carry a mechanism of this kind, an opt-in signature format called SIGHASH_UNIFIED, specified in Knots pull request 357, whose signed message differs from the three signature hashes in use today, so a signature that opts in will not verify on a chain that does not implement it. The project's own documentation is unusually candid about the limits, describing that protection as incidental to the new message, one-way, and per signature, and stating plainly that ordinary signatures stay valid and still replay. That sentence is the whole story: the protection applies only when the spender asks for it, only to the spend it was used on, and only in one direction. Anyone signing the way wallets sign today gets none of it. It is also worth remembering that this fork changed the proof-of-work algorithm and not the address, key or signature formats, which is precisely why the same authorization can still mean something on both networks.
The point, then, is not that a replay attack lets someone hack your bitcoin, because it does not. The real risk is that around a fork, one cryptographic authorization can unintentionally spend your coins on two different networks. The practical version is easy to picture. A new fork appears, and afterwards you hold one bitcoin on Bitcoin and a matching balance of the fork's coin. Someone then offers, publicly, to buy those fork coins for a few dollars, and since they look close to worthless to you, why not. If your coins were never split and you sign that transfer the ordinary way, the same transaction can be copied onto Bitcoin, where it spends the very same pre-fork output. What leaves your wallet is then not the fork's coin. It is your bitcoin. The fork's own documentation gives the defense, and it is the split described above: before spending on the other chain, send your coins to yourself on the BLAKE2b chain using the opt-in format, and wait for that payment to confirm.
On the market, Bitcoin has held the ground it took last week. After the September 3 run to an intraday high of $82,283, its first touch of the $81,000 to $84,000 band, it closed above $80,000 again on September 6 at $80,339 and trades near $79,200 as we publish. The $75,600 line has not been tested since, and our three horizon views are unchanged.
This is general market commentary, not investment advice or a recommendation to buy or sell any asset.
Sources
- Bitcoin BLAKE2b: Bitcoin for developers, accessed 2026-09-07
- Bitcoin BLAKE2b: Bitcoin common questions, accessed 2026-09-07
- Bitcoin Knots repository: pull request 357, unified opt-in sighash for all transaction types, 2026-08-13
- Bitcoin Cash upgrade specifications: replay protected sighash, accessed 2026-09-07
- Bitcoin Cash protocol reference: BCH-UAHF, accessed 2026-09-07
- Coinbase: BTC-USD spot price and daily candles, accessed 2026-09-07