When the Ethereum network split into ETH and ETC on July 20, 2016, both chains shared identical transaction formats and account histories. This created a vulnerability: a transaction signed on one chain could be "replayed" on the other.
What Is a Replay Attack?
A replay attack occurs when a valid transaction from one blockchain is broadcast on another blockchain where it is also valid. After the DAO fork:
- Alice sends 10 ETC to Bob on the ETC chain
- An attacker copies that signed transaction and broadcasts it on the ETH chain
- Since the transaction format and signing scheme were identical, Alice also sends 10 ETH to Bob — unintentionally
Why It Happened
Both chains diverged from the same state at block 1,920,000. All accounts, balances, and contract code were identical on both chains. Signed transactions didn't specify which chain they were intended for, making them valid on both.
The Solution: Chain ID (EIP-155)
EIP-155 introduced a chain identifier into the transaction signing process:
- Ethereum (ETH): Chain ID 1
- Ethereum Classic (ETC): Chain ID 61
- Mordor Testnet: Chain ID 63
With EIP-155, the chain ID is incorporated into the transaction hash before signing. A transaction signed for chain 61 produces an invalid signature on chain 1, and vice versa.
Implementation on ETC
ETC implemented EIP-155 replay protection via the Spurious Dragon equivalent changes. After activation:
- All new transactions include the chain ID in the signature
- Legacy transactions (without chain ID) are still accepted for backward compatibility
- Wallets and libraries automatically include the chain ID when constructing transactions
Practical Impact
Today, replay attacks between ETH and ETC are effectively eliminated for any transaction using EIP-155 signing. All modern wallets and libraries use this format by default.
The chain ID solution was one of the earliest examples of both chains cooperating on a technical standard that benefited users of both networks.