EIP-InvalidBlockList.md

Preamble

EIP: <to be assigned>
Title: Invalid block list
Author: Micah Zoltu <@MicahZoltu>
Type: Standard Track 
Category: Core 
Status: Draft
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>

Simple Summary

Provide a configuration to ignore specified block hashes for make a fork easier to follow.

Abstract

It would be nice if it were easy for clients to fork via block hash blacklist in config or environment variable (standardized across clients ideally). For example, I could put into a config somewhere that I will not accept block hash 0x1234abcd and any blocks built on that block will similarly be unacceptable. This would be useful both on test net and live net in the face of attack. It allows users to do out-of-band coordination and get onto a healthy network without requiring an immediate client update. The clients can also bake in blacklists like this for future releases, but this relieves the pressure quite a bit.

Motivation

In the current Ropsten situation, people could (voluntarily) simply choose a fork point with their peers without any buy-in from Geth or Parity maintainers and run from they. This is useful for development teams who are trying to test their dApps but running into problems with Ropsten. As long as the team has at least one testnet miner amongst them, they can just pick a fork block amongst themselves and blacklist it, allowing them to continue development while waiting for the community to come up with a better solution.
In a live net attack, the same thing could happen where someone can start mining with a blacklisted block and advertise as much to the community. If the community agrees that there is in fact an attack and switch that person likely made some money since they were one of the first to mine on the fork, giving some financial incentive to pro-actively identifying network attacks and forking them quickly. Ideally in both Geth and Parity this block blacklist could be updated live (no resync) and be editable in a UI, since in an attack scenario end-users will need to set it while waiting for client updates with backed in blacklists.

Copyright

Copyright and related rights waived via CC0.

Geth or Parity maintainers and run from they

Geth or Parity maintainers and run from there

fact an attack and switch that person likely

fact an attack and switch, then that person likely

Ideally in both Geth and Parity this block blacklist could be updated live (no resync) and be editable in a UI, since in an attack scenario end-users will need to set it while waiting for client updates with backed in blacklists.

That should probably read something like, "clients should provide an easy mechanism for adding to/removing from this blacklist that doesn't require the client resync." The exact mechanism for this configuration is TBD, but should be standardized across clients/platforms (perhaps a separate EIP for configuration standardization?).

The phrasing should probably be turned into a proposal rather than a request. The current phrasing is more of a question. e.g., "It would be nice if ..."

Also rather than using examples it should be more specific on what exactly a client should do.