Reading the spec closely the different language used for serialization of input outpoints and input amounts was
confusing on first read. This change uses the same language
for both, which makes it easier to read.
In contrast to taproot_output_script, taproot_sign_key was not able to deal with
a script_tree that is None. This commit fixes taproot_sign_key such that it can
sign for such outputs.
This commit avoids changing the behavior of the functions except
taproot_sign_key at the cost of having some code duplication. Alternatively, one
could let taproot_tree_helper deal with a None script_tree directly.
`lift_x` returns `None` if the input integer is not an X coordinate on the curve
to indicate failure. `point_add`, on the other hand, interprets `None` as the
point at infinity. Therefore, without this commit, if the internal `pubkey` is
not a valid X coordinate, the function will not fail, which contradicts the
specification in the "Script validation rules section". Instead, it sets `Q` to
`t*G`.
Currently the BIP-341 and BIP-342 leave the question of how to verify signature for non-`0xC0` leaf version scripts undefined. I haven't checked the Bitcoin Core code for that matter yet, but (1) I think we need to cover signature validation of non-`0xC0` leaf version scripts in this standard and (2) the only way of doing that is "always succeed" rule for the future leaf version values (otherwise we will need a hard fork to introduce them).
* Pull the definition of the extension in BIP342 to its own section
* Add a section to BIP341 on validating script path signatures
* Clarify that SigMsg does not produce the message being signed, but
a common portion of it