Topic: Why are DER-encoded signatures for p2pkh differing in size? (Read 1282 times)
Interesting catch! But good to know it was accepted and could be spent further... But I will feel better doing it the compliant way
This transaction https://blockchain.info/tx/251d9cc59d1fc23b0ec6e62aff6106f1890bf9ed4eb0b7df70319d3e555f4fd2
has a messed up DER encoding too.
3044022090f7346fa0f6a4dc4b31300bf93be229001a1104532829644e07f45814bb734e0220579da5a14362f 46bfd7c2be0d19c67caedc812147b9b8d574e34a3932cf21f7a01
It's definitively not consistent.
has a messed up DER encoding too.
3044022090f7346fa0f6a4dc4b31300bf93be229001a1104532829644e07f45814bb734e0220579da5a14362f 46bfd7c2be0d19c67caedc812147b9b8d574e34a3932cf21f7a01
It's definitively not consistent.
It is some sort of a mess that was created as the protocol was being developed. Now it has became a legacy...
In general the bitcoin protocol uses most significant bit of an encoded integer value as the sign.
I think the initial idea was that R and S values inside a signatures shall follow that rule - so if the highest bit happens to be one, it gets padded with a zero byte in front.
Which obviously doesn't make any sense as these values are always positive and whoever was designing it had to know that.
What's even weirder in here, the protocol doesn't follow the sign-bit-rule for the EC keys - these are also 256-bit numbers, but always assumed unsigned, despite of their MSB.
And if that wasn't messy enough, the bitcoin protocol in general uses little-endian to encode integers - that includes 160 and 256 bit hashes wherever they are treated as big ints.
It uses little endians everywhere, except for the values of EC signtures and EC keys.
So the protocol is pretty much inconsistent, but you get to learn it after all
In general the bitcoin protocol uses most significant bit of an encoded integer value as the sign.
I think the initial idea was that R and S values inside a signatures shall follow that rule - so if the highest bit happens to be one, it gets padded with a zero byte in front.
Which obviously doesn't make any sense as these values are always positive and whoever was designing it had to know that.
What's even weirder in here, the protocol doesn't follow the sign-bit-rule for the EC keys - these are also 256-bit numbers, but always assumed unsigned, despite of their MSB.
And if that wasn't messy enough, the bitcoin protocol in general uses little-endian to encode integers - that includes 160 and 256 bit hashes wherever they are treated as big ints.
It uses little endians everywhere, except for the values of EC signtures and EC keys.
So the protocol is pretty much inconsistent, but you get to learn it after all
okay i see, thanks again, much appreciated
It wouldn't but it would break using standard crypto libraries. Bitcoin isn't consistent in this area though. Most likely the result of legacy.
Ah, thank you for the quick answer!
Is this because the BER-class is 0x02 = (not unsigned) INTEGER?
Anyway, still strange for my understanding, because r and s are by definition >=1, so where could this be misinterpreted in the Bitcoin context?
Is this because the BER-class is 0x02 = (not unsigned) INTEGER?
Anyway, still strange for my understanding, because r and s are by definition >=1, so where could this be misinterpreted in the Bitcoin context?
There is an extra leading byte of 00 to indicate the sign. Without it, the number r or s would be treated as negative because its most significant bit is 1.
as an example, grabbed just from the blockchain.info front page:
https://blockchain.info/tx/abb26283b080296ff969dd772b5a1d0ab91e44e19d14dd4420727c1a038286c0
sig starts with hex 30 44 02 20 63 c4 ...
full sig sequence is 0x44 bytes long, r is 0x20 bytes long and starts with 63 c4 ...
https://blockchain.info/tx/fcef2501bed87d99a2ed36fba82c249a0394b511ade129c6a7cbef8286b43d95
here, sig starts with hex 30 45 02 21 00 cb ...
the sig sequence is 0x45 bytes long, r is 0x21 bytes long and starts with 00 cb ...
there is no technical need for the 0x00 byte?!
(unfortunately i cannot find a tx with 0x46 bytes sig length, but i am sure i already saw them...)
https://blockchain.info/tx/abb26283b080296ff969dd772b5a1d0ab91e44e19d14dd4420727c1a038286c0
sig starts with hex 30 44 02 20 63 c4 ...
full sig sequence is 0x44 bytes long, r is 0x20 bytes long and starts with 63 c4 ...
https://blockchain.info/tx/fcef2501bed87d99a2ed36fba82c249a0394b511ade129c6a7cbef8286b43d95
here, sig starts with hex 30 45 02 21 00 cb ...
the sig sequence is 0x45 bytes long, r is 0x21 bytes long and starts with 00 cb ...
there is no technical need for the 0x00 byte?!
(unfortunately i cannot find a tx with 0x46 bytes sig length, but i am sure i already saw them...)
Hello,
browsing the blockchain shows that the DER-part of the sigscript of transactions ranges between 0x44 and 0x46 bytes. this is the result of r and/or s variing in length 0x20 (256 bits) to 0x21.
r and s have to be in range [1, n-1], so they will never exceed 256 bits. transactions with longer r and/or s just have 0x00 stuffed as the first byte.
is there a reasonable explanation for that phenomenon?
thanks,
inf
browsing the blockchain shows that the DER-part of the sigscript of transactions ranges between 0x44 and 0x46 bytes. this is the result of r and/or s variing in length 0x20 (256 bits) to 0x21.
r and s have to be in range [1, n-1], so they will never exceed 256 bits. transactions with longer r and/or s just have 0x00 stuffed as the first byte.
is there a reasonable explanation for that phenomenon?
thanks,
inf
Jump to: