1

On Ethereum and ʙꜱᴄ an invalid signature (for exampler s v==0) has a 0x0 address. It’s only the signature that determine who is the ᴇᴏᴀ being used.

  • Now, the yellow paper tell in which case a signature is invalid compared to when ecrecover is used in contracts, but not what to do with such signatures in the case of a regular transaction.
  • The official Geth implementations prevents transactions using invalid signatures to reach the mempool but don’t seems to prevent to reject a block or a slot containing such transactions.
  • There’s also the eip‒4337 that propose to have account abstraction without a hard fork

Given all of this, am I right to think msg.sender can be null on Ethereum and bsc ? If not please point where I’m wrong including with the source code.

1 Answer 1

0

It depends on what you mean by an invalid signature:

  • If you mean malformed, no. If such a tx is present, the block will be discarded by other validators, so it is not included in the ledger.
  • Yes, if you mean a signature that resolves to a 0x0 address. And anyone that finds the private key will have a lot of ethers to play with ;)

msg.sender cannot be null, because if so it means the signature is invalid, and the tx is not accepted. 0x0000000000000000000000000000000000000000, on the contrary, is a perfectly valid address.

Any signatures (V, R, S) must still generate a valid corresponding address (recover the pub key, hash it, and take the first 20 bytes), and that address must have enough ethers to pay for the fees, or, again, the TX will not pass.

There are multiple points in the code where you need to check for the validity of the transaction's signature.

To have a msg.sender = null you must have an invalid signature, and if you have an invalid signature, geth discards the tx.

As a reference, here is an example with the ValidateSignatureValues function that verifies signatures; that function is used among others by recoverPlain, that is used among others by Sender to recover the sender.

Something funny you can do is set the gas price to 0 and hijack the signature, i.e., changing the v parameter and ending up with a different public key, hence a different address. Here is an interesting article about The Magic of Digital Signatures on Ethereum.

That transaction will pass if you convince a validator or block producer to include that TX (i.e., because you are a block producer/validator or pay the validator OTC).

6
  • Blocks contains rlp encoded transactions qnd transactions includes signatures. What do you mean by hijack the signature? Also I would need the source code validating your assertions as nor the consensus layer nor the Geth layer seems to have code invalidating such blocks (only for the mempool on an individual transaction basis). Commented Feb 10 at 10:06
  • I added reference to the code in the answer. Same for info about playing with the v parameter. Commented Feb 10 at 21:32
  • About your code references, I see it returns Common.address in case of failure and that it’s used unmodified for ecrecover in Soldity code : a situation where the sender is the null address. Commented Feb 13 at 17:09
  • All those functions returns Common.address{} only in conjunction with the corresponding errors (usually invalid public key, ErrInvalidSig, etc.). There's no good path with Common.address null. Commented Feb 15 at 8:56
  • also, when ecrecover returns null it means the signature is invalid, and no transaction containing invalid signature can be included in the ledger. From the yellowpaper "We define ΞECREC as a precompiled contract for the elliptic curve digital signature algorithm (ECDSA) public key recovery function (ecrecover). See Appendix F for the definition of the function ECDSARECOVER and the constant secp256k1n. We also define d to be the input data, well defined for an infinite length by appending zeroes as required. In the case of an invalid signature, we return no output". Commented Feb 15 at 9:04

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.