Hi recently when I use the secp256k1 library to generate the test vector, I find that EOS add some more API into the "official secp256k1" lib of bitcoin. For Exp, for signature generating, EOS lib API provides one more function "secp256k1_ecdsa_sign_compact"--there is one similar API is ""secp256k1_ecdsa_sign". They both produce the 64byte signature. Initially, I thought this would be a similar tricky like a "compact" signature that ETH to compress recid--which only impact the 1st byte of the key.

But later found, if using the same private key and digest, "secp256k1_ecdsa_sign_compact" and "secp256k1_ecdsa_sign" will produce the completely different signature, not only 1 byte different. Can any one help to explain why was that?


ECDSA signature consists of two values, r and s. Recovery ID (v in Ethereum) is not mandatory, but due to characteristics of elliptic curve, multiple public keys are recovered from signature and verifier can determine what he should choose among them by recovery ID v. Or, verifier can check whether one of recovered key is same to known signer's public key.

EOSIO signature has 65-byte length, v(1) + r(32) + s(32), so you can say that EOSIO signature has exactly same meaning with that of Ethereum.

secp256k1_ecdsa_sign() creates ECDSA signature in DER encoded format (it contains type and length information as well as signature binaries), but secp256k1_ecdsa_sign_compact() creates exact 64 byte-length binaries by serializing r(32) and s(32).

| improve this answer | |
  • Thanks. do you mean secp256k1_ecdsa_sign() and secp256k1_ecdsa_sign_compact() did the same thing but only format different? actually I find EOS remove secp256k1_ecdsa_sign() but add secp256k1_ecdsa_sign_compact() into secp256k1-zkp lib. My problem is the r/s I generated by using secp256k1_ecdsa_sign() ( using secp256k1_ecdsa_signature_serialize_compact to serialze to get r(32) and s(32) ), are somewhat completely different from what generated by secp256k1_ecdsa_sign_compact(). – LeonMSH May 25 at 2:49
  • Yes, they do the same thing. Do you use original secp256k1? secp256k1-zkp doesn't have secp256k1_ecdsa_signature_serialize_compact(). I have to look into code further, but simply saying, signature that can be generated is not the only one. Internally, sign() repeats generating signature until signature is valid. If validation criteria are different among libraries (secp256k1 and secp256k1-zkp here), they can generate valid, but different signatures. – conr2d May 25 at 7:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.