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

1. 
   jasonandjay commented at 1:57 am on February 15, 2026: none

   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):

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

   Fix swapped

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

   Fix

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

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

   Verification of correctedontrolBlocks

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

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

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

   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.
   
   Fix swapped scriptPathControlBlocks entries for:
   - p2mr_three_leaf_complex
   - p2mr_three_leaf_alternative

   3081e08900
3. 
   murchandamus commented at 9:59 pm on February 17, 2026: member

   cc: @cryptoquick @EthanHeilman
4. murchandamus added the label Pending acceptance on Feb 17, 2026
5. murchandamus added the label Bug fix on Feb 17, 2026
6. murchandamus renamed this:
   fix: swap scriptPathControlBlocks[1] and [2] for three-leaf P2MR test vectors
   BIP360: swap scriptPathControlBlocks[1] and [2] for three-leaf P2MR test vectors
   on Feb 17, 2026
7. 
   murchandamus commented at 5:32 pm on March 16, 2026: member

   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.
8. 
   cryptoquick commented at 5:34 pm on March 16, 2026: contributor

   Just noticing this

   Will direct my team to investigate

9. 
   cryptoquick commented at 10:19 pm on March 16, 2026: contributor

   We are still investigating this one, please hold this open for now
10. 
    jbride commented at 1:35 pm on March 17, 2026: none

    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

Contributors
jasonandjay murchandamus cryptoquick jbride

Labels
Pending acceptance Bug fix