Update bip-0341.mediawiki #1348

1. 
   Randy808 commented at 11:04 pm on August 7, 2022: none

   “If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path. This can be achieved by computing the output key point as Q = P + int(hash_TapTweak(bytes(P)))G”

   Calling ’taproot_tree_helper’ calls ‘hash_TapLeaf’ instead of ‘hash_TapTweak’.

2. Update bip-0341.mediawiki 4730d7a9b8
3. 
   jonasnick commented at 11:40 am on August 10, 2022: contributor

   Not sure what your point is exactly but the commit doesn’t make sense. h is supposed to be a hash, not a tweaked public key.
4. 
   Randy808 commented at 1:31 pm on August 10, 2022: none

   @jonasnick Yeah I wasn’t looking too closely and put taproot_tweak_pubkey assuming it returned the tagged hash and assuming that taproot_tweak_seckey used the h parameter as the tagged hash directly (which I see now doesn’t).

   I guess the main thing I was trying to get at is why script_tree is a parameter to the taproot_sign_key in the ‘Spending using the key path’ section when no script is needed to compute the tweak_seckey for a key path signature**?

5. Update bip-0341.mediawiki 417880adab
6. 
   Randy808 commented at 3:21 pm on August 10, 2022: none

   I’ll assume script_tree and the subsequent call to taproot_tree_helper is there in the case where a valid internal key is chosen for an output that can also be spent with a script path.

   Could an explicit case be added to return empty bytes like in https://github.com/bitcoin/bitcoin/blob/bada9636d7f2efbc620fd89107baa2bf3e64a6b8/test/functional/test_framework/script.py#L822?

7. in bip-0341.mediawiki:202 in 417880adab

   198@@ -199,6 +199,8 @@ The following function, <code>taproot_output_script</code>, returns a byte array
   199 
   200 <source lang="python">
   201 def taproot_tree_helper(script_tree):
   202+    if len(scripts) == 0:
   

   ---

   ---

   

   jonasnick commented at 8:34 am on August 12, 2022:

   scripts is undefined
8. 
   jonasnick commented at 8:37 am on August 12, 2022: contributor

   Thanks, I see what you’re saying now. Here’s my attempt at a fix: #1350. Feel free to mention there whether this addresses the issue you brought up.
9. Randy808 closed this on Aug 12, 2022

   ---

10. Randy808 cross-referenced this on Aug 12, 2022 from issue BIP 341: allow taproot_sign_key with no script tree by jonasnick
11. 
    Randy808 commented at 10:41 am on August 12, 2022: none

    @jonasnick Another thing to look at might be the commented lines below:

    0def taproot_tweak_pubkey(pubkey, h):
    1    t = int_from_bytes(tagged_hash("TapTweak", pubkey + h)) # Line A
    2    if t >= SECP256K1_ORDER:
    3        raise ValueError
    4    Q = point_add(lift_x(pubkey), point_mul(G, t))  # Line B
    5    return 0 if has_even_y(Q) else 1, bytes_from_int(x(Q))
    

    The addition of pubkey and h in ‘Line A’ implies pubkey and h are of type ‘bytes’ but the usage of lift_x(pubkey) in ‘Line B’ implies pubkey is an int (since bip340 reads “The function lift_x(x), where x is a 256-bit unsigned integer” ). Does it make sense to change pubkey to int(pubkey) in ‘Line B’ (just like how p is converted to an int in the definition of Q under the ‘Script validation rules’ section)?

    There isn’t a place to file issues for this repo and since this is a pretty small thing I thought I might just add the comment here

12. 
    jonasnick commented at 11:26 am on August 12, 2022: contributor

    Yes that makes sense. Good catch.
13. jonasnick cross-referenced this on Aug 20, 2022 from issue BIP 340 & 341: use consistent definition of lift_x by jonasnick

Contributors
Randy808 jonasnick