Discussion for EIP-3607: Reject transactions from senders with deployed code

[dankrad]

Discussions for https://eips.ethereum.org/EIPS/eip-3607

[github-actions]

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

[jochem-brouwer]

To be clear here: these kind of transactions are invalid and can thus not be included in the block?

[MicahZoltu]

It would be good to get this clarified in the specification.

[tjayrush]

Wildly minor typo:

// Make sure the sender is an EOA
Set ch to the CodeHash of the sender account
if cs is not equal to EmptyCodeHash then
	return ErrSenderNoEOA
end if

I think the cs should be ch.

[eulerbeat5]

Is this issue still open?

[jochem-brouwer]

To be clear here: these kind of transactions are invalid and can thus not be included in the block?

I have no answer to this question yet

[CodeMustRule]

What happens in the reverse case, if a contract address collisions with a EOA that has been used and may have no balance but such user has locked value in DeFi or other contracts as tokens, ownership, administration or any form of contract rights?

[dankrad]

To be clear here: these kind of transactions are invalid and can thus not be included in the block?

Yes, I think the EIP makes this clear: A block containing such a transaction MUST be considered invalid. What's unclear about this?

[dankrad]

What happens in the reverse case, if a contract address collisions with a EOA that has been used and may have no balance but such user has locked value in DeFi or other contracts as tokens, ownership, administration or any form of contract rights?

How would it happen? There are two different ways:

1. The owner of the EOA created an address collision to have their EOA collide with the deployment of a contract, and they decided to use it as an EOA first. This is the fault of the owner of this address, and would be stupid, because it being a contract address will (with the implementation of EIP-3607) strictly reduce their capabilities. So there is no attack surface here.
2. Someone else (other than the account owner) brute forced an account to collide with this. 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).

[MicahZoltu]

I don't see an immediately obvious and simple solution, but it would be great if self destructing a contract didn't make that address accessible by an EOA. I believe the specification as currently written would allow someone with an EOA + contract collusion to self destruct the contract and then access all of the assets held by that address via the EOA.

Disallowing this would...

1. Give stronger guarantees that there is no way for any human to access the assets held by a colliding contract.
2. Allow us to implement a one way "convert to contract" feature where users can submit a transaction that writes code to their EOA address and that functionally turns it into a contract (permanently).
3. Gives one less sharp edge with self destruct (which causes no end of problems).

[dankrad]

@MicahZoltu This EIP was never intended to fix all possible problems with EOA/contract collisions, only by a lucky accident we could fix the most exploitable case through a soft fork.

I think what you mention will basically be addressed by #4758 ot #4760 which deactivate SELFDESTRUCT. After one of these EIPs has been fully implemented, there is no way for a contract account to ever become an EOA again.

[MicahZoltu]

Closing this for housekeeping purposes since this EIP is final, but feel free to continue discussing here as needed.