Signature – Why is the ECDSA v Value Often Neither 27 Nor 28?

hashraw-transactionsignature

There are a lot of information out there explaining that in the ECDSA signature the value of v is always either 27 or 28.

However there are many transactions which, when decoded using several decoders, give me a value of v which is neither 27 nor 28. Even for plain old "legacy" ETH to ETH address transfers.

For example this transaction (which just happened as I type this):

0x3e7dcc2968b867d12fa6312fb4ffd529bd9fac38c12ae5e48979cca96c60141f

https://etherscan.io/tx/0x3e7dcc2968b867d12fa6312fb4ffd529bd9fac38c12ae5e48979cca96c60141f

As a "raw transaction" hex of:

0xf86a5f8531f132410082520894eb2c8f9b298a5f20fededc2ed42ee18ced1cd90c86c272bfeadca38025a0c6e2eff27b387b3f85b78c250e13f334941e5a6ef0edc40a86e9bfd48993cdb9a05610ff618aae0e7a95ec09fadef31a4c0762af2252b024aad16eb665bbab755d

Which decodes to (I tried using several decoder):

{
  "nonce": 95,
  "gasPrice": 214500000000,
  "gasLimit": 21000,
  "to": "0xeb2c8f9b298a5f20fededc2ed42ee18ced1cd90c",
  "value": 213798101900451,
  "data": "",
  "from": "0x9033c7a300013cbbcef428a6979084245587a8be",
  "r": "c6e2eff27b387b3f85b78c250e13f334941e5a6ef0edc40a86e9bfd48993cdb9",
  "v": "25",
  "s": "5610ff618aae0e7a95ec09fadef31a4c0762af2252b024aad16eb665bbab755d"
}

The v value is 0x25 (that is 37 in decimal). So it's neither 27 nor 28.

What are all these docs / blog post out there talking about when they say v is either 27 or 28? There's also a lot of source code out there with 27 hardcoded in.

There's even a question here asking: Why the value of v is always either 27 (11011) or 28 (11100)?

Yet I don't understand that question, at all. From my tests v is rarely 27 or 28.

If anything, I've got a hard time finding decoded transaction where I see v being either 27 or 28: it seems more often than not to be 0x26 (decimal 38) or 120 or any other value really.

The reason I'm asking is I'm signing ERC-20 USDC transaction offline and I was reviewing them before broadcasting them, checking all the fields. Then I found a v at 26, but I was reading docs saying it should always be 27 or 28. Then I searched some more and, if anything, I found more and more documentation saying it's always 27 or 28.

Yet when I decode transactions, it's nearly never 27 or 28.

So my question is very simple: why is the value of v nearly never neither 27 nor 28 although all the documentation out there says it's always either 27 or 28?

Best Answer

The recid value (v) is only a way to speed up verification and address recovery, as explained here.

So your actual v value is defined in {0, 1, 2, 3}.

In the Ethereum network the recid value (v) is computed that way since EIP-155 which was included in the Spurious Dragon fork from EIP-607 (to protect against tx replay attack with Ethereum classic) :

{0,1} + CHAIN_ID * 2 + 35 Meaning that the possible outcomes for the Ethereum mainnet with CHAIN_ID 1 are : 37 and 38 (while 39 and 40 are still possible as per my understanding but extremely unlikely, don't take my word for it though).

The previous computation scheme (not encoding chain_id, r=0, s=0) was defined as : {0,1} + 27 giving the most probable outcomes 27 and 28. (Again, I think that 29 and 30 are possible but highly unlikely)

So my question is very simple: why is the value of v nearly never neither 27 nor 28 although all the documentation out there says it's always either 27 or 28?

Because your documentation is outdated, and doesn't take EIP-155 into consideration.

Additionally, EIP-155 states that :

The currently existing signature scheme using v = 27 and v = 28 remains valid and continues to operate under the same rules as it did previously.

I haven't found anything invalidating that previous signature scheme (certainly kept for backward compatibility) so it might very well still be valid, but its usage is discouraged. This is why you mostly see 37 and 38 on mainnet as people switched to the new computation scheme.

Related Topic