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
Make TaprooBuilder::finalize able to return keyspend only #936
Conversation
b4158a9
to
17f629b
Compare
17f629b
to
7969b7a
Compare
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.
One small comment
Why is this important if the function takes ownership of the value? It
would be dropped in the error, no?
Happy to fixup soon if it matters, mostly asking to see if I'm missing
something else.
…On Thu, Apr 7, 2022, 11:47 AM Andrew Poelstra ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/util/taproot.rs
<#936 (comment)>
:
> pub fn finalize<C: secp256k1::Verification>(
mut self,
secp: &Secp256k1<C>,
internal_key: UntweakedPublicKey,
) -> Result<TaprootSpendInfo, TaprootBuilderError> {
- if self.branch.len() > 1 {
- return Err(TaprootBuilderError::IncompleteTree);
+ match self.branch.pop() {
+ None => Ok(TaprootSpendInfo::new_key_spend(secp, internal_key, None)),
+ Some(Some(node)) => {
+ Ok(TaprootSpendInfo::from_node_info(secp, internal_key, node))
+ }
+ _ => Err(TaprootBuilderError::IncompleteTree),
Agreed -- can you change this to push the data back onto self.branch in
this case?
—
Reply to this email directly, view it on GitHub
<#936 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGYN642UI7WTGZNPNAKCYLVD37QNANCNFSM5SNMTTPQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Ha! I missed the ownership thing during review as well, perhaps a code comment in the function mentioning it? |
The inner API
Yes, but this was in the previous case when the builder was empty. Perhaps, the correct thing to do here(and other builder APIs) is to return to the previous builder state in the error value. |
@sanket1729 that sounds like a bigger change because then it's a breaking API change vs a bug fix that can be minor released. Can we merge this patch for a point release as-is and we can open a new issue for the above (change to a continuation that lets you continue?) |
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 7969b7a
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 7969b7a
I missed the ownership thing as well :).
TBH I don't really follow the discussion here. Will hold off on merging until @sanket1729 agrees that it's resolved. But I'm fine to pull this into the release. It is technically adding extra functionality, which we aren't supposed to do, but it's small.
I think the resolution is that we'll do a breaking API change later to make
finalize return an error + state to keep working on it if finalize failed,
but we'll do that after a non breaking change to just fix the 'non
totality' of the current builder, which should go into the release.
By non totality, I mean there are reasonable taprootspendinfos that cannot
be built
…On Mon, Apr 18, 2022, 4:40 PM Andrew Poelstra ***@***.***> wrote:
***@***.**** approved this pull request.
ACK 7969b7a
<7969b7a>
I missed the ownership thing as well :).
TBH I don't really follow the discussion here. Will hold off on merging
until @sanket1729 <https://github.com/sanket1729> agrees that it's
resolved. But I'm fine to pull this into the release. It is technically
adding extra functionality, which we aren't supposed to do, but it's small.
—
Reply to this email directly, view it on GitHub
<#936 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGYN62EVW64ZJSKYDTGHULVFXJD3ANCNFSM5SNMTTPQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Can you point to an example? |
Yes the example being a key spend only taprootspendinfo cannot be built from taprootbuilder before this patch, after the patch it can be. I.e., should all taprootspendinfos be reachable by the builder?
Probably I should have included a test showing this.
|
This commit does two things: 1) BUG FIX: We should have checked that the length of the branch is 1 before computing the spend_info on it. This was introduced in rust-bitcoin#936, but slipped past my review :( 2) Update the return type to return the consumed `self` value. This function can only error when there the tree building is not complete. Returning TaprootBuilderError causes issues in downstream projects that need to deal with error cases which cannot happen in this function
This commit does two things: 1) BUG FIX: We should have checked that the length of the branch is 1 before computing the spend_info on it. This was introduced in rust-bitcoin#936, but slipped past my review :( 2) Update the return type to return the consumed `self` value. This function can only error when there the tree building is not complete. Returning TaprootBuilderError causes issues in downstream projects that need to deal with error cases which cannot happen in this function
This commit does two things: 1) BUG FIX: We should have checked that the length of the branch is 1 before computing the spend_info on it. This was introduced in rust-bitcoin#936, but slipped past my review :( 2) Update the return type to return the consumed `self` value. This function can only error when there the tree building is not complete. Returning TaprootBuilderError causes issues in downstream projects that need to deal with error cases which cannot happen in this function
This commit does two things: 1) BUG FIX: We should have checked that the length of the branch is 1 before computing the spend_info on it. This was introduced in rust-bitcoin#936, but slipped past my review :( 2) Update the return type to return the consumed `self` value. This function can only error when there the tree building is not complete. Returning TaprootBuilderError causes issues in downstream projects that need to deal with error cases which cannot happen in this function
870ad59 Rename is_finalized to is_finalizable (sanket1729) aaadd25 Add breaking test that allowed incomplete builders to be created (sanket1729) 0b88051 Update TaprootBuilder::finalize (sanket1729) 5813ec7 Return EmptyTree instead of OverCompleteTree when there are no scripts to add (sanket1729) Pull request description: Found while reviewing rust-bitcoin/rust-miniscript#450 . There is also a BUG fix in the second commit that would have let users spendinfo from incomplete trees. The bug was introduced in #936 which I am responsible for ACKing ACKs for top commit: apoelstra: ACK 870ad59 Kixunil: ACK 870ad59 tcharding: ACK 870ad59 Tree-SHA512: 61442bd95df6912865cbecdc207f330b241e7fbb88b5e915243b2b48a756bea9eb29cb28d8c8249647a0a2ac514df4737bddab695f63075bd55284be5be228ff
Yes the example being a key spend only taprootspendinfo cannot be built
from taprootbuilder before this patch, after the patch it can be. I.e.,
should all taprootspendinfos be reachable by the builder?
…On Wed, Apr 20, 2022, 11:38 AM Sanket Kanjalkar ***@***.***> wrote:
I mean there are reasonable taprootspendinfos that cannot be built
Can you point to an example?
—
Reply to this email directly, view it on GitHub
<#936 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGYN6ZP4WPW46FB55MURITVGAXGRANCNFSM5SNMTTPQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
No description provided.