Add a ECIP for adding blockchain origin to transactions.

ECIPs/ECIP-1011.md

@@ -0,0 +1,39 @@
+### Title
+
+    ECIP: 1011
+    Title: Transaction Replay Prevention
+    Status: Draft
+    Type: Standard
+    Layer: Consensus (hard-fork)
+    Author: Marcus R. Brown <[email protected]>
+    Created: 2016-09-25
+
+### Abstract
+This ECIP describes a strategy for preventing transaction replays (or "replay attacks") both on the blockchain and across forks. It adds a new field to the transaction header that specifies the origin of the blockchain where the transaction should be considered valid.
+
+### Motivation
+When a blockchain is created or a hard fork of an existing blockchain occurs, a distinct block is confirmed on the blockchain that represents either the "Genesis" (creator block) or fork point. Transactions created on blockchains (or a fork of an existing blockchain) that share an identical consensus algorithm can be replayed across both blockchains or forks under the following conditions:
+
+- The address of the account that created the transaction is the same on both blockchains.
+- The balance of the account that created the transaction contains enough Ether for the transaction to be valid on both blockchains.
+- The nonce of the account that created the transaction is lower or equal to the nonce of the account on another blockchain.
+
+In the case of a fork of an existing blockchain, it is usually undesirable to replay transactions occurring on the pristine blockchain onto the forked blockchain. In the case of similar but separate blockchains (e.g. a "testnet" versus a "mainnet"), it is usually undesirable to replay a transaction originating on one blockchain onto another.
+
+### Specification
+A new field is added to the transaction header (called Origin Block Hash, formally `To`) that contains the hash of a block on a blockchain where the transaction originates. The value of the `To` can be any one of the following:
+
+- A null hash, consisting of all zeros
+- The hash of the Genesis block
+- The hash of the most recent fork block
+
+A null hash is permitted as the value for `To` for transactions that are generated and signed offline. It can be assumed that any transaction where `To` contains the null hash is not safe from transaction replays across another blockchain for fork.
+
+When the Genesis block hash is specified as the value for `To`, then it can be assumed that the transaction is safe from transaction replays across blockchains with a different Genesis block. This may be sufficient for blockchains where transactions originating from the same account of one blockchain hold no significance on another. Additionally, the author of a transaction that specifies the Genesis block hash for `To` may want the transaction available for any future forks of the blockchain.
+
+Specifying the hash of the most recent fork block as the value for `To` provides the highest security against transaction replays. If a transaction originates with a `To` value set to the block hash of the block that designates a fork, then that transaction is guaranteed to be valid on the forked blockchain, but not on the pristine blockchain. Conversely, if a client chooses not to adopt the fork of a blockchain, then it can be assured that transactions originating on the forked blockchain will have an invalid block hash specified in the `To` field.
+
+### History
+The idea for this ECIP is based on the [discussion][eip-discussion] of a potential EIP for Ethereum 'Metropolis'.
+
+[eip-discussion]: https://github.com/ethereum/EIPs/issues/134#issuecomment-237266879