Provide function(s) that verify an address is an EOA

🧐 Motivation It can be useful to verify that a given address is:

1. For-sure an EOA
2. For-sure an EOA that is not a one-time-use EOA

We could provide this functionality in the Address library.

📝 Details I suggest adding two functions to the Address library.

The first would be: isEOA(address account, bytes32 hash, bytes memory signature). This would accept an arbitrary hash, verify the signature, use recover (from the ECDSA library) to recover the account of the signer, and return true only if the recovered address matched the account parameter. Thus, if isEOA returns true then we know for-sure that account is an EOA because it was able to sign a message. (Though if it returns false we get no information at all).

However, there are also important cases where being an EOA is not enough – and we also want to verify that a given address is not a one-time-use EOA (such as those created using Nick Johnson’s method). So for that I suggest the following general function:

isNonOneTimeUseEOA(address account, bytes32 hash1, bytes memory signature1, bytes32 hash2, bytes memory signature2). This would verify both signatures, verify that hash1 != hash2, use recover on both signatures, then return true only if the recovered addresses and the account parameter were all equal to each other. What this is doing is verifying that the account is able to sign two distinct messages – ensuring that it cannot be a one-time-use EOA (since one-time-use EOAs can only ever create a single signature). Thus, if isNonOneTimeUseEOA returns true then we know for-sure that account is an EOA but not a one-time-use EOA. (Though if it returns false we get no information at all).

[nventuro]

Note that, if EIP 3074 were to come out (and it seems extremely likely that it will), this sort of check would be irrelevant (except to e.g. validate user input by checking addresses expected to be contracts indeed hold code).

[Austin-Williams]

@crazyrabbitLTC I generally agree that sending ETH from to/from contracts is a great thing.

There are very special cases when we’d want to prevent it. These are mostly cases where we are designing a mechanism in which we don’t want the users to be able to make strategic commitments (aka strategic moves) that might undermine the mechanism.

A specific example is when creating token timelocks for incentive-alignment. If the beneficiary of the token timelock is able to make strategic commitments, then they are able to bypass the token timelock.

In practice, strategic commitments are often very difficult to achieve (in the blockchain setting) without the use of a contract to enforce the commitment. So if, as a mechanism designer, you can prevent the use of contracts (in very particular settings) you can sometimes effectively eliminate large classes of potentially malicious behavior.