I do realize that in bitcoin when we return the signature result for signing a message the first byte includes information for recovering the public key required for verification using a formula like this:
27 + (4 if comp. 0 if not) + (0<=num<=3)
What I am struggling with is how do we determine that
According to section 4.1.6 of SEC:1 for recovering public keys:
x = r + jn
Rif invalid move to next
Since j (cofactor of secp256k1) is 0 and 1 and there are two values for R. So there should be 4 possible public keys. Is
num the number of public keys that we rejected before reaching the correct one? Because that is the only explanation that I can come up with based on comparisons I have made between signatures generated using Electrum and public key recovery I have done myself using SEC1.
Bonus question: Why was 27 chosen?
nummeans there either, but I wrote this a while ago which might interest you. It explains exactly how to encode and decode the recid byte : github.com/fivepiece/sign-verify-message/blob/master/…
numafter signing and finding
r,s. But it seems like you must find it during using the y coordinate of
rwhich is discarded and doesn't come out of sign function. Now I am trying to figure out the details...