![]() ![]()
If you want to validate historical signatures from the blockchain then either openssl or the code in contrib is sufficient. (You may need to use the signature normalize call if you want to match consensus acceptance instead of standardness acceptance). If you want to accept all transactions and only transactions that Bitcoin would accept, libsecp256k1 alone is what you want. It isn't clear to me from your question what your goal is. With some protocols that require parties to store signed transactions, that might be relevant.Īs this is historical behavior of python-bitcoinlib, I am inclined to just document this in the README.md as a 'gotcha', and leave it as it is now.īut maybe there is some other potential problems that could arise out of this issue, that may be more serious, and the first or second options described above should be considered ? What I can see is that when someone uses python-bitcointx or python-bitcoinlib to verify inputs in some transaction, and these inputs contain signatures that is accepted by openssl, but not by bitcoind, they might be convinced that tx is valid, but will have unpleasant surprise when they try to broadcast it. My question is: what may be the implications of this choice ? This means I cannot drop openssl dependency. Python-bitcoinlib was using openssl to decode, too, so I went with the later approach - decode/encode/decode. The problem with this approach (in addition to this decode/encode cycle) is that it will allow some format violations that bitcoind won't allow, because ecdsa_signature_parse_der_lax() only allows an arbitrary subset of violations allowed by openssl. ![]() encode-with-openssl then creates valid encoding, and decode-with-libsecp256k1 is happy. This way all encoding violations that openssl allows are also allowed by first decode-with-openssl.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |