From acbc7b000bf8655ecf6ef03359ba291b9e9b891f Mon Sep 17 00:00:00 2001
From: Oli <gugger@gmail.com>
Date: Sat, 22 Aug 2026 14:18:25 +0200
Subject: [PATCH] bip379: note that the type properties assume their
 requirements

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.
---
 bip-0379.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/bip-0379.md b/bip-0379.md
index 8241bded..a2b5d1fe 100644
--- a/bip-0379.md
+++ b/bip-0379.md
@@ -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