1

Ethereum Yellow Paper: Please see equation 220 and 221.

enter image description here

On equation 220, we obtain the transaction that can be sent to the network and will be tracked by a 256 bit transaction-id. Its right most 160-bits is equalled to S(T) which is the defined as the sender function S of the transaction.

My question is related to Equation 221 which is an assertion about: :

The assertion that the sender of a signed transaction equals the address of the signer should be self-evident

[Q] Why and how the sender of a signed transaction(S(T) on the eq. 220) equals the address of the signer (A(pr)) ? Is there any well explained documentation related to this.

Could we conclude the following statement:

B96...255(KEC(ECDSARECOVER(h(T),Tw,Tr,Ts))) == B96...255((KEC(ECDSAPUBKEY(pr)))

Thank you for your valuable time and help.

alper
  • 8,395
  • 11
  • 63
  • 152

1 Answers1

2

This is know as the ECDSA public key recover trick, see https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work how elliptic curve math works.

An ethereum signature has three parameters r, s and v. Using r, s and the ECDSA equation you have two candidates for the public key, then using v you can disambiguate and know exactly which one is the public key of the signer.

Once you have the public key, you use can calculate the address with the last 20 bytes of keccak256(publicKey).

rustyx
  • 910
  • 7
  • 15
Ismael
  • 30,570
  • 21
  • 53
  • 96
  • I get really confused :( what does S(T) stands for, is it Ethereum address of the sender, which is actually the 160-bit we obtain on eq. 215? So KEC( ECDSARECOVER(h(T),Tw,Tr,Ts)) == KEC(ECDSAPUBKEY(pr)) you could see on my updated Q?@Ismael – alper Dec 16 '17 at 13:55
  • 1
    T is a transaction, S(T) is a function that returns the sender of the transaction T. – Ismael Dec 16 '17 at 14:00
  • Much clear, So ECDSARECOVER(h(T),Tw,Tr,Ts)) is the publicKey of the signer and from that we can obtain signer's 160-bit Ethereum-Address, right? @Ismael. – alper Dec 16 '17 at 14:03
  • 1
    The equation without KEC is not always true, we have addresses are 20 bytes and public keys are 64 bytes, so there exists multiple public keys that maps to the same address. – Ismael Dec 16 '17 at 14:05
  • How can multiple public keys can map to the same address? Shouldn't KEC(somePublicKey) should generate a unique value for each give public key? @Ismael – alper Dec 16 '17 at 14:07
  • Aa I get it, KEC(somePublicKey can generate a unique value but that right-most 160 bit could be same which leads to the same address. Overall this is should be correct B96...255(KEC(ECDSARECOVER(h(T),Tw,Tr,Ts))) == B96...255((KEC(ECDSAPUBKEY(pr))), right? @Ismael – alper Dec 16 '17 at 14:10
  • 1
    Yes, that is correct, KEC=KECCAK256 is a hash function it only scramble bits of the input and always returns 256 bits, but it cannot guarantee uniqueness. – Ismael Dec 16 '17 at 14:12
  • What do you mean by " it cannot guarantee uniqueness", based on the most-right 160 bits of its output? @Ismael – alper Dec 16 '17 at 14:18
  • 1
    See here https://en.wikipedia.org/wiki/Hash_function. A hash function is like a fingerprint of the input data, it cannot guarantee that for every input data it will generate a different output. For example if the output is 32 bytes you have 2^(328) different outputs, but if you input data is 64 bytes then you have 2^(648) different inputs. Because of the Dirichlet principle at least two input will have the same output (this is called a collision of the hash). – Ismael Dec 16 '17 at 14:40
  • So this collusion may occur on ethereumt as well, right? where multiple public key may link to the same Ethereum address @Ismael – alper Dec 16 '17 at 14:51