Spurious Dragon hard fork
Mainnet 2016-11-22
The chain ID was included in signatures to prevent their reuse on other chains (replay), and empty accounts were cleaned up.
What changed
- Users
- With the chain ID included in transaction signatures, replay was prevented, where someone copies a transaction sent on mainnet and executes it again on another chain. After Ethereum and Ethereum Classic split earlier that year, a transfer made on one chain could be reproduced as is on the other, so users had to be careful themselves. After this fork, the network rejects signatures with a different chain ID. How wallets are used did not change.
- Wallet & app developers
- Wallets and libraries changed to build transactions according to a new standard (EIP-155) that puts the chain ID in the signature. Each chain has its own number, such as 1 for mainnet, so it was necessary to tell at the signing stage which chain a transaction was meant for. For contract developers, a cap of about 24KB (EIP-170) was set on the size of code that can be deployed at once, so contracts larger than this had to be split into several and deployed that way.
- Node operators
- Because of the attack that slowed the network in the fall of that year, a large number of empty accounts with neither balance nor code remained in the state. This fork cleaned up those empty accounts and ensured that empty accounts would no longer remain in the state (EIP-161). The amount of data nodes have to hold shrank, which eased the burden of syncing and block processing. Operators had to upgrade their clients to the new version before the fork block, and nodes that did not upgrade split off onto a different chain after the fork.