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 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.
bip47:
- Change BIP type from Informational to Specification
- Move "recent changes" from above preamble to Changelog section
- Drop Comments headers from Preamble
Clarifies that the commutativity only applies if the original PSBTs do not have conflicting fields.
---------
Co-authored-by: Murch <murch@murch.one>
Co-authored-by: Ava Chow <github@achow101.com>
- Apply BIP-0440 wordspan notation to numeric and bitvector costs.
- Define OP_RIGHT as rightmost-byte extraction with bounded copying cost.
- Clarify OP_UPSHIFT, CLTV/CSV, and final success-check costs.
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.
