bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-08-31 18:47:36 +00:00
Code Issues Releases Wiki Activity

bip379: note that the type properties assume their requirements

Browse Source 
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.
This commit is contained in:
Oli
2026-08-22 14:18:25 +02:00
parent 7fe0b034ec
commit acbc7b000b
1 changed files with 12 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
bip-0379.md
View File

@@ -155,6 +155,10 @@ its type properties in function of those of their subexpressions.
| `j:X` | X is Bn | B | o=o<sub>X</sub>; n; d; u=u<sub>X</sub>
| `n:X` | X is B | B | z=z<sub>X</sub>; o=o<sub>X</sub>; n=n<sub>X</sub>; d=d<sub>X</sub>; u
The properties of a fragment assume that the conditions in its "Requires" column are met. They exist
only to reason about correctness, so they say nothing about an expression that does not meet them:
such an expression is not valid Miniscript.
#### Timelock Type Mixing
There is one additional correctness property that Miniscript expressions must satisfy:
@@ -207,6 +211,14 @@ The following table lists the malleability properties and requirement of each fr
| `j:X` | | s=s<sub>X</sub>; e=f<sub>X
| `n:X` | | s=s<sub>X</sub>; f=f<sub>X</sub>; e=e<sub>X</sub>
As in the correctness table, the properties of a fragment assume that the conditions in its
"Requires" column are met. They exist only to reason about malleability, so they say nothing about
an expression that does not meet them: such an expression is malleable, and so is every expression
containing it.
Implementors of APIs which unconditionally return values for these properties should always return
false for malleable expressions.
### Satisfaction
The following table shows all valid satisfactions and dissatisfactions for every Miniscript, using