Migration to new bitcoin hash type system; bumping to the latest rust-bitcoin release #238
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
All types are replaced; only work on merkle types left, which requires addition of the code
This commits contains fixes to merklization function arguments and return types. New hash type system from bitcoin crate does not cover all cases for merkle values; and the same function may be applied to different hash types. Thus, I have used generic types to abstract the logic. `Txid` merklization operates with TxMerkleNode type; `BlockHash` merklization does not introduce a new type: the same design decision was made in the original work on new bitcoin crate type system since it is used in a single case, and there is no point in introducing a special designated hash type. Script hashes (used in RPC queries) are left of Sha256dHash type since there is no corresponding type defined in bitcoin crate; this type is specific to Electrum X protocol. Corresponding new type can be implemented in the project later with `hash_newtype!` macro in the same way it was done in bitcoin crate.
d71e14a to
0ccdf44
Compare
This was referenced Apr 19, 2020
Kixunil
approved these changes
Apr 21, 2020
| let tx_nodes: Vec<TxMerkleNode> = txids | ||
| .into_iter() | ||
| .map(|txid| TxMerkleNode::from_inner(txid.into_inner())) | ||
| .collect(); |
There was a problem hiding this comment.
I don't like this allocation, but removing it is not trivial. I might look at it later and see if I can optimize it.
There was a problem hiding this comment.
Well, I think it will be nice to have direction conversion functions for such cases which are optimized by performance – and make them part of the hash type system in rust-bitcoin
There was a problem hiding this comment.
I was thinking more in terms of replacing vecs with iterators, but not really sure how applicable it is in this case. I managed to refactor those in the past, so I might try again. :)
There was a problem hiding this comment.
It seems that have to be a PR to rust-bitcoin though...
34 tasks
|
Many thanks for the contribution, much appreciated! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After my work on new bitcoin crate hash type system last year rust-bitcoin/rust-bitcoin#349 I find many project depending on the upstream
bitcoincrate being unable to update to the latest version without spending a lot of effort on type replacements (plus some additional code editing in cases like merklization). Due to my work on adding support to Signet (which was implemented in rust-bitcoin fork containing the new type system) I had to do this work, so I propose it for your consideration as a PR here. Pls review it before significant changes to the master, since it will take many hours of my time again to do any rebase, which I do not have.New hash type system from bitcoin crate does not cover all cases for merkle values; and the same function may be applied to different hash types. Thus, I have used generic types to abstract the logic.
Txidmerklization operates with TxMerkleNode type;BlockHashmerklization does not introduce a new type: the same design decision was made in the original work on new bitcoin crate type system since it is used in a single case, and there is no point in introducing a special designated hash type."Script hashes" met through the code are in fact has nothing to do with P2SH script hashes and
ScripHashtype; but instead are custom pubkeyScript hashes used in RPC queries. This data structures are left of Sha256dHash type since there is no corresponding type defined in bitcoin crate; this type is specific to Electrum X protocol. Corresponding new type can be implemented in the project later withhash_newtype!macro in the same way it was done in bitcoin crate.