The Ethereum Foundation officially announced its fourth major network upgrade on November 18, 2016, detailing the technical specifications of the Spurious Dragon hard fork. Scheduled to activate at block 2,675,000 — estimated for November 22 — the upgrade represented the culmination of a two-month battle against sophisticated denial-of-service attacks that had crippled the network since September. But beyond the immediate security fixes, Spurious Dragon introduced fundamental changes to Ethereum’s architecture that would shape the platform’s development for years to come.
TL;DR
- Ethereum Foundation announced Spurious Dragon hard fork at block 2,675,000 on November 18, 2016
- Fork addressed aftermath of Shanghai DoS attacks that created 19 million empty accounts
- EIP-155 introduced replay attack protection with chain ID separation
- EIP-170 set a 24KB smart contract size limit for the first time
- EIP-161 implemented state cleanup to remove ghost accounts from blockchain
- ETH traded at $9.48 with a market cap of $816 million
The Shanghai Attacks: How We Got Here
The story of Spurious Dragon began during the second Ethereum Developers Conference in Shanghai, held in September 2016. A malicious actor — or group of actors — began systematically exploiting weaknesses in the Ethereum Virtual Machine’s gas pricing mechanism. Certain EVM opcodes were significantly underpriced relative to their computational cost, allowing attackers to flood the network with transactions that consumed enormous resources while paying minimal gas fees.
The attacker discovered a particularly insidious exploit: by leveraging the selfdestruct opcode, they could create empty accounts on the blockchain at almost no cost. These ghost accounts served no purpose but bloated the blockchain state, making it increasingly expensive for nodes to store and sync the chain. By November, approximately 19 million such empty accounts had been created.
The first response came on October 18 with the Tangerine Whistle hard fork, which repriced the most egregiously underpriced opcodes through EIP-150. This provided immediate relief to miners and node operators, but it was always understood that a second fork would be necessary to address the accumulated damage and implement deeper protections.
EIP-155: The Birth of Replay Attack Protection
Perhaps the most far-reaching change in Spurious Dragon was EIP-155, which introduced replay attack protection to Ethereum. Prior to this upgrade, a transaction signed on one Ethereum chain could theoretically be rebroadcast on another — a problem that had become acute following the DAO hack and the subsequent Ethereum Classic chain split.
EIP-155 solved this by introducing a chain ID field into transaction signatures. This meant that a transaction created on the main Ethereum network could not be replayed on the testnet, on Ethereum Classic, or on any future forked chain. The change was backwards compatible — old-format transactions would still be accepted — but users were strongly encouraged to upgrade their wallet software to take advantage of the new protection.
This seemingly technical change had profound implications for Ethereum’s long-term ecosystem. By making chains cryptographically distinct, EIP-155 laid the foundation for the multi-chain future that would later include thousands of Layer 2 networks and sidechains.
EIP-170: Smart Contract Size Limits Change Development Forever
Another significant change was EIP-170, which introduced a maximum smart contract size of 24,576 bytes (24KB). Before this limit, developers could deploy contracts of arbitrary size, which posed a growing risk to network resources. Large contracts required more time and computation to process, creating potential attack vectors similar to those exploited during the Shanghai attacks.
The 24KB limit forced a fundamental shift in how smart contracts were designed. Developers could no longer create monolithic contracts containing all their application logic. Instead, they had to adopt patterns like the proxy pattern, where a small delegate contract forwards calls to a larger implementation contract. This constraint paradoxically led to better, more modular contract architectures and became a standard best practice in Ethereum development.
EIP-161: Cleaning Up 19 Million Ghost Accounts
The most direct response to the Shanghai attacks was EIP-161, which addressed the blockchain state bloat caused by millions of empty accounts. Rather than attempting to delete all 19 million accounts in one operation — which would have been computationally infeasible — EIP-161 implemented an elegant lazy deletion mechanism.
Under the new rules, any empty account that was touched by a transaction would be automatically removed from the state. This meant that over time, as normal network activity interacted with these ghost accounts, they would gradually disappear. Within days of the fork, approximately 4 million empty accounts had been cleared through this process.
The implementation was not without complications. A consensus bug was discovered shortly after the fork when geth and Parity produced different blocks at block 2,686,351. The issue centered on whether empty accounts should be deleted even when a transaction resulted in an Out of Gas exception. The Ethereum community had actually flagged this potential problem before the fork, but the edge case proved thornier than expected in practice.
Client Updates and Network Preparation
To prepare for Spurious Dragon, users and miners needed to upgrade their Ethereum clients. The Foundation released geth v1.5.2, Parity v1.4.4, and Ethereum Wallet/Mist v0.8.7. Anyone running older client versions would find themselves on an incompatible chain after the fork, unable to interact with the post-fork network.
The upgrade also affected the Morden testnet, which was forked at block 1,885,000 in parallel with the mainnet upgrade. This was particularly important because EIP-155’s replay protection extended to test networks, preventing testnet transactions from being rebroadcast on the main chain.
Why This Matters
The Spurious Dragon hard fork was a defining moment in Ethereum’s technical evolution. The four EIPs it introduced — EIP-155, EIP-160, EIP-161, and EIP-170 — addressed immediate security concerns while establishing architectural principles that remain foundational to Ethereum today. EIP-155’s chain ID system became essential as the ecosystem expanded to include thousands of chains. EIP-170’s contract size limit shaped the entire field of smart contract development. And the lazy deletion mechanism of EIP-161 demonstrated how elegant protocol-level solutions could address seemingly intractable problems.
The fork also highlighted the resilience of the Ethereum development community. Just months after the traumatic DAO hack and the resulting chain split, developers successfully coordinated another complex network upgrade while simultaneously managing an active attack on the network. The experience reinforced the importance of rigorous testing, community coordination, and the ability to respond rapidly to emerging threats — lessons that continue to inform Ethereum’s development process today.
Disclaimer: This article is for informational purposes only and does not constitute financial or technical advice. Cryptocurrency investments carry significant risk. Always conduct your own research before making investment decisions.