In p2mr_pqc_construction.json, the three-leaf vectors
(p2mr_three_leaf_complex, p2mr_three_leaf_alternative) listed
intermediary.leafHashes with entries 0 and 2 swapped relative to the
depth-first order of the script tree, while the merkle root,
scriptPubKey, address and control blocks all follow depth-first
order (as do the same trees in p2mr_construction.json).
In p2mr_different_version_leaves, scriptPathControlBlocks[1] started
with byte 0xc1 although the leaf it commits to has leafVersion 0xfa;
the control byte carries the leaf version in its upper 7 bits with
the low bit set, so it must be 0xfb. The vector's leafHashes[1] and
merkle root already correspond to the 0xfa leaf.
Standardizes all P2MR-specific functions to use bytes uniformly for
input/output. Hex conversions are now confined to two boundaries:
reading `script` field out of ScriptTree input, and comparing against
hex-encoded test vector data in `run_single_test`.
bech32 functions and s2w are left unchanged.
This refactors `compute_control_block` to improve performance, and make
the function simpler to read (to me at least).
The previous version walked the entire script tree searching for the
first matching instance of the leaf node.
The new version expects the caller to pass in an explicit `path`
parameter, which tells us exactly where the leaf node lives, with
left/right steps encoded as bits in an integer. We walk down the
tree straight to that leaf node, and build the control block as we go.
This might not be the best DX for a real-world API or library, but this
is just reference code, so we can accept poor usage ergonomics if it makes
the code clearer and more explicit.
JP
jbride
notmike
jbride
