Replay Attack Alarm Grows as BIP-110 Backers Brand Bitcoin ‘Spamcoin’

A planned revival of the failed BIP-110 stalled fork is putting an old cryptocurrency hazard back in the spotlight: replay attacks, where a transaction intended for one blockchain can potentially be copied onto another.

Imagine someone holds 1 bitcoin before a hard fork. When the blockchain divides, the same historical unspent transaction output, or UTXO, exists on both networks. In practical terms, the owner controls corresponding coins on each chain with the same private key.

Trouble begins if both networks also recognize the same transaction and signature rules. Suppose the owner sends the coin to an exchange on Chain A. If that signed transaction is also valid on Chain B, another party can copy it and broadcast it there. Chain B may accept the transaction because, cryptographically, nothing distinguishes the authorization from one intended for its network.

That is a replay. Nobody steals the private key or breaks Bitcoin’s cryptography. The problem is simpler: the user created one valid authorization, but two blockchains recognize it. And while the BIP-110 chain sits at block height 961636, people spending BTC are moving BIP-110 coins, or whatever they will be called going forward, at the same time, without even knowing.

Replay protection prevents that crossover by making transactions on the competing networks distinguishable. One method changes the signature hash, commonly called sighash, so a transaction signed for one chain fails the consensus rules of the other.

Mandatory protection makes this distinction part of the fork itself. Opt-in protection leaves ordinary transactions potentially compatible with both chains and requires users to deliberately use a chain-specific mechanism when they want to separate their coins.

That distinction has become important for BIP-110. The emerging plan does not appear to provide automatic, comprehensive two-way replay protection. Instead, at least according to Discord discussions, Bitcoin Knots is implementing a new sighash option that can create a transaction valid on the RDTS chain but invalid under Bitcoin Core.

He added that there would be ways to separate transactions but argued that “legitimate Bitcoin transactions need to remain valid on Bitcoin.” His reasoning rests on his assertion that the BIP-110/RDTS minority network is Bitcoin, while the overwhelmingly dominant SHA-256d Bitcoin blockchain is the breakaway network.

Dashjr has repeatedly used derogatory names for the dominant Bitcoin chain, including “Spamcoin” and “Bpedo,” a reference incorporating “pedo.” He has characterized that network as the altcoin while continuing to describe the BIP-110 branch as the legitimate Bitcoin.

That characterization collides with observable network activity. BIP-110 miner signaling peaked at roughly 2.53%, and when its consensus rules took effect Aug. 8, its minority branch produced only two immediate blocks before stalling. Bitcoin’s dominant chain continued operating while the gap widened by hundreds of blocks. A few other BIP-110 blocks have been mined at an extremely slow rate.

Moreover, the Bitcoin community is frustrated with Dashjr’s repeated claims and the intended opt-in styled replay protection being discussed is a bone of contention. “Lol. Luke isn’t gonna launch his sh**coin with replay protection, is he? I guess it won’t be listed on exchanges then,” one X user wrote on Wednesday.

“This has crossed the line from nonsense into bad-actor behavior. Spreading false information like this can cause real financial harm to Bitcoiners.”

Under the approach now being discussed on the Bitcoin Knots Discord channel, ordinary transactions may remain replayable because RDTS intends to maintain compatibility with Bitcoin Core’s existing sighash types. Users wanting RDTS-specific protection would need to use the new sighash, requiring supporting wallet software or hardware-signing firmware.

Users can also attempt to split their coins manually. A Bitcoin transaction containing data that RDTS rejects could create an output existing only on the dominant chain. Conversely, the proposed RDTS-specific sighash could produce a transaction that RDTS accepts, but Bitcoin Core rejects.

If the BLAKE2b fork proceeds around Sept. 1, replay protection will therefore be more than an obscure technical detail. It will become a practical test of whether users can safely separate assets inherited from the same Bitcoin history, even as Dashjr continues making the far larger claim that the network carrying virtually all of Bitcoin’s hashrate, liquidity and economic activity is somehow the altcoin.