Hello ligi, I was coming here with a query that might actually answer your question, or help you. Maybe.
I’m learning Ethereum and reading through lots of main EIPs making notes. Some are much higher quality writing than others. I’m at that wondeful stage where I don’t have the Curse of Knowledge, and this EIP is confusing.
The opening sentence gives the impression that the proposal I’m about to read will fix the “current” state of affairs so that contracts will be able to sign messages! But then goes on to say that it is merely proposing a way for any contract to check whether a signature “on behalf of a contract” is valid.
Strictly speaking, neither are true. The EIP is just defining a method which validates arbitrary data.
Because the EIP neglects to formalise or give an example of how the hash and signature are generated, it’s left open to interpretation as to what these values may contain, exactly. Thus the function is really asking, “Do you like this data?”
There are no uses of MUST or SHALL etc. other than a few in the coded spec.
Therefore, the signature bytes could potentially contain a custom layout of data to be decoded and checked, which could be a workaround for ligi.
Again, the EIP does not elaborate on how the method will be used in practice, nor how or what generates the hash and signature, so it is either:
a) left open intentionally
b) left open unintentionally, probably due to tacit (assumed) knowledge within the community of how this would work, or
c) is closed; the constraints are implied in the tacit knowledge that it’s simply not possible for public contract code to securely do anything much with this data other than to recover the signer public key and compare it to some other known address.
So I’m posting here to perhaps show ligi a way out, (or lead poor ligi astray), and to highlight that the EIP is not clear enough.
Thanks all,
Luke