Bitcoin Forum
December 14, 2017, 03:42:26 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Why are DER-encoded signatures for p2pkh differing in size?  (Read 1180 times)
inf
Newbie
*
Offline Offline

Activity: 26


View Profile
October 04, 2014, 03:51:08 PM
 #1

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
1513266146
Hero Member
*
Offline Offline

Posts: 1513266146

View Profile Personal Message (Offline)

Ignore
1513266146
Reply with quote  #2

1513266146
Report to moderator
1513266146
Hero Member
*
Offline Offline

Posts: 1513266146

View Profile Personal Message (Offline)

Ignore
1513266146
Reply with quote  #2

1513266146
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513266146
Hero Member
*
Offline Offline

Posts: 1513266146

View Profile Personal Message (Offline)

Ignore
1513266146
Reply with quote  #2

1513266146
Report to moderator
1513266146
Hero Member
*
Offline Offline

Posts: 1513266146

View Profile Personal Message (Offline)

Ignore
1513266146
Reply with quote  #2

1513266146
Report to moderator
inf
Newbie
*
Offline Offline

Activity: 26


View Profile
October 04, 2014, 04:14:09 PM
 #2

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...)
hhanh00
Sr. Member
****
Offline Offline

Activity: 464


View Profile
October 04, 2014, 04:42:10 PM
 #3

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.

inf
Newbie
*
Offline Offline

Activity: 26


View Profile
October 04, 2014, 04:52:24 PM
 #4

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?
hhanh00
Sr. Member
****
Offline Offline

Activity: 464


View Profile
October 04, 2014, 05:10:25 PM
 #5

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.

inf
Newbie
*
Offline Offline

Activity: 26


View Profile
October 04, 2014, 09:29:53 PM
 #6

okay i see, thanks again, much appreciated Smiley
piotr_n
Legendary
*
Offline Offline

Activity: 1778


aka tonikt


View Profile WWW
October 05, 2014, 09:33:53 AM
 #7

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 Smiley

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
hhanh00
Sr. Member
****
Offline Offline

Activity: 464


View Profile
October 06, 2014, 08:38:03 AM
 #8

This transaction https://blockchain.info/tx/251d9cc59d1fc23b0ec6e62aff6106f1890bf9ed4eb0b7df70319d3e555f4fd2
has a messed up DER encoding too.

3044022090f7346fa0f6a4dc4b31300bf93be229001a1104532829644e07f45814bb734e0220579da5a14362f 46bfd7c2be0d19c67caedc812147b9b8d574e34a3932cf21f7a01

It's definitively not consistent.

inf
Newbie
*
Offline Offline

Activity: 26


View Profile
October 06, 2014, 11:46:19 AM
 #9

Interesting catch! But good to know it was accepted and could be spent further... But I will feel better doing it the compliant way Smiley
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!