-
Notifications
You must be signed in to change notification settings - Fork 2.2k
adhere more closely to BIP66 #423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
ping @weilu @jprichardson |
|
Since we discussed creating packages that represent BIPs, do you think that it makes sense to turn BIP66 functionality into a package? |
|
@jprichardson that sounds like a great idea, however, lets not let it slow down this PR? We can extract it very easily after :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should extract all above validation into a function validateDER with reference to bip66?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will later, in fact I might even pull this out to a bip66 module, that way it could be super clear.
|
The implementation looks right to me compared to the reference code. Do we have test case for each one of them though? |
|
@weilu we do have test cases for each. |
See pseudo code for BIP66 here, with ordering amendments.
The constant amendments are because we ignore the SIGHASH byte in this function, which is why the constants are
8, 72for the min/max sizes, and6instead of7for the total length offset.