-
Notifications
You must be signed in to change notification settings - Fork 831
Remove redundant code computing tap hashes #926
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
@@ -131,6 +131,21 @@ impl TapLeafHash { | |||
} | |||
} | |||
|
|||
impl TapBranchHash { | |||
/// Computes branch hash given two hashes of the nodes underneath it. | |||
pub fn from_node_hashes(a: sha256::Hash, b: sha256::Hash) -> TapBranchHash { |
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.
Referring to the previous discussion on whether this function should be public: https://github.com/rust-bitcoin/rust-bitcoin/pull/922/files#r838943645
I am using this function downstream in OP_RETURN taproot commitment code.
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 like having it be public. It seems like a generally useful thing to do.
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.
Should this parameter be TapBranchHash
instead?
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 see that for leaves it is TapLeafHash
and for nodes, it is TapBranchHash
. Maybe not worth having it here
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.
There are three hash types involved in taproot trees: TapBranchHash
, TapLeafHash
and sha256::Hash
for hidden branches/leaves or for parameters generic over branch/leaves. To solve the abiguity we have the following options
- Add type alias
pub type TapNodeHash = sha256::Hash
and use it in API - Use
impl Into<TapNodeHash>
in arguments which are generic over specific hash type - Do
From<TapBranch|LeafHash> for TapNodeHash
convertors.
But even if we decide to do so, this should be a scope of separate (quite large) 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.
Sorry to be nit-picky here. I would like this to be left
and right
instead of a
and b
.
eng.input(&a); | ||
}; | ||
TapBranchHash::from_engine(eng) | ||
} |
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:
let (min, max) = if a < b { (a, b) } else { (b, a) };
let mut eng = TapBranchHash::engine();
eng.input(&min);
eng.input(&max);
TapBranchHash::from_engine(eng)
}
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 like this, but I won't hold up the PR for it.
Ok(Self { | ||
hash: sha256::Hash::from_engine(eng), | ||
hash: sha256::Hash::from_inner(hash.into_inner()), |
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.
Is this a 'normal' thing to do, convert between the various sha256 hash types? Should be be providing conversion functions over in bitcoin_hashes
?
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.
We should probably provide a conveience method for "wrapped hashes" to their generic form (and vice-versa), yeah.
Sometimes hash conversions reflect perversions in Bitcoin, and these should appear perversely in our code :) but I don't think this is one of them.
In any case, for purposes of this PR the explicit conversion is fine.
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 f3ebfd6
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.
sorta ACK 1b28375. Left one question, that I am unsure about
@@ -131,6 +131,21 @@ impl TapLeafHash { | |||
} | |||
} | |||
|
|||
impl TapBranchHash { | |||
/// Computes branch hash given two hashes of the nodes underneath it. | |||
pub fn from_node_hashes(a: sha256::Hash, b: sha256::Hash) -> TapBranchHash { |
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.
Should this parameter be TapBranchHash
instead?
@@ -131,6 +131,21 @@ impl TapLeafHash { | |||
} | |||
} | |||
|
|||
impl TapBranchHash { | |||
/// Computes branch hash given two hashes of the nodes underneath it. | |||
pub fn from_node_hashes(a: sha256::Hash, b: sha256::Hash) -> TapBranchHash { |
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 see that for leaves it is TapLeafHash
and for nodes, it is TapBranchHash
. Maybe not worth having it here
No description provided.