As described in this answer to What is the maximum size of a DER encoded ECDSA signature? the DER encoded signature for a given ECDSA signature (r, s) has 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
where r is prepended with a byte 0x00 in the case where it has a highest bit of 1, and likewise with s.
However how is the case where r has a byte length less than 32 handled?
Suppose for example we had :
r = 0x83e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
which is 30 bytes.
Do we
(1) prepend this with 0x00 because of the highest bit (ie. bit 239) being 1, so we put :
0x0083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
in the R field above, or :
(2) write it in full 32 byte format :
0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
and therefore do not prepend it with 0x00 because the highest bit (ie. bit 255) is zero, so we put :
0x000083e1ed5c6298a2dfb3e98f2d8963575487c888ac02483045022100ec6ab2
in the R field above?
Can anyone point to any example blockchain transactions illustrating how these shorter r, s values are handled?
Is there any possibility of malleability here, ie. both options (1) and (2) are accepted by Bitcoin Core, assuming (r, s) is a valid signature?
Or are leading zero bytes always stripped away from r and s before considering whether their highest bit is 1 (noting zero is not a permissible value for r or s)?
