2

I have been studing ECDSA signature/verify for a while. By my understanding: the standard ECDSA signature/verify process are like something as below: enter image description here

  1. A sender combines message and its ECC public key (pk), do hash, then using ECC sk (private key) to generate signature; it then append the signature with the message (ECC pk include), send all these to receiver;

  2. The receiver do ECDSA verify by using the ECC pk, the message and the signature output true or false;

My 1st question is, for EOS a signature verify looks not likely align to a standard ECDSA signature verify--does EOS adopt some simplified signature verification algorithm (due to 0.5s Block producing timing, this have to be done as quick as possible)? if it does, what kind modification was put?

In a EOS node, it need to do several ECDSA signature verify: 1). Check each Tx signature--from code it call lib called get_signature_keys, which from name like simply recover the pk? and follow up by a routine naming as check_authorization (this does not like a real signature verification); 2). Check a Block's signature, this routine however, looks likely a real ECDSA signature verify (verify_signee);

My 2nd question: I know BTC/ETH may adopt quite different method as they are PoW so each miner must do signature verification for each Tx inside a block, but as they have much more time (several minutes) than in EOS, they would be using the standard ECDSA verification?

2

There are several ECDSA according to what elliptic curve algorithm uses. Bitcoin, Ethereum and EOSIO support secp256k1 using Koblitz curve, and their ways to sign a transaction or recover public key from signature are fundamentally same.

When a transaction is pushed to node, node tries recovering public keys from signatures (multi-sig is supported in EOSIO by nature) and checking whether authorization specified in transaction is satisfied. Unlike Bitcoin or Ethereum, EOSIO public key doesn't mean address or wallet itself. Public key is registered to account.

The block time (interval) is determined by not only signature recovery, but various concerns. A short interval can increase the possibility of chain fork especially in PoW, but EOSIO adopts DPoS, so it can mitigates this side effect by predetermined schedule of producing blocks.

Update:

In Ethereum, address (account) is one-to-one match to public key. When public key is recovered from signature, the address derived from recovered key will be compared with from element in transaction. If they are equal, we can say that transaction is correctly signed by from.

However, EOS account is human-readable string (has no cryptographic relationship with public key), but its permission like owner or active has registered public key. EOS transaction contains authorization field like eosio@active, and when public key is recovered from signature, node will check whether recovered key is registered to given permission. (eg. eosio@active)

  • Thanks. regarding your comments " node tries recovering public keys from signatures (multi-sig is supported in EOSIO by nature) and checking whether authorization specified in transaction is satisfied." Can you please give some further explain, or recommend some further reading? From my understanding: 1) from a standard ECDSA signature one can not recover pub key? 2). even obtaining the pub key, then what does "authorization" exact mean -- if node does not run a standard ECDSA signature verify algorithm? – LeonMSH Sep 5 at 8:31
  • I can't get exact meaning of your "standard" ECDSA, but there are not so special things in each blockchain. I updated original answer. (it exceeds length limit of comment) – conr2d Sep 5 at 9:56
  • "When public key is recovered from signature, the address derived from recovered key will be compared with from element in transaction. If they are equal, we can say that transaction is correctly signed by from." OK I think here is my confuse come from: I assume annother (Mr.B) can recover the public key of Mr.A, then Mr.B could sign a transaction with himself private key but attached with Mr.A public key's hash. If verifier just verifier the public key but not run a normal signature verify--how can they know this is a "true" trasaction? I am not sure If I miss something here.. – LeonMSH Sep 6 at 2:37
  • the "standard" ECDSA means what I described in the begaining of the question the normal ECDSA--it can be find in any text-book of cryptographic.. I don't understand, without running a signature verification process (which is core part of the Pub-Key Algorithm), how can one completey commit the trust? – LeonMSH Sep 6 at 2:41
  • All blockchain recover public key from signature when they accept any transaction. If Mr.B signs Mr.A's transaction and its signature is generated by Mr.B's private key, recovered public key is Mr.B's one, but transaction from field indicates Mr.A's public key (or address), so verification will fail. – conr2d Sep 6 at 14:52

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.