-
Notifications
You must be signed in to change notification settings - Fork 37.7k
Disallow automatic conversion between disparate hash types #17938
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
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
concept ACK, will review deeper if base is merged |
35e585a
to
730267f
Compare
Code review ACK 730267f |
@instagibbs rebased now that #17924 is merged |
@instagibbs how about a review? |
Concept ACK, I like the idea of using explicit and separate types here to prevent non-sensible conversions, if you can use language features to avoid bugs that's very good. |
Concept ACK: explicit conversion is better (and safer!) than implicit conversion |
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.
ACK 4b7de7c
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.
Code review ACK 4b7de7c
There is a build error unfortunately
|
Rebased, and the fix is in 1236555 I'm not sure what's up with Appveyor, and I'm happy to squash. |
I think it makes sense to squash fixup commits that fix a compile-failure. Otherwise it is not possible to compile earlier commits. |
The round-tripping through PKHash has no effect, and is potentially misleading as such.
These types are equivalent, in data etc, so they need only their data cast across. Note a function is used rather than a casting operator as CKeyID is defined at a lower level than script/standard
These types are equivalent, in data etc, so they need only their data cast across.
ScriptHash <-> CScriptID CKeyID -> PKHash PKHash -> WitnessV0KeyHash
CScript -> CScriptID -> ScriptHash is unnecessary because ScriptHash and CScriptID do the same thing.
A templated BaseHash does not allow for automatic conversion, thus conversions much be explicitly allowed / whitelisted, which will reduce the risk of unintended conversions.
Squashed the fix and rebased. |
ACK 4d73691 Only change since last is to handle a newly introduced conversion. That's also a good example of the benefits that this PR brings. |
re-utACK 4d73691 |
Summary: ``` This bases the script/standard hash types, TxDestination-related and CScriptID on a base template which does not silently convert the underlying uintN type. Inspired by and built on #17924. Commits are small and focused to ease review. Note some of these changes may be relative to existing bugs of the same sort as #17924. See particularly "Convert CPubKey to WitnessV0KeyHash directly" and "Remove an apparently unnecessary conversion". ``` Backport of core [[bitcoin/bitcoin#17938 | PR17938]]. Test Plan: ninja all check-all Reviewers: #bitcoin_abc, PiRK Reviewed By: #bitcoin_abc, PiRK Differential Revision: https://reviews.bitcoinabc.org/D9140
This bases the script/standard hash types, TxDestination-related and CScriptID on a base template which does not silently convert the underlying
uintN
type.Inspired by and built on #17924. Commits are small and focused to ease review.
Note some of these changes may be relative to existing bugs of the same sort as #17924. See particularly "Convert CPubKey to WitnessV0KeyHash directly" and "Remove an apparently unnecessary conversion".