Clarification on EIP-3607

Question

Are these scenarios possible in the existing EVM based systems: NOTE: I understand that the probability of this happening is very small, but EIP-3607 assumes this probability and tries to reduce the attack surface.

case 1: EOA created at an address where a contract already exists. I believe a typical user may not have complete control on what address get assigned. From my understanding, EIP-3607 prohibits a contract from misusing the funds of an existing EOA. But, it is possible to have a contract deployed at an existing EOA address and funds could be transferred to the contract by an unsuspecting user. If this is possible, how can this be avoided?

case 2: contract deployed at an existing EOA address. Does the EVM verify if the address is unassigned (i.e., codehash(address) == 0, balance=0, nonce=0) before deploying a contract?

[11 Dec 2022: Updated after reply from 'eth'] Let me clarify: For case 1: "An EOA/private key for an existing contract is discovered" and For case 2: "A hacker deploys a contract at an EOA to steal the funds of the EOA": I understand that a targeted attack may be tough. However, it is possible by chance that an unsuspecting user gets his account address (or contract address) to match that of an existing contract (or account).
EIP-3607 only seems to prevent the case of an EOA getting created at the same address as an existing contract. But, does the user know that there is a clash when his account is created? What if he asks someone to send funds to this newly created account? Will he loose those to the contract?

In summary: It is possible to distinguish if an account is an existing EOA or contract by using the codeHash(account). Why can that not be used to disallow transfer to an account (if contract exists) or disallow creation of contract (of an EOA exists)?

Answer 1

An EOA / private key for an existing contract is discovered

This is the scenario that EIP-3607 prohibits. Transactions from the EOA are invalid and cannot be included in a block.

A hacker deploys a contract at an EOA to steal the funds of the EOA

Deploying a contract at an EOA is as hard as finding the private key of the EOA itself. Such a hacker may as well use the private key. EIP-3607 discussion explains:

Note that this requires a preimage attack rather than just finding a collision, which is much harder. In fact it is just as hard as just brute forcing the private key for the address. So this attack should be considered computationally infeasible (complexity 2**160).

A hacker tries to overwrite an existing contract by deploying to it

A contract cannot be created at an address that already has code. EIP-1014 includes:

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.