Leading zeros are stripped from signature values

[alcuadrado]

I'm opening this issue mainly to document some unexpected behavior in this library: When signing a transaction, the r and s values get their leading zeros removed.

This behavior doesn't invalidate the signatures, but can make comparing them non-obvious, as using Buffer.prototype.equals can give false negatives. As a workaround, ethereumjs-util's stripZeros can be used before comparing the r and s buffers:

function areSignatureBuffersEqual(buffer1, buffer2) {
  return stripZeros(buffer1).equals(stripZeros(buffer2))
}

The root of this behavior is that this library's internal representation mimics the protocol-level rlp-encoded transaction representation. This is being reevaluated and may change in a future major version.

[SurfingNerd]

web3.eth.accounts.recoverTransaction(serializedTx) is also one of the methods that is unable to deal with the shorter zero-prunned RLP Encoded strings.
Example: https://gist.github.com/SurfingNerd/2be70efd789912b5a9a51d662c38ed40

[alcuadrado]

Hi @SurfingNerd, thanks for investigating this issue, and the reproduction script.

I suspect that this is a bug in web3, as it's probably treating r and s as bytearrays, while the yellow paper says that they are numeric values. In RLP numeric values must have their left-side zeros removed.

How did you create/obtain that transaction? it would be really helpful to know this.

@nivida, have you encountered something similar?

[d10r]

@alcuadrado I came to the same conclusion, thus reported it at web3.js: web3/web3.js#2902

[alcuadrado]

Thanks @d10r! This is being tracked in web3/web3.js#2777

[SurfingNerd]

@alcuadrado i obtained this signature by an Infineon security2go smart card. (therefore i can't provide the Private Key, since it is secure stored in the hardware)

[ryanio]

This should now be resolved in #812 by storing R & S as BN.