Implementing this for spendinfo is really complicated because it
contains some cached data without retaining the components that are used
to compute them.
Users should serde the 1) NodeInfo and 2) internal key and reconstruct
TaprootSpendInfo from it.
Cleanly separate `TapTree` and `NodeInfo`. Fix serde not respecting
invariants for several data structures
Repurpose some tests from removed taproot builder for taptree
"schnorr" is a dirty word; the current `schnorr` module defines a
`Signature` that includes a sighash type, this sighash type is a bitcoin
specific construct related to taproot. Therefore the `Signature` is
better named `taproot::Signature`. Note also that the usage of `schnorr`
in `secp256k1` is probably justified because the
`secp256::schnorr::Signature` is just doing the crypto.
While we are at it, update docs and error messages to use "taproot"
instead of "schnorr". Also change function names and identifiers that
use "schnorr".
In order that we can safely change/maintain de/serialization code we
need to have regression tests with hard coded serializations for each
type that implements serde.
It is enough to test a single serde data format, use JSON for `opcodes`
and bincode for other types.
Do regression testing in a newly added `tests` module.
Subhradeep Chakraborty
sanket1729
Tobin C. Harding
Andrew Poelstra