conicalize DER encoded signitures#1
conicalize DER encoded signitures#1scottwalters wants to merge 1 commit intomtve:masterfrom scottwalters:master
Conversation
bitcoind was permissive with how DER encoding was done, which lead to the transaction malliability problem. the exact same transaction could be written multiple ways, signed, and then sent out to confuse people. part of the fix was conicalizing DER encoded signitures. DER encoded numbers now have all leading 0 bytes (0x00 hex) removed from the beginning *except* if the first byte would have its 8th bit, which would indicate that it's negative, which s and r are never in ecdsa signitures, in which case it gets exactly one 0x00 byte stuck on to the front.
|
Hello Scott! Thank you very much for your patch! This project was abandoned a few years ago. As i remember there was another branch called "broken" which was a bit more complete. Since then there were lots of changes in bitcoin core itself: a hardfork, new types on transactions, etc, including the problem addressed by your patch. I guess I should resurrect this project someday, and try at least to keep up to the current block chain. I'll merge your patch as soon as I get back to this project. Thanks again! mtve |
|
Hi mtve, Indeed. After I sent that patch, I read in https://en.bitcoin.it/wiki/Protocol_rules about "compressed keys". I was trying to re-use logic from your modules to blindly generate tx transactions in the spirit of http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html, but with that change, it seems like it's no longer possible. One would have to actually fetch the previous tx (or txes) to see which key type was used. That seems unfortunate. BitcoinJ also doesn't seem to support compressed keys so I couldn't use it as a guide. And after a week of trying to get the network to talk to me (including using Wireshark to try to figure out why no one will answer my 'version' messages), I think I might be out of time here for now. If you find the might, you might consider releasing your ecdsa.pm as a stand-alone pure-Perl module. Regardless, thanks for sharing all of the work you did on this. Cheers, |
2 participants
bitcoind was permissive with how DER encoding was done, which lead to the transaction malliability problem.
the exact same transaction could be written multiple ways, signed, and then sent out to confuse people.
part of the fix was conicalizing DER encoded signitures. DER encoded numbers now have all leading 0 bytes
(0x00 hex) removed from the beginning except if the first byte would have its 8th bit, which would
indicate that it's negative, which s and r are never in ecdsa signitures, in which case it gets exactly one
0x00 byte stuck on to the front.
Addendum: here's an example of a 'reject' message from a bitcoind 0.9.3 upset about this:
message: f9beb4d972656a65637400000000000032000000df2fdad4027478400d6e6f6e2d63616e6f6e6963616c901bd0a0d6060fdbfca593b386000ac24374a9e6afff592a68cd697
856c578c7
in --> reject
message: tx
code: 64
reason: non-canonical
Also, awesome work on implementing ecdsa in Perl! Impressive.