When is the date for the next fork?
https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/Hard Fork No. 4: Spurious Dragon
Posted by Hudson Jameson on November 18th, 2016.
The Ethereum network will be undergoing a hard fork at block number 2,675,000, which will likely occur between 15:00 and 16:00 UTC on Tuesday, November 22, 2016. A countdown timer can be seen at
https://fork.codetract.io/. The Morden test network will be undergoing a hard fork at block number 1,885,000.
As a user, what do I need to do?
Download the latest version of your Ethereum client:
Latest version of Ethereum Wallet/Mist (v0.8.7)
Latest geth client (v1.5.2)
Latest Parity client (v1.4.4)
Latest ruby-ethereum client (v0.11.0)
What happens if I do not update my client?
If you are using an Ethereum client that is not updated for the upcoming hard fork, your client will sync to the pre-fork blockchain once the fork occurs. You will be stuck on an incompatible chain following the old rules and you will be unable to send ether or operate on the post-fork Ethereum network.
Importantly, if your client is not updated, it also means that any transactions you make will still be susceptible to replay attacks.
What if I am using a web or mobile Ethereum wallet like MyEtherWallet or Jaxx?
Ethereum websites and mobile applications that allow you to store ether and/or make transactions are running their own Ethereum client infrastructure to facilitate their services. Generally, you do not need to do anything if you use a third party web based or mobile Ethereum wallet. However, you should still check with your web or mobile Ethereum wallet provider to see what actions they are taking to update for the hard fork and if they are asking their users to take other steps.
In particular, you should ensure that transactions are generated with the new replay-protected EIP 155 scheme.
What do I do if my Ethereum client is having trouble syncing to the blockchain?
Make sure you have downloaded the latest version of your Ethereum client.
If you are using Geth or Mist, refer to this Ethereum StackExchange thread.
If you are using Parity, refer to this section of the Parity wiki.
Why are we proposing to hard fork the network?
“Spurious Dragon” is the second hard fork of the two-round hard fork response to the DoS attacks on the Ethereum network in September and October. The previous hard fork (a.k.a “Tangerine Whistle”) addressed immediate network health issues due to the attacks. The upcoming hard fork addresses important but less pressing matters such as further tuning opcode pricing to prevent future attacks on the network, enabling “debloat” of the blockchain state, and adding replay attack protection.
What changes are a part of this hard fork?
The following Ethereum Improvement Proposals (EIPs) describe the protocol changes implemented in this hard fork.
EIP 155: Replay attack protection – prevents transactions from one Ethereum chain from being rebroadcasted on an alternative chain. For example: If you send 150 test ether to someone from the Morden testnet, that same transaction cannot be replayed on the main Ethereum chain. Important note: EIP 155 is backwards compatible, so transactions generated with the “pre-Spurious-Dragon” format will still be accepted. However, to ensure you are protected against replay attacks, you will still need to use a wallet solution that implements EIP 155.
Be aware that this backwards compatibility also means that transactions created from alternative Ethereum based blockchains that have not implemented EIP 155 (such as Ethereum Classic) can still be replayed on the main Ethereum chain.
EIP 160: EXP cost increase – adjusts the price of `EXP` opcode so it balances the price of `EXP` with the computational complexity of the operation, essentially making it more difficult to slow down the network via computationally expensive contract operations.
EIP 161: State trie clearing – makes it possible to remove a large number of empty accounts that were put in the state at very low cost as a result of earlier DoS attacks. With this EIP, ’empty’ accounts are removed from the state whenever ‘touched’ by another transaction. Removal of the empty accounts greatly reduces blockchain state size, which will provide client optimizations such as faster sync times. The actual removal process will begin after the fork by systematically performing `CALL` to the empty accounts that were created by the attacks.
EIP 170: Contract code size limit – changes the maximum code size that a contract on the blockchain can have. This update prevents an attack scenario where large pieces of account code can be accessed repeatedly at a fixed gas cost. The maximum size has been set to 24576 bytes, which is larger than any currently deployed contract.
