BIP360: swap scriptPathControlBlocks[1] and [2] for three-leaf P2MR test vectors

[jasonandjay]

Summary

Problem

In a tree structured as [leaf0, [leaf1, leaf2]],
the control block for spending
a leaf must contain the sibling
hashes along the Merkle path, not the leaf's
own hash. The current test vectors have the control blocks for leaf1 and leaf2
swapped, causing them to include the spending leaf's own hash as the first path
element instead of its sibling's hash.

Example:es 1 and 2 in the

three-lea
Intermediate leaf hashes (correct in the test vector):

leafHash[0] = 2645a02e0aac1fe69d69755733a9b7621b694bb5b5cde2bbfc94066ed62b9817
leafHash[1] = ba982a91d4fc552163cb1c0da03676102d5b7a014304c01f0c77b2b8e888de1c
leafHash[2] = 9e31407bffa15fefbf5090b149d53959ecdf3f62b1246780238c24501d5ceaf6
merkleRoot  = ccbd66c6f7e8fdab47b3a486f59d28262be857f30d4773f2d5ea47f7761ce0e2
Current (incorrect)ests/data/p2mr_construction. 
[1] = c1 ba982a91...de1c 2645a02e...9817   ← first path element is leafHash[1] itself!
[2] = c1 9e31407b...f6   2645a02e...9817   ← first path element is leafHash[2] itself!

Fix swapped

scripto verify leaf1:kj = leafHash[1] = ba982a91...
ej = ba982a91...  (from control block, which IS leafHash[1])
→ tapBranchHash(ba982a91..., ba982a91...) = ccabeef4...  ← hashing with itself!
→ final root = 5037e24f... ≠ expected ccbd66c6...  ✗

Fix

Swap1 and 2 in the
three-leaf P2MRand scriptPathControlBlocks[2]:

[1] = c1 9e31407b...f6   2645a02e...9817   ← sibling of leaf1 is leafHash[2], then leafHash[0]
[2] = c1 ba982a91...de1c 2645a02e...9817   ← sibling of leaf2 is leafHash[1], then leafHash[0]

Verification of correctedontrolBlocks

entries for leaffor leaf1:kj = leafHash[1] = ba982a91...  
ej = leafHash[2] = 9e31407b...  
→ tapBranchHash(9e31..., ba98...) = ffe578e9...  ← correct inner branch hash ✓. 
ej = leafHash[0] = 2645a02e...  
→ tapBranchHash(2645..., ffe5...) = ccbd66c6...  ← correct merkle root ✓

The same issue exists in P2MR test vectors p2mr_threeand is fixed identically.

[murchandamus]

cc: @cryptoquick @EthanHeilman

[murchandamus]

Given from the look of this, that a new PR by this author was authored by Openclaw, and from the general activity on this author’s profile, I assume that this PR is AI slop. It may be useful AI slop, which is why I asked for your opinion, but I tend to close this. Will close this in a couple weeks (on or after 2026-03-30), if I don’t hear more from @cryptoquick, or @EthanHeilman.

[cryptoquick]

Just noticing this

Will direct my team to investigate

[cryptoquick]

We are still investigating this one, please hold this open for now

[jbride]

The elements in the "scriptPathControlBlocks" are currently not intended to be in any particular order.
I can understand how this could be confusing given the tree structure from the same test vectors imply an order.

I propose updating the test vectors (and corresponding BIP-360 Rust reference implementation) to order the elements in the "scriptPathControlBlocks" array and make that ordering explicit.

This update can be found here