379: Miniscript #1610
pull achow101 wants to merge 1 commits into bitcoin:master from achow101:miniscript changing 2 files +430 −0-
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
-
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 (lowercases
) should be moved up and folded into theType System
section (uppercases
).
-
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 (lowercases
) should be moved up and folded into theType System
section (uppercases
).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: contributorACK 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: contributorACK 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:Fixedin 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:Fixedin 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:Donein 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:Fixedin 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 theolder
andafter
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:Donesipa commented at 8:59 pm on June 11, 2024: memberA few quick comments.achow101 force-pushed on Jun 11, 2024in 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 ≤ #(sats) ≠ 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 formulti_a
: sig/0 with #(sig) ≠ k
achow101 commented at 7:48 pm on June 13, 2024:Donein 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 ≤ k ≤ 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 ≤ k ≤ 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:Donein 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:Doneachow101 force-pushed on Jun 13, 2024apoelstra commented at 4:10 pm on June 14, 2024: contributorACK 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, everyafter
fragment must make the same choice of height- or time-based timelocks. (It is permissible for theolder
fragments to differ from theafter
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: contributorAh, 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: contributorI 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, 2024achow101 commented at 0:17 am on June 19, 2024: memberI 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: contributor0For 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: membershould 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 ak
that means something completely different.
Updated the sentence.
achow101 force-pushed on Jun 19, 2024achow101 force-pushed on Jun 19, 2024sipa commented at 11:26 pm on June 19, 2024: memberIf 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, 2024achow101 commented at 4:07 am on June 20, 2024: memberI’ve removed thek
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: contributorI 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 thethresh
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: memberIn 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: contributorSimilar 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: memberit 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, 2024achow101 commented at 3:38 pm on June 20, 2024: memberUpdated the timelock mixing textin 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:Donein 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:Donein 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:Donein 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:Donein 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:Donein 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:Donein 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 forDONTUSE
.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:Donein 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:Donein 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:Donein 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:Donein 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:Donejonatack commented at 10:44 pm on June 20, 2024: contributorLooks 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, 2024jonatack commented at 11:00 pm on June 20, 2024: contributorAssigned BIP 379.jonatack removed the label Needs number assignment on Jun 20, 2024achow101 force-pushed on Jun 21, 2024achow101 force-pushed on Jun 21, 2024BIP 379: Specify Miniscript
Co-Authored-By: Antoine Poinsot <darosior@protonmail.com>
achow101 force-pushed on Jun 21, 2024achow101 commented at 0:23 am on June 21, 2024: memberBIP 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, 2024apoelstra commented at 2:48 pm on June 21, 2024: contributorACK 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 rebasejonatack commented at 8:54 pm on June 22, 2024: contributorjonatack closed this on Jun 27, 2024
github-metadata-mirror
This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-08 09:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me