379: Miniscript

achow101 commented at 4:20 pm on June 6, 2024: member

murchandamus added the label New BIP on Jun 6, 2024

murchandamus commented at 6:29 pm on June 11, 2024: contributor

Was wondering whether @sipa, @apoelstra, @sanket1729, @darosior might want to review this?

apoelstra commented at 6:51 pm on June 11, 2024: contributor

For the most part this looks great to me. In 3282c75eea9eb2698288c8d72e9a6af6f70b0e7c:

There is trailing whitespace on a couple of lines.
The definition of “non-canonical” doesn’t make sense to me (and I forget what the correct definition is supposed to be :) @sipa do you remember?)
I think the Type system section (lowercase s) should be moved up and folded into the Type System section (uppercase s).

sipa commented at 7:53 pm on June 11, 2024: member

@apoelstra I think it’s roughly right. Non-canonical (dis)satisfactions are ones that are valid by script semantics (and thus need to be taken into account when they’re available to malleators, e.g.), but can be proven to never be used by the specified non-malleable satisfaction algorithm.

achow101 force-pushed on Jun 11, 2024

achow101 commented at 7:59 pm on June 11, 2024: member

There is trailing whitespace on a couple of lines.

Fixed

I think the Type system section (lowercase s) should be moved up and folded into the Type System section (uppercase s).

This was a deliberate decision to split the discussion/reasoning/explanation of things away from the specification. The types are explained in the discussion section since an implementor does not need to understand what each type means in order to implement miniscript.

apoelstra commented at 8:00 pm on June 11, 2024: contributor

@sipa ok, rereading the text, I understand it now, but I think it’s worded in a confusing way. The text says “are not necessary to produce correct witnesses”, but the surrounding text is not about the satisfaction algorithm and it’s not clear who they’re “not necessary” to. My read of it was that they weren’t necessary to the spec, in which case, why are they listed, and why aren’t they necessary.

I think the text in your comment (they are provably unused by the satisfaction algorithm but they are legal according to consensus rules and available to malleators) is much better.

This was a deliberate decision to split the discussion/reasoning/explanation of things away from the specification. The types are explained in the discussion section since an implementor does not need to understand what each type means in order to implement miniscript.

Ok, yeah, that’s reasonable. I rescind my request then.

apoelstra commented at 8:01 pm on June 11, 2024: contributor

ACK d2f8b25ba2c0ce174c9e8c34acb4d5b7ba6affd0 except that I’d still like the first occurrence of “non-canonical” to be changed to have a clearer definition.

achow101 commented at 8:03 pm on June 11, 2024: member

I’d still like the first occurrence of “non-canonical” to be changed to have a clearer definition.

Suggest some words please?

apoelstra commented at 8:08 pm on June 11, 2024: contributor

Some options are not actually necessary to produce correct witnesses, and are called non-canonical options.

should be

Some options are inefficient and provably unnecessary to the satisfaction algorithm described below, but are valid according to Script rules and could be used by a malleator or other non-standard actor. These are called non-canonical options, and are listed for completeness…

achow101 force-pushed on Jun 11, 2024

apoelstra approved

apoelstra commented at 8:49 pm on June 11, 2024: contributor

ACK da4ca97260b7ed5aa66b5c02d032caecb3d9adb1

in bip-miniscript.md:49 in da4ca97260 outdated

44+Miniscript form - avoiding the need for additional metadata for e.g. signing devices that support
45+it.
46+
47+## Specification
48+
49+These specifications apply to P2WSH (BIP143) and Tapscript (BIP342) scripts, with only minor

sipa commented at 8:51 pm on June 11, 2024:

BIP141 specifies the P2WSH consensus rules (BIP143 is just the sighash scheme)

achow101 commented at 9:49 pm on June 11, 2024:

Fixed

in bip-miniscript.md:59 in da4ca97260 outdated

54+
55+Miniscript consists of a set of script *fragments* which are designed to be safely and correctly composabe.
56+
57+This table shows all Miniscript *fragments* and their associated semantics and Bitcoin Script.
58+Fragments that do not change the semantics of their subexpressions are called *wrappers*. Normal
59+fragments use a `fragment(arg1, arg2, ..)` notation, while wrappers are written using

sipa commented at 8:52 pm on June 11, 2024:

We don’t generally permit spaces in descriptor notation.

achow101 commented at 9:49 pm on June 11, 2024:

Fixed

in bip-miniscript.md:73 in da4ca97260 outdated

68+Miniscript fragments are expected to be used in [BIP 382](bip-0382.mediawiki) `wsh()` descriptors
69+and [BIP 386](bip-0386.mediawiki) `tr()` descriptors. Key expressions are specified in
70+[BIP 380](bip-0380.mediawiki#user-content-Key_Expressions). Additionally, BIPs 382 and 386 specify
71+restrictions on key expressions and what they resolve to - these apply to key expressions in
72+Miniscript. BIP 382's key expression restrictions apply to Miniscript in P2WSH contexts, and BIP
73+386's key expression restrictions apply to Miniscript in P2TR contexts.

sipa commented at 8:54 pm on June 11, 2024:

Perhaps a sentence like “From a user’s perspective, Miniscript is not a separate language, but a (significant) expansion of the descriptor language”? Alternatively, this could go in the Abstract too.

achow101 commented at 9:49 pm on June 11, 2024:

Done

in bip-miniscript.md:123 in da4ca97260 outdated

118+
119+#### Correctness
120+
121+Every miniscript expression has one of four basic types: "**B**" (base), "**V**" (verify),
122+"**K**" (key) and "**W**" (wrapped). Then there are 6 type modifiers which guarantee additional
123+properties: "**z**" (zero arg), "**o**" (one-arg), "**n**" (nonzero), "**d**"

sipa commented at 8:55 pm on June 11, 2024:

Nit: consistency, either “zero-arg” and “one-arg”, or “zero arg” and “one arg”.

achow101 commented at 9:49 pm on June 11, 2024:

Fixed

in bip-miniscript.md:125 in da4ca97260 outdated

119+#### Correctness
120+
121+Every miniscript expression has one of four basic types: "**B**" (base), "**V**" (verify),
122+"**K**" (key) and "**W**" (wrapped). Then there are 6 type modifiers which guarantee additional
123+properties: "**z**" (zero arg), "**o**" (one-arg), "**n**" (nonzero), "**d**"
124+(dissatisfiable), "**u**" (unit) and "**k**" (no timelock mixing).

sipa commented at 8:56 pm on June 11, 2024:

The typing rules for timelock mixing don’t seem to be included here.

achow101 commented at 8:04 pm on June 13, 2024:

Hmm, it seems like representing them in the table might be complicated since it depends on the arguments to the older and after fragments.

sanket1729 commented at 10:34 pm on June 16, 2024:

How about adding as a small description as suggested here?

in bip-miniscript.md:161 in da4ca97260 outdated

156+| `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
157+
158+
159+#### Malleability
160+
161+Malleability is the ability for a third party (*not* a participant in the script) to modify an

sipa commented at 8:57 pm on June 11, 2024:

“participant” could be made more specific: “not someone who holds a participating private key”.

achow101 commented at 9:49 pm on June 11, 2024:

Done

sipa commented at 8:59 pm on June 11, 2024: member

A few quick comments.

achow101 force-pushed on Jun 11, 2024

in bip-miniscript.md:231 in 94ac21c60d outdated

226+| `or_c(X,Z)`                  | *(none)*                                                | sat(X); sat(Z) dsat(X)
227+| `or_d(X,Z)`                  | dsat(Z) dsat(X)                                         | sat(X); sat(Z) dsat(X)
228+| `or_i(X,Z)`                  | dsat(X) 1; dsat(Z) 0                                    | sat(X) 1; sat(Z) 0
229+| `thresh(k,X_1,...,X_n)`      | All dsats; ~~[Sats/dsats with 1 &le; #(sats) &ne; k]~~  | Sats/dsats with #(sats) = k
230+| `multi(k,key_1,...,key_n)`   | 0 0 ... 0 (k+1 times)                                   | 0 sig ... sig
231+| `multi_a(k,key_1,...,key_n)` | 0 ... 0 (n times)                                       | sig/0 with #(sig) = k and #(sigs/0) = n

darosior commented at 8:40 am on June 13, 2024:

it’s missing a non-canonical dissatisfaction for multi_a: sig/0 with #(sig) ≠ k

achow101 commented at 7:48 pm on June 13, 2024:

Done

in bip-miniscript.md:149 in 94ac21c60d outdated

144+| `or_b(X,Z)`                  | X is Bd; Z is Wd                                      | B           | z=z<sub>X</sub>z<sub>Z</sub>; o=z<sub>X</sub>o<sub>Z</sub> or z<sub>Z</sub>o<sub>X</sub>; d; u
145+| `or_c(X,Z)`                  | X is Bdu; Z is V                                      | V           | z=z<sub>X</sub>z<sub>Z</sub>; o=o<sub>X</sub>z<sub>Z</sub>
146+| `or_d(X,Z)`                  | X is Bdu; Z is B                                      | B           | z=z<sub>X</sub>z<sub>Z</sub>; o=o<sub>X</sub>z<sub>Z</sub>; d=d<sub>Z</sub>; u=u<sub>Z</sub>
147+| `or_i(X,Z)`                  | both are B, K, or V                                   | same as X/Z | o=z<sub>X</sub>z<sub>Z</sub>; u=u<sub>X</sub>u<sub>Z</sub>; d=d<sub>X</sub> or d<sub>Z</sub>
148+| `thresh(k,X_1,...,X_n)`      | 1 &le; k &le; n; X<sub>1</sub> is Bdu; others are Wdu | B           | z=all are z; o=all are z except one is o; d; u
149+| `multi(k,key_1,...,key_n)`   | 1 &le; k &le; n                                       | B           | n; d; u

darosior commented at 8:43 am on June 13, 2024:

nit: we could add “n ≤ 20” as a constraint as per https://github.com/sipa/miniscript/pull/131

achow101 commented at 7:48 pm on June 13, 2024:

Done

in bip-miniscript.md:350 in 94ac21c60d outdated

333+
334+When analysing Miniscripts for resource limits, restricting yourself to just non-malleable solutions
335+(or even non-malleable scripts) also leads to tighter bounds, as all non-canonical satisfactions and
336+dissatisfactions can be left out of consideration.
337+
338+The malleability analysis makes the following assumptions:

darosior commented at 8:45 am on June 13, 2024:

I think it’s worth mentioning one assumption made by the malleability analysis is that an attacker is constrained by common standardness rules, as per https://github.com/sipa/miniscript/pull/129/files.

achow101 commented at 7:48 pm on June 13, 2024:

Done

achow101 force-pushed on Jun 13, 2024

apoelstra commented at 4:10 pm on June 14, 2024: contributor

ACK c868e9e3d662663dafff5a4d9fbee35a6bc4b94e other than the locktime rule.

I think that, after the correctness table, we should add some text like:

“Additionally there is one global correctness rule: every older fragment within a Miniscript fragment must make the same choice of height- or time-based timelocks. Similarly, every after fragment must make the same choice of height- or time-based timelocks. (It is permissible for the older fragments to differ from the after fragments.)”

I think it makes sense for this to appear outside of the table because all the rules in the table are local, in the sense that once you see a fragmet you know whether it’s legal or not. Vs this thing which is a global rule that breaks composability.

Maybe we should recommend people always use height-based timelocks to avoid running afoul of this rule?

sipa commented at 4:15 pm on June 14, 2024: member

@apoelstra That’s too strong, I think. It is only groups that get anded/threshed together that cannot conflict in their height vs time constraints. Pure disjunctions can make distinct choices. In that sense it is not a global constraint, but a local one just like the other type properties.

apoelstra commented at 4:17 pm on June 14, 2024: contributor

Ah, yes, you’re right. It’s a local constraint on the conjunctions and thresholds I guess.

sanket1729 commented at 7:12 pm on June 14, 2024: contributor

@achow101 @murchandamus I have this on my review list for this weekend.

sanket1729 commented at 10:31 pm on June 16, 2024: contributor

I think it makes sense for this to appear outside of the table because all the rules in the table are local, in the sense that once you see a fragmet you know whether it’s legal or not. Vs this thing which is a global rule that breaks composability.

I think adding 5 new type properties in the table will pollute(add too many things in the row) the existing properties and confuse people. For the sake of completeness, we can write a description of how “k” property is computed and link to the source c++ code for details.

How about adding a line after the table:

Property ‘k’ is determined as follows: Each leaf node inherently possesses property ‘k’. A parent node will not have property ‘k’ if any of its children lack this property. Furthermore, in scenarios involving thresholds (k ≥ 2) or conjunctions, property ‘k’—which indicates no-timelock mixing—is absent if the node contains two or more children that require different types of timelock conditions for their satisfaction.

achow101 force-pushed on Jun 19, 2024

achow101 commented at 0:17 am on June 19, 2024: member

I think adding 5 new type properties in the table will pollute(add too many things in the row) the existing properties and confuse people. For the sake of completeness, we can write a description of how “k” property is computed and link to the source c++ code for details.

I agree

How about adding a line after the table:

Property ‘k’ is determined as follows: Each leaf node inherently possesses property ‘k’. A parent node will not have property ‘k’ if any of its children lack this property. Furthermore, in scenarios involving thresholds (k ≥ 2) or conjunctions, property ‘k’—which indicates no-timelock mixing—is absent if the node contains two or more children that require different types of timelock conditions for their satisfaction.

I’ve added a line similar to this, with slightly different wording.

apoelstra commented at 1:55 pm on June 19, 2024: contributor

0For parent nodes with multiple children (thresholds and conjunctions),

should be changed to Sanket’s original For thresholds with k >= 2 and conjunctions,. The existing wording is confusing because it’s not obvious what the rule for disjunctions or k=1 thresholds are.

achow101 commented at 5:02 pm on June 19, 2024: member

should be changed to Sanket’s original For thresholds with k >= 2 and conjunctions,. The existing wording is confusing because it’s not obvious what the rule for disjunctions or k=1 thresholds are.

I find it confusing that the type is k, but for thresholds, we’re also going to mentioning a k that means something completely different.

Updated the sentence.

achow101 force-pushed on Jun 19, 2024

sipa commented at 11:26 pm on June 19, 2024: member

If we’re not going to include “k” as a property in the tables, then I don’t think it needs a letter. It can just be described.

It’s not the only type property that doesn’t have a letter: “validity” and “nonmalleability” also fall in that category.

achow101 force-pushed on Jun 20, 2024

achow101 commented at 4:07 am on June 20, 2024: member

I’ve removed the k property and wrote a subsection that describes the timelock mixing constraints. The wording is a little bit awkward though.

apoelstra commented at 1:50 pm on June 20, 2024: contributor

I would suggest this wording:

"

Timelock Type Mixing

There is one additional correctness property that Miniscript programs must satisfy: the four timelock types (absolute time-based, absolute height-based, relative time-based and relative height-based) must not be mixed in an incompatible way. Specifically, within the and combinator and the thresh combinator where k >= 2, it is illegal for both absolute height-based and time-based locktimes to appear, or for both relative height-based and time-based locktimes to appear.

Outside of these combinators, it is legal to mix height-based and time-based timelocks, and it is always legal to mix absolute and relative timelocks (even if one is height-based and the other is time-based). "

I think trying to split height/time and absolute/relative into “types” and “categories” is too hard to describe clearly and that it’s easier to exhaustively list all four possibilities and how the can be mixed.

sipa commented at 2:25 pm on June 20, 2024: member

In the Bitcoin Core implementation malleability and timelock mixing (as well as resource limit checks) are not part of “validity”, but of “sanity”. The distinction being that valid-but-insane miniscripts can be parsed, and the satisfaction algorithm can be run for it, and if it succeeds the result can be a valid transaction. Sanity additionally guarantees that the resulting policy of the actually emitted script will match the apparent policy. The idea is that when designing scripts you probably only want sane ones, but if somehow you’re confronted with an insane but valid one after the fact (e.g., it already holds funds), the code shouldn’t fail at the parsing stage preventing you from attempting to sign it anyway.

Do we want to make that distinction clear in the BIP?

apoelstra commented at 2:31 pm on June 20, 2024: contributor

Similar in rust-miniscript – though we’ve generalized things a bit so that the caller can (if they want to use the annoying form of the API) individually toggle all of the “sanity” checks. The exact definition of “sane” feels ad-hoc and hard to remember and usually I need to check the source code of the default rust-miniscript parser to see which flags it has set/unset.

IMHO we shouldn’t bother making this distinction in the BIP, and just consider insane parsers to be “extensions” or nonstandard. Though maybe we could add a sentence saying it’s possible to do this.

sipa commented at 2:37 pm on June 20, 2024: member

@apoelstra I’m not sure. The sanity checks are arguably more complicated (or at least similarly complicated) to all the validity checks combined. If we want to only treat sane scripts as BIP-valid-miniscript, then I think it should be fully specified in the BIP (including e.g. stack limit analysis).

achow101 commented at 3:27 pm on June 20, 2024: member

it is legal to mix height-based and time-based timelocks

~I presume you meant to say illegal?~

Nvm, misunderstood that sentence

achow101 force-pushed on Jun 20, 2024

achow101 commented at 3:38 pm on June 20, 2024: member

Updated the timelock mixing text

in bip-miniscript.md:50 in a1f63b50d6 outdated

45+it.
46+
47+## Specification
48+
49+These specifications apply to P2WSH (BIP141) and Tapscript (BIP342) scripts, with only minor
50+variations between the two. Differences are noted inline. Unless explicitly stated specifications

jonatack commented at 9:06 pm on June 20, 2024:

0variations between the two. Differences are noted inline. Unless explicitly stated otherwise, specifications

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:31 in a1f63b50d6 outdated

26+
27+## Motivation
28+
29+Bitcoin Script is an unusual stack-based language with many edge cases, designed for implementing
30+spending conditions consisting of various combinations of signatures, hash locks, and time locks.
31+Yet despite being limited in functionality it is still highly nontrivial to:

jonatack commented at 9:07 pm on June 20, 2024:

0Yet, despite being limited in functionality, it is still highly nontrivial to do the following with Bitcoin Script:

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:49 in a1f63b50d6 outdated

44+Miniscript form - avoiding the need for additional metadata for e.g. signing devices that support
45+it.
46+
47+## Specification
48+
49+These specifications apply to P2WSH (BIP141) and Tapscript (BIP342) scripts, with only minor

jonatack commented at 9:09 pm on June 20, 2024:

Here and line 332, perhaps use the spacing and internal BIP links like the other references to BIPs in this draft, e.g. lines 68-74.

0These specifications apply to P2WSH (BIP 141) and Tapscript (BIP 342) scripts, with only minor

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:83 in a1f63b50d6 outdated

78+| false                                                    | `0`                           | `0`
79+| true                                                     | `1`                           | `1`
80+| check(key)                                               | `pk_k(key)`                   | `<key>`
81+|                                                          | `pk_h(key)`                   | ` DUP HASH160 <HASH160(key)> EQUALVERIFY `
82+|                                                          | `pk(key)` = `c:pk_k(key)`     | `<key> CHECKSIG`
83+|                                                          | `pkh(key)` = `c:pk_h(key)`    | ` DUP HASH160 <HASH160(key)> EQUALVERIFY CHECKSIG`

jonatack commented at 9:16 pm on June 20, 2024:

0|                                                          | `pkh(key)` = `c:pk_h(key)`    | `DUP HASH160 <HASH160(key)> EQUALVERIFY CHECKSIG`

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:81 in a1f63b50d6 outdated

76+| Semantics                                                | Miniscript Fragment           | Bitcoin Script
77+|----------------------------------------------------------|-------------------------------|---------------
78+| false                                                    | `0`                           | `0`
79+| true                                                     | `1`                           | `1`
80+| check(key)                                               | `pk_k(key)`                   | `<key>`
81+|                                                          | `pk_h(key)`                   | ` DUP HASH160 <HASH160(key)> EQUALVERIFY `

jonatack commented at 9:16 pm on June 20, 2024:

0|                                                          | `pk_h(key)`                   | `DUP HASH160 <HASH160(key)> EQUALVERIFY `

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:123 in a1f63b50d6 outdated

118+system for Miniscript.
119+
120+#### Correctness
121+
122+Every miniscript expression has one of four basic types: "**B**" (base), "**V**" (verify),
123+"**K**" (key) and "**W**" (wrapped). Then there are 5 type modifiers which guarantee additional

jonatack commented at 9:20 pm on June 20, 2024:

0"**K**" (key) and "**W**" (wrapped). Then there are 5 type modifiers that guarantee additional

(“which” would require a preceding comma)

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:256 in a1f63b50d6 outdated

251+
252+#### Non-malleable Satisfaction Algorithm
253+
254+In order to produce non-malleable satisfactions we make use of a function that returns the optimal
255+satisfaction and dissatisfaction for a given expression (if any exist), or a special DONTUSE value,
256+together with an optional HASSIG marker that tracks whether the solution contains at least one

jonatack commented at 9:31 pm on June 20, 2024:

Suggestion on first use of HASSIG.

0together with an optional HASSIG ("has signature") marker that tracks whether the solution contains at least one

Perhaps also for DONTUSE, for non-native English speakers.

achow101 commented at 0:18 am on June 21, 2024:

Done and for DONTUSE.

in bip-miniscript.md:260 in a1f63b50d6 outdated

255+satisfaction and dissatisfaction for a given expression (if any exist), or a special DONTUSE value,
256+together with an optional HASSIG marker that tracks whether the solution contains at least one
257+signature. To implement the function:
258+* Invoke the function recursively for all subexpressions, obtaining all their satisfactions/dissatisfactions.
259+* Iterate over all the valid satisfactions/dissatisfactions in the table above (including the non-canonical ones), taking into account:
260+ * The dissatisfactions for `sha256`, `ripemd160`, `hash256`, and `hash160` are always malleable, so instead use DONTUSE there.

jonatack commented at 9:33 pm on June 20, 2024:

The intended additional indentation on these four lines 260-263 doesn’t seem visible in the preview.

achow101 commented at 0:18 am on June 21, 2024:

Fixed, also fixed another indentation down below.

in bip-miniscript.md:343 in a1f63b50d6 outdated

338+such guaranteed-nonmalleable scripts, as unexpected behavior can occur when using other scripts.
339+
340+For example, when running the non-malleable satisfaction algorithm above, adding available
341+preimages, or increasing the nLockTime/nSequence values actually may make it fail where it succeeded
342+before. This is because a larger set of met conditions may mean an existing satisfaction goes from
343+nonmalleable to malleable. Restricting things to scripts that are guaranteed to be satisfiable in a

jonatack commented at 9:47 pm on June 20, 2024:

Here and line 337 (s/nonmalleably/non-malleably/, per your writing elsewhere in this document.

0non-malleable to malleable. Restricting things to scripts that are guaranteed to be satisfiable in a

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:386 in a1f63b50d6 outdated

381+
382+
383+### Resource Limits
384+
385+Various types of Bitcoin Scripts have different resource limitations, either through consensus or standardness. Some of them affect otherwise valid Miniscripts:
386+* In P2WSH, scripts larger than 3600 bytes are invalid by standardness. In Tapscript scripts are implicitly bounded by the maximum size of a block (1 million virtual bytes).

jonatack commented at 9:51 pm on June 20, 2024:

0* In P2WSH, scripts larger than 3600 bytes are invalid by standardness. In Tapscript, scripts are implicitly bounded by the maximum size of a block (1 million virtual bytes).

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:417 in a1f63b50d6 outdated

412+
413+A first reference implementation and documentation for Miniscript in P2WSH was originally published at
414+https://github.com/sipa/miniscript .
415+
416+The reference implementation for Miniscript in P2WSH was introduced in Bitcoin Core through PRs
417+https://github.com/bitcoin/bitcoin/pull/24147 https://github.com/bitcoin/bitcoin/pull/24148 and

jonatack commented at 9:53 pm on June 20, 2024:

0[https://github.com/bitcoin/bitcoin/pull/24147](https://github.com/bitcoin/bitcoin/pull/24147), https://github.com/bitcoin/bitcoin/pull/24148 and

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:418 in a1f63b50d6 outdated

413+A first reference implementation and documentation for Miniscript in P2WSH was originally published at
414+https://github.com/sipa/miniscript .
415+
416+The reference implementation for Miniscript in P2WSH was introduced in Bitcoin Core through PRs
417+https://github.com/bitcoin/bitcoin/pull/24147 https://github.com/bitcoin/bitcoin/pull/24148 and
418+https://github.com/bitcoin/bitcoin/pull/24149 . The last one to be merged was released in Bitcoin

jonatack commented at 9:54 pm on June 20, 2024:

0[https://github.com/bitcoin/bitcoin/pull/24149](https://github.com/bitcoin/bitcoin/pull/24149). The last one to be merged was released in Bitcoin

achow101 commented at 0:18 am on June 21, 2024:

Done

in bip-miniscript.md:422 in a1f63b50d6 outdated

417+https://github.com/bitcoin/bitcoin/pull/24147 https://github.com/bitcoin/bitcoin/pull/24148 and
418+https://github.com/bitcoin/bitcoin/pull/24149 . The last one to be merged was released in Bitcoin
419+Core version 25.0.
420+
421+The reference implementation for Miniscript in Tapscript was introduced in Bitcoin Core in PR
422+https://github.com/bitcoin/bitcoin/pull/27255 . This PR was merged and released for Bitcoin Core

jonatack commented at 9:54 pm on June 20, 2024:

0[https://github.com/bitcoin/bitcoin/pull/27255](https://github.com/bitcoin/bitcoin/pull/27255). This PR was merged and released in Bitcoin Core

achow101 commented at 0:19 am on June 21, 2024:

Done

jonatack commented at 10:44 pm on June 20, 2024: contributor

Looks like this needs a BIP assignment.

A few optional minor suggestions follow.

BIP 388 contains many references to Miniscript and may need verification of cross-references and updating.

jonatack added the label Needs number assignment on Jun 20, 2024

jonatack commented at 11:00 pm on June 20, 2024: contributor

Assigned BIP 379.

jonatack removed the label Needs number assignment on Jun 20, 2024

achow101 force-pushed on Jun 21, 2024

BIP 379: Specify Miniscript

Co-Authored-By: Antoine Poinsot <darosior@protonmail.com>

4b321d7246

achow101 force-pushed on Jun 21, 2024

achow101 commented at 0:23 am on June 21, 2024: member

BIP 388 contains many references to Miniscript and may need verification of cross-references and updating.

I’ll let @bigspider do that in a separate pr.

achow101 renamed this:
~~BIP miniscript~~
379: Miniscript
on Jun 21, 2024

apoelstra commented at 2:48 pm on June 21, 2024: contributor

ACK 4b321d7246eca5ac5887df5da6186c4e6e8e6c64 @sipa yeah, agreed. It does seem like the sanity checks are a big deal and should be specified. I don’t know if they belong here (though it is weird that we have included timelock mixing and put it under “correctness” but not included any other discussion of sanity).

On the other hand, because of the complexity and lack of written specification of the sanity rules (and also I’m not thrilled with the names “sane”/“insane” which were kinda funny when we came up with them, but are awkward to use because “insane” has the wrong connotations when we really mean something like “contains branches that are not verified to be sane”), I don’t want to hold up this PR/BIP for it. Nor do I want to have a big discussion on Github which really sucks for long discussions.

I wonder if we should accept this BIP as-is and then move to the ML to propose an extension to it (which would be strictly additive and could be folded into the same BIP) for the sanity rules.

The only question is what to do with the current timelock-mixing text, which IMHO looks good to me other than possibly it shouldn’t be labelled “correctness”.

in bip-0379.md:50 in 4b321d7246

45+it.
46+
47+## Specification
48+
49+These specifications apply to P2WSH ([BIP 141](bip-0141.mediawiki)) and Tapscript ([BIP 342](bip-0342.mediawiki)) scripts, with only minor
50+variations between the two. Differences are noted inline. Unless explicitly stated otherise,

jonatack commented at 8:54 pm on June 22, 2024:

not worth invalidating review for, can be a follow-up

0variations between the two. Differences are noted inline. Unless explicitly stated otherwise,

jonatack commented at 5:11 pm on June 27, 2024:

done in the rebase

jonatack commented at 8:54 pm on June 22, 2024: contributor

Format looks complete. @sipa @darosior @sanket1729 sign-off?

jonatack commented at 5:12 pm on June 27, 2024: contributor

Rebased for #1540 and merged manually.

jonatack closed this on Jun 27, 2024

379: Miniscript #1610

Timelock Type Mixing