Simple replay attack protection

[vbuterin]

EDITOR UPDATE (2017-08-15): This EIP is now located at https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md. Please go there for the correct specification. The text below may be incorrect or outdated, and is not maintained.

Parameters

• FORK_BLKNUM: TBA
• CHAIN_ID: 1

Specification

If block.number >= FORK_BLKNUM and v = CHAIN_ID * 2 + 35 or v = CHAIN_ID * 2 + 36, then when computing the hash of a transaction for purposes of signing or recovering, instead of hashing only the first six elements (ie. nonce, gasprice, startgas, to, value, data), hash nine elements, with v replaced by CHAIN_ID, r = 0 and s = 0. The currently existing signature scheme using v = 27 and v = 28 remains valid and continues to operate under the same rules as it does now.

Example

Consider a transaction with nonce = 9, gasprice = 20 * 10**9, startgas = 21000, to = 0x3535353535353535353535353535353535353535, value = 10**18, data='' (empty).

The "signing data" becomes:

0xec098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a764000080018080

The "signing hash" becomes:

0x2691916f9e6e5b304f135496c08f632040f02d78e36ae5bbbb38f919730c8fa0

If the transaction is signed with the private key 0x4646464646464646464646464646464646464646464646464646464646464646, then the v,r,s values become:

(37, 11298168949998536842419725113857172427648002808790045841403298480749678639159, 26113561835810707062310182368620287328545641189938585203131842552044123671646)

Notice the use of 37 instead of 27. The signed tx would become:

0xf86c098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a76400008025a028ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276a067cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83

Rationale

This would provide a way to send transactions that work on ethereum without working on ETC or the Morden testnet. ETC is encouraged to adopt this EIP but replacing CHAIN_ID with a different value, and all future testnets, consortium chains and alt-etherea are encouraged to adopt this EIP replacing CHAIN_ID with a unique value.

[janx]

Out of curious: why make v=27|28 instead of v=0|1 at first place?

[vbuterin]

It was a carry-over from Bitcoin's Electrum wallet.

[Smithgift]

Relevant Classic ECIP discussion on this subject. Even more here. As far as I understand it, they're considering adding the blockhash of the nearest fork to the signing process.

I'm not competent to speak on the cryptographic parts of this idea, but I'll note a philosophical difference between this and ECIP-1011. Here, picking CHAIN_ID requires human intervention to choose which community it belongs in, whereas a machine can compute the right blockhash to stick in if it detects even a minor fork.

In any case, the existence of two incompatible replay protection systems will hardly cause them to fail in their intended function. It's just a kind of balkanization of code that, IMHO, would be harmful for a future cross-chain metaetheral world. I'm not saying that doing our own system would be wrong, but that there's a non-zero cost to having different systems.

[holiman]

because v = 27 and v = 28 will continue to be usable to send transactions on all chains and so that would create a protocol ambiguity as there would be two different valid ways to calculate the sender of a transaction

To clarify, does "continue to be usable to send transactions on all chains" mean that we would retain the old transaction signing scheme as valid, in addition to the new signing scheme? If so, the specification-paragraph should be updated to reflect that.

[vbuterin]

Yes, the old scheme is still valid in addition to the new one.

[rebroad]

@vbuterin The mention of ETC confuses me as I thought this issue was being raised to address up-coming forks to ensure replay attacks cannot happen again should the current chain survive in some form. Is that what this issue is created to address?

[Smithgift]

@rebroad: This will work just as well for ETH/ETC replay attack prevention. As it is, that's the bigger need.

[Arachnid]

Instead of using a 'chain ID' that has a limited namespace of 8 bits, and has to be changed on each fork, I'd like to propose two alternatives:

1. Before hashing, replace one of V, R, or S with a 'fork ID'. A fork ID is 0 for the initial Ethereum chain. Each time there is a hard fork, the forked side sets a 1 bit in the next available slot, starting with the least significant bit. So, Ethereum post frontier has fork id 1, as does Ethereum Classic. Ethereum after the DAO fork had fork ID 11b = 3, and after the recent gas reprice fork had fork ID 111b = 7. After this fork, Ethereum will have fork ID 1111b = 15. After the forthcoming ETC fork it will have fork ID 101b = 5.
2. Before hashing, replace one of V, R, or S with the block hash of the block at which the most recent fork occurred.

[sebs]

Is this only a protection against simple replay attacks or all attacks in a simple way? Please clarify for the non whitepaper safe fellows.

[holiman]

The latter; "all attacks in a simple way".