In everywhere except the handshake diagram, the transport initialization method name is `initialize_v2_transport`, but was `v2_initialize` in the diagram.
In BIP380 the capital letter H is explicitly defined as an invalid
indicator for a hardened step. The "Invalid expression" section has
explicit examples prefixed "Invalid hardened indicators" that show
"0H/0H/0H" as being wrong.
The base58 example address has an intentionally invalid checksum, but
the bech32 and bech32m examples added later have valid checksums, so
they are spendable addresses that a reader may pay by accident -- the
very hazard that motivated the invalid base58 address in #119. Two of
them are mainnet:
bc1qufgy354j3kmvuch987xe4s40836x3h0lg8f5n2 (bech32, witness v0)
bc1p5swkugezn...vep9m4p7339x5qzyrh4g (bech32m, witness v1)
tb1qghfhmd4zh7ncpmxl3qzhmq566jk8ckq4gafnmg (bech32, testnet)
Alter the final checksum character of each, and document the intent
with the note BIP 21 received in #1861. Bech32 detects any
single-character substitution, so the modified strings cannot be valid
addresses. The human-readable part, charset and length are unchanged,
so the examples remain structurally representative of P2WPKH and P2TR.
The uppercase QR-code variants are updated to match, and the changed
testnet address in the "Invalid URIs" section still demonstrates the
same point (a `tb` address in the `bc` parameter).
Alternative to #2228, which leaves the addresses untouched and instead
words the note to match them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Transaction Size and Fees section says a P2MR witness is always 32
bytes smaller than an equivalent P2TR script path spend witness. The
control blocks are 1 + 32*m and 33 + 32*m bytes, each serialised with
a compact size prefix, so at m = 7 the P2TR control block is 257 bytes
and takes a 3-byte prefix while the P2MR one is 225 bytes and takes 1.
The saving there is 34 bytes, not 32. Every other depth up to 128
gives 32.
The section already footnotes this boundary for the P2MR side a few
paragraphs earlier.
- The Test Vectors section linked P2MR_construction.json; the file on
disk is lowercase p2mr_construction.json, so the link 404s.
- The same section still linked the rust implementation under
bip-0360/ref-impl/rust, which #2202 moved out of the repository.
- The header said Version: 0.12.0 while the changelog's latest entry
is 0.12.1.
- The 135-byte depth-1 witness example labeled the merkle path
"(empty)" while counting 32 bytes for it (a depth-1 path has one
32-byte node).
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.
