EIP1240 - Remove Difficulty Bomb

# Simple Summary

The average block times are increasing due to the difficulty bomb (also known as the "ice age") slowly accelerating. This EIP proposes to remove the difficulty increase over time and replace it with a fixed difficulty targeting 15 second blocks.

# Abstract

Starting with FORK_BLOCK_NUMBER the client will calculate the difficulty without considering the current block number.

# Motivation

The difficulty bomb operates under the assumption that miners decide what code economic participants are running, rather than economic participants deciding for themselves. In reality, miners will mine whatever chain is most profitable and the most profitable chain is the one that economic participants use. If 99% of miners mine a chain that no economic participants use then that chain will have no value and the miners will cease mining of it in favor of some other chain that does have economic participants. Another way to put this is that miners will follow economic participants, not the other way around.

# Specification

# Remove Difficulty

For the purposes of calc_difficulty, if block.number >= FORK_BLOCK_NUMBER then change the epsilon component to 0 rather than having it be a function of block number.

# Rationale

With the difficulty bomb removed, when Casper is released it will be up to economic participants to decide whether they want the features that Casper enables or not. If they do not want Casper, they are free to continue running unpatched clients and participating in the Ethereum network as it exists today. This freedom of choice is the cornerstone of DLTs and making it hard for people to make that choice (by creating an artificial pressure) does not work towards that goal of freedom of choice. If the development team is not confident that economic participants will want Casper, then they should re-evaluate their priorities rather than trying to force Casper onto users.

Author Personal Note: I think we will see almost all economic participants in Ethereum switch to PoS/Sharding without any extra pressure beyond client defaults.

# Backwards Compatibility

This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number.

# Test Cases

Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients.

# Implementations

The yellow paper implements this change in https://github.com/ethereum/yellowpaper/pull/710