-
Notifications
You must be signed in to change notification settings - Fork 831
Don't allow uncompressed pks in witness addresses #428
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
Don't allow uncompressed pks in witness addresses #428
Conversation
Codecov Report
@@ Coverage Diff @@
## master #428 +/- ##
==========================================
+ Coverage 85.64% 86.19% +0.54%
==========================================
Files 39 39
Lines 7446 7402 -44
==========================================
+ Hits 6377 6380 +3
+ Misses 1069 1022 -47
Continue to review full report at Codecov.
|
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.
Looks good. Kinda annoying to have to return a Result
, but it's probably not worth the hassle to re-engineer the whole key API again 😅.
055577d
to
ed9bf41
Compare
Updated, fixed the typo and put the format and typo change in a separate commit. |
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.
LGTM
What about p2wsh?
We decided to parse the witnessScript and run a quick check to see if any chunks are 65 bytes starting with a 0x04, and if there are any we check if it is a valid secp256k1 point. Then error if it is a valid point.
There is probably near 0% chance of some useful data being 65 bytes and starting with 0x04, so maybe even checking for a valid key is overkill.
Thoughts?
Hmm, I'm a bit reluctant to parse scripts, to be honest. Perhaps this can be considered in a separate PR? I think this PRs change is quite straightforward, so I'd prefer to just merge it. If we want to do something for p2wsh, I think it might benefit from a discussion on IRC or so. |
sounds fair enough. Related: |
I agree with @sgeisler that it's unfortunate to need to return a |
@yancyribbens it's a tricky trade-off. We could have a |
@sgeisler I agree that the current PR solves the issue. It would be nice to see either using trait bounds or possibly wrapping in a enum? Either way, I agree it's probably a fair amount of work that might not be worth doing for this PR but possibly could be a followup PR. |
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.
Yeah, I think this approach is fine.
We'll need to revisit compressedness in a bit anyway when we have Taproot keys, and we can consider API changes then.
Solves #427.