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 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.
This commit clarifies that even for Proof of Funds signatures the
sequence of the first input is considered as "age S".
The reasoning behind this is that only the first input is a synthetic
one that doesn't reference a real transaction to which the height could
be compared against. Even though the Proof of Funds inputs could have
higher sequence values, those heights might have already been long
reached and would make the sequence values irrelevant compared to the potential
restrictions in the challenge script.
This is cleaning up an artifact that was left over from #1352.
The alternative to removing the optionality of the address
would be to assume OP_TRUE in case of an empty address.
But that sounds like it could open up any number of potential
vulnerabilities.
And a user still has the ability to use an OP_TRUE script
in a p2wsh or p2tr address.
This commit updates the test vectors to reflect all the changes in the
previous commits and also introduces new test vectors for the Proof of
Funds variant.
This commit proposes a fix for the problem that an offline verifier
previously was not able to even verify the witness stack of additional
inputs. By providing the full finalized PSBT, a verifier has all the
input data necessary to run the script through the validation engine.
We require the PSBT to be finalized to make sure it contains the final
script witness or final script sig but no extra potentially
privacy-sensitive fields. The Non-Witness and Witness UTXO fields are
explicitly allowed for finalized PSBTs, which makes the format perfect
for the use case.
This addresses two discussion items:
- The list of UTXOs should not be interpreted as a "proof that no other
UTXOs for an address exist".
- The BIP only addresses "signer receives funds with the address" and
not "signer sent a previous transaction" use case.
This re-formats the document for easier editing and diff viewing.
Wiki syntax is weird for lists and line wraps break them. Simple lists
were changed to <ul> or <ol> tags but complex lists remain as they are
to not bloat the diff too much.
Before this commit it was not clear that non-native SegWit outputs
(e.g. P2PKH or P2SH-P2WPKH) only work if the correct scriptSig is
provided.
This then also makes it more clear why P2SH-P2WPKH outputs are NOT
supported by the "simple" variant.
This commit adds a table that clarifies what script types are compatible
with what signing variant and also makes more clear what the exact
format for the signatures of the different variants are.
Both generating and verifying a proof allows for specifying a custom
generator point G. But that custom generator point was not passed into
the dleq_challenge function, resulting in the default (secp256k1)
generator point to be used. This lead to the test vectors being
incorrect.
Oli
