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.

1 Answer 1


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).

  • 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, 2017 at 13:55
  • 1
    T is a transaction, S(T) is a function that returns the sender of the transaction T.
    – Ismael
    Dec 16, 2017 at 14:00
  • 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, 2017 at 14:05
  • 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, 2017 at 14:12
  • 1
    See here 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^(32*8) different outputs, but if you input data is 64 bytes then you have 2^(64*8) 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, 2017 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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