ecdsa – Effect of byte length of r and s on DER encoded signatures
As described in this answer to What is the maximum size of a DER-encoded ECDSA signature? The DER encoded signature for a specific ECDSA signature (r, s) has the following format:
0x30 = 1 byte constructed sequence type
L = 1 byte length of the following bytes (excluding SIGHASH byte)
0x02 = 1 byte primitive integer type
LR = 1 byte length of integer r
R = integer r in big endian
0x02 = 1 byte primitive integer type
LS = 1 byte length of integer s
S = integer s in big endian
SIGHASH = 1 byte
Here, if the most significant bit of r is 1, byte 0x00 is added before r, and the same goes for s.
But what if the byte length of r is less than 32?
For example, let’s say you have the following case:
r = 0x83e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
It is 30 bytes.
we are
(1) Since the highest bit (i.e. bit 239) is 1, add 0x00 to it as follows:
0x0083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
In the R field above, or:
(2) Write in full 32-byte format.
0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
Therefore, do not prepend 0x00 because the highest bit (i.e. bit 255) is 0. So, type:
0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
In the R field above?
Can anyone point to an example of a blockchain transaction that shows how these short r, s values are handled?
Is there any possibility of malleability here? Assuming (r, s) is a valid signature, are both options (1) and (2) allowed in Bitcoin Core?
Or do I always remove leading zero bytes from r and s before considering whether the highest bit is 1 (0 is not an acceptable value for r or s)?