EIP-689: Address Collision of Contract Address Causes Exceptional Halt

Discussion topic for:

This was also proposed as EIP-684 and EIP-83.

(Some comments were left on the PR: https://github.com/ethereum/EIPs/pull/689)

This has been discussed started ACD#60. On ACD#61

Martin : No. Long time ago we decide on 684 and 689 are roughly the same thing.

On ACD#62

Status : Completed. Exists in Clients and is in tests as it has already been accepted but is not in the yellow paper. No one available to write it into the Yellow Paper.

@holiman I think you also mentioned this was done because of EIP-86, but EIP-86 is not part of any hard fork.

Can you clarify what version of this EIP is implemented and can we mark the EIP final once everything is clarified?

Started to add some clarifications in this PR: https://github.com/ethereum/EIPs/pull/2238

See https://eips.ethereum.org/EIPS/eip-1014 , under “Clarifications”:

The init_code is the code that, when executed, produces the runtime bytecode that will be placed into the state, and which typically is used by high level languages to implement a ‘constructor’.

This EIP makes collisions possible. The behaviour at collisions is specified by EIP 684:

If a contract creation is attempted, due to either a creation transaction or the CREATE (or future CREATE2) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. This applies retroactively starting from genesis.

So, we decided on a call to consider #684 retroactively adopted, and code was added to clients and tests. What prompted this (EIP-684) was that we were contempling EIp-86, and needed to define how to handle collisions.

However, #86 was never actually implemented, for various reasons. So #684 was not really needed (but still accepted), until eventually the next version of EIP-86, the EIP-1014 was implemented.

Therefore, to make things clearer, I made sure to include the “Clarificatios” into 1014, so that the behaviour would be well defined, even if people had forgotten about EIP-684.

I’m not sure where all the confusion comes from, or how we could/should improve it.

This clarifies it a lot. I think where confusion stems from is that a lot of these “EIPs” are not actual EIPs, just issues on the repo.

Seemingly 689 and 684 are identical. I think the best solution going forward would be either:

  1. Creating a “real EIP” out of 684 and marking it final and marking 689 as “abandoned”.
  2. Updating 689 to match reality completely (e.g. removing references to 86) and marking it final.

In that case, I’d go with option 1, since that’s the one we did agree on at a call long ago.
Also, back in those times the format of EIPs weren’t well-defined, and a lot of old EIPs are issues rather than md-files. So lifting it into proper form seems the right approach.