Allow specifing a raw TapLeafHash in sighash computation#722
Conversation
|
Maybe |
eaaa02e to
35a25ca
Compare
|
Renamed the struct and rebased on the lastest |
35a25ca to
656d732
Compare
dr-orlovsky
left a comment
There was a problem hiding this comment.
Not sure if I am right, but better to overlook than underlook (pls see comment)
src/util/sighash.rs
Outdated
There was a problem hiding this comment.
Am I right that this will ignore the parity flag and will result in an incorrect TapLeafHash for non-even cases?
There was a problem hiding this comment.
I don't think the parity flag is encoded here, I think it's only in the control block that goes in the witness
sanket1729
left a comment
There was a problem hiding this comment.
How about just removing the existing ScriptPath? It has the slight downside of making the callee compute the leaf hash. But makes the code here cleaner.
Unrelated: I think we should really have some helper functions with minimum parameters for taproot_key_spend_sighash, and taproot_script_spend_sighash. Most users really don't care about LeafVersion, annex, and codeseparator.
656d732 to
5aa1d02
Compare
|
I've done a few changes:
|
apoelstra
left a comment
There was a problem hiding this comment.
ACK 5aa1d02fee2df825e66347abb179d7ef26330afa
Cleaner and more flexible!
sanket1729
left a comment
There was a problem hiding this comment.
cr ACK 5aa1d02fee2df825e66347abb179d7ef26330afa . There is a minor spell error, but it should not be merge blocking.
src/util/sighash.rs
Outdated
There was a problem hiding this comment.
nit: enging should be spelled engine . Same error in the following line
|
@afilini, unfortunately, I cannot merge, there is an error on test |
|
Great catch @RCasatta !! |
Thanks! But it was merit of the great tool https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/github-merge.py with |
|
TIL about |
Instead of always requiring the full raw script and leaf version, allow just specifying a raw leaf hash to the sighash computation functions. This is very useful when dealing with PSBTs, because the `PSBT_IN_TAP_BIP32_DERIVATION` field only maps a public key to a leaf hash, so a signer could just take it and produce a signature with it rathern than having to jump through hoops to recover the full raw script.
5aa1d02 to
2959e04
Compare
|
Fixed and rebased :) |
sanket1729
left a comment
There was a problem hiding this comment.
Tested locally. ACK 2959e04. Reviewed range-diff with 5aa1d02
When fuzzing my new non-recursive tree parsing logic, I noticed that we were deviating from the released 12.0 in the way that we display l:0. This is an ambiguous fragment which can be displayed either as l:0 or u:0. In our released code we use u:0 so stick with that. This was unintentially changed as part of rust-bitcoin#722. Change it back. While we are at it add a regression test for rust-bitcoin/rust-miniscript#735
…things 1259375 miniscript: make display prefer 'u' over 'l' in the fragment l:0 (Andrew Poelstra) 67fdc50 descriptor: reject strings of the form "tr(<key>,)" (Andrew Poelstra) 00cac40 descriptor: add unit test demonstrating sanity-checking behavior in <= 12.x (Andrew Poelstra) Pull request description: This PR has three changes which are mostly unrelated except that they were all found when fuzzing my "rewrite expression parser to be nonrecursive" branch against 12.x. * First is a unit test demonstrating rust-bitcoin#734. It doesn't fix anything, just tests the current behavior. * Second is a fix for rust-bitcoin#736 (backported in rust-bitcoin#735). * Third tweaks the new `Display` code from rust-bitcoin#722 to change how the ambiguous `l:0`/`u:0` is serialized, to match 12.x. ACKs for top commit: sanket1729: ACK 1259375 Tree-SHA512: 921d65a1efd49bda0f9db488a2854b004e14518f584d832497a9dbc13a845ceec99544375385570c6ac42d4985277e8dcbb3aa8654de93235cf9067ba601f91d
Still need to add some tests but the code should be ready for review. Please let me know if you have better ideas for the enum naming.
Instead of always requiring the full raw script and leaf version, allow
just specifying a raw leaf hash to the sighash computation functions.
This is very useful when dealing with PSBTs, because the
PSBT_IN_TAP_BIP32_DERIVATIONfield only maps a public key to a leafhash, so a signer could just take it and produce a signature with it
rathern than having to jump through hoops to recover the full raw
script.