Test demonstrating ECRECOVER opcode

[codingupastorm]

Need to test that it is seamless to enable this in contracts

[zeptin]

Hmm, so my understanding is, normally an uncompressed secp256k1 pubkey has a lot of redundant information. For a given x coordinate there are only 2 possible y values. So instead of storing the complete x and y coordinates (64 bytes), you can almost halve the space requirement by only storing x with a single byte (32 + 1 = 33 bytes) to indicate which of the solutions it is. So recId is that indicator in this case.

I would need to look into it a little to see how you are supposed to infer it when recovering from a signature. Dark magic.

[zeptin]

Ah yes, it's coming back to me a little. There was a softfork mandating that all signature S-values past a certain block height be the 'low' value (at most N/2, where N is the curve order). So I think you'd have to try both the potential pubkeys and see which one gives that outcome.

May be mistaken, still researching.

[zeptin]

Ok, so after looking at the NBitcoin implementation in more detail:

1. I don't think recId should be hardcoded like this, as it can have several different values depending on whether the pubkey is compressed, and other characteristics of the curve point that comprises the pubkey. 1 may be working in your test by coincidence more than anything else.
2. recId gets stored in the first byte of an encoded signature if you are using NBitcoin's message signing functionality anyway. An ECDSASignature instance does not have this data as it is only the raw R & S values.
3. I would therefore suggest using PubKey.RecoverCompact() instead. See Key.SignCompact() for the operation that will return the signature in the encoded form with recId prepended. For RecoverCompact we do obviously need the hash of the message available, but that is a minor tweak of the methods you've already implemented.

[rowandh]

Structurally LGTM. No comment on the RecId/crypto side, will await @zeptin's continued feedback