Both tables give the properties of a fragment in function of those of its
subexpressions, and both are written assuming that the conditions in the
"Requires" column of that fragment hold. Where they do not, the tables
still assign values, but the values carry none of the meaning the
descriptions of the properties give them, and implementations are free to
differ on them.
thresh is the case that surfaced this. Its rule is "e=all are s", so
thresh(2,or_i(pk(A),pk(B)),a:or_i(pk(C),pk(D))) is "e" even though each
or_i child has two unconditional dissatisfactions, giving the threshold
four, which is the opposite of the "unique unconditional dissatisfaction"
that the description of "e" promises. The threshold fails the "e"
requirement the same table imposes, though, so it is malleable and the
value is a don't-care.
Say so below both tables, so that implementations which disagree on the
type of an invalid or malleable expression are not read as contradicting
this document. Bitcoin Core (bitcoin/bitcoin#36028) and rust-miniscript
are aligning on the values the tables give, and the test vectors proposed
in #2240 leave out the properties that are not meaningful: z/o/n/d/u for
invalid expressions and s/f/e for malleable ones.
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>
