bip-0379.mediawiki:formatting

Author: RandyMcMillan

bip-0379.md renamed to bip-0379.mediawiki

@@ -15,16 +15,16 @@
   License: CC0-1.0
 </pre>
 
-## Abstract
+==Abstract==
 
 This document specifies Miniscript, a language for writing (a subset of) Bitcoin Scripts in a
 structured way, enabling analysis, composition, generic signing and more.
 
-## Copyright
+==Copyright==
 
 This document is licensed under the Creative Commons CC0 1.0 Universal license.
 
-## Motivation
+==Motivation==
 
 Bitcoin Script is an unusual stack-based language with many edge cases, designed for implementing
 spending conditions consisting of various combinations of signatures, hash locks, and time locks.
@@ -44,13 +44,13 @@ targeted by spending policy compilers. Finally, compatible scripts can easily be
 Miniscript form - avoiding the need for additional metadata for e.g. signing devices that support
 it.
 
-## Specification
+==Specification==
 
 These specifications apply to P2WSH ([BIP 141](bip-0141.mediawiki)) and Tapscript ([BIP 342](bip-0342.mediawiki)) scripts, with only minor
 variations between the two. Differences are noted inline. Unless explicitly stated otherwise,
 specifications apply to both. P2SH and bare scripts are excluded from this specification.
 
-### Translation Table
+===Translation Table===
 
 Miniscript consists of a set of script *fragments* which are designed to be safely and correctly composabe.
 
@@ -109,15 +109,15 @@ Miniscript is not a separate language, but rather a significant expansion of the
 |                                                          | `l:X` = `or_i(0,X)`           | `IF 0 ELSE [X] ENDIF`
 |                                                          | `u:X` = `or_i(X,0)`           | `IF [X] ELSE 0 ENDIF`
 
-### Type System
+===Type System===
 
 Not every Miniscript expression can be composed with every other. Some return their result by
 putting true or false on the stack; others can only abort or continue. Some require subexpressions
 that consume an exactly known number of arguments, while others need a subexpression that has a
 nonzero top stack element to satisfy. To model all these properties, we define a correctness type
 system for Miniscript.
 
-#### Correctness
+====Correctness====
 
 Every miniscript expression has one of four basic types: "**B**" (base), "**V**" (verify),
 "**K**" (key) and "**W**" (wrapped). Then there are 5 type modifiers that guarantee additional
@@ -156,7 +156,7 @@ 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
 
-#### Timelock Type Mixing
+====Timelock Type Mixing====
 
 There is one additional correctness property that Miniscript expressions must satisfy:
 the four timelock types (absolute time based, absolute height based, relative time based, and
@@ -169,7 +169,7 @@ timelocks to appear.
 For all other combinators, it is legal to mix timelock types. It is also always legal to
 mix absolute and relative timelocks (even if one is height based and the other is time based).
 
-#### Malleability
+====Malleability====
 
 Malleability is the ability for a third party (someone who does *not* hold a participating private
 key) to modify an existing satisfaction into another valid satisfaction. To analyze the
@@ -208,7 +208,7 @@ 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>
 
-### Satisfaction
+====Satisfaction====
 
 The following table shows all valid satisfactions and dissatisfactions for every Miniscript, using
 satisfactions and dissatisfactions of its subexpressions. Multiple possibilities are separated by
@@ -249,7 +249,7 @@ will contain *(empty)*.
 | `j:X`                        | 0; ~~[dsat(X) (if nonzero top stack)]~~                 | sat(X)
 | `n:X`                        | dsat(X)                                                 | sat(X)
 
-#### Non-malleable Satisfaction Algorithm
+====Non-malleable Satisfaction Algorithm====
 
 In order to produce non-malleable satisfactions we make use of a function that returns the optimal
 satisfaction and dissatisfaction for a given expression (if any exist), or a special DONTUSE ("don't use") value,
@@ -272,9 +272,9 @@ script but the result does not have the HASSIG flag, also fail. If the satisfact
 DONTUSE and HASSIG, return it.
 
 
-## Discussion
+==Discussion==
 
-## Security
+==Security==
 
 Miniscript primarily aims to provide guarantees on the correctness of a Bitcoin Script. That is, to
 guarantee **consensus soundness** and **standardness completeness**. Consensus soundness means
@@ -297,7 +297,7 @@ that scripts whose conditions can be met without any digital signature are insec
 trivially insecure, note how a transaction lacking a signature check allows an attacker to change
 its nLockTime and nSequence fields to meet additional timelock conditions.
 
-### Type System
+===Type System===
 
 To statically verify the correctness and malleability guarantees discussed in the previous section,
 we define a type system. See the specifications above for a reference of each fragment's
@@ -323,7 +323,7 @@ Finally to analyze malleability guarantees we introduce 3 new type modifiers:
 * "**e**" Expressive: this requires a unique unconditional dissatisfaction to exist, and forces all conditional dissatisfactions (if any) to require a signature.
 
 
-### Malleability
+===Malleability===
 
 Since Segwit, malleating a transaction no longer breaks the validity of unconfirmed descendant
 transactions. However, unintentional malleability may still have a number of much weaker undesirable
@@ -354,7 +354,7 @@ The malleability analysis makes the following assumptions:
 * We restrict this analysis to scripts where no public key is repeated. If signatures constructed for one part of the script can be bound to other checks in the same script, a variant of the mixing from the previous point becomes available that is equally hard to reason about. Furthermore this situation can be avoided by using separate keys.
 * The attacker is constrained by common standardness rules. A miner may be able to malleate a witness considered non-malleable by Miniscript.
 
-#### Non-Malleable Satisfaction
+====Non-Malleable Satisfaction====
 
 Malleable satisfactions or dissatisfactions appear whenever options are available to attackers distinct from the one taken by honest users. This can happen for multiple reasons:
 1. Two or more options for a satisfaction or dissatisfaction are listed in the table above which are both available to attackers directly. Regardless of which option is used in the honest solution, the attacker can change the solution to the other one.
@@ -380,7 +380,7 @@ satisfaction:
   * `thresh(k,...)` is always "d", a non-HASSIG dissatisfaction with just dissatisfactions must exist due to typing rules, and thus rules out usage of the other dissatisfactions. They are also overcomplete.
 
 
-### Resource Limits
+====Resource Limits====
 
 Various types of Bitcoin Scripts have different resource limitations, either through consensus or standardness. Some of them affect otherwise valid Miniscripts:
 * 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).
@@ -392,11 +392,11 @@ A static analysis can be performed on a Miniscript to verify if none, all or any
 paths hit any of the limits.
 
 
-## Test Vectors
+==Test Vectors==
 
 TBD
 
-## Backwards Compatibility
+==Backwards Compatibility==
 
 Miniscript's syntax is compatible with BIP 380 Output Script Descriptors, and should be considered
 an extension to it that provides a new type of Script expression that is only valid in
@@ -408,16 +408,18 @@ The `pk()`, `pkh()`, `multi()`, and `multi_a()`
 fragments overlap with existing descriptors. These parse to the same semantic meanings as those
 descriptors and produce the same scripts.
 
-## Reference Implementation
+==Reference Implementation==
 
 A first reference implementation and documentation for Miniscript in P2WSH was originally published at
 https://github.com/sipa/miniscript .
 
+[[bip-0381.mediawiki[381]]
+
 The reference implementation for Miniscript in P2WSH was introduced in Bitcoin Core through PRs
-[24147](https://github.com/bitcoin/bitcoin/pull/24147), [24148](https://github.com/bitcoin/bitcoin/pull/24148), and
-[24149](https://github.com/bitcoin/bitcoin/pull/24149). The last one to be merged was released in Bitcoin
+[[24147][https://github.com/bitcoin/bitcoin/pull/24147]], [[24148][https://github.com/bitcoin/bitcoin/pull/24148]], and
+[[24149][https://github.com/bitcoin/bitcoin/pull/24149]]. The last one to be merged was released in Bitcoin
 Core version 25.0.
 
 The reference implementation for Miniscript in Tapscript was introduced in Bitcoin Core in PR
-[27255](https://github.com/bitcoin/bitcoin/pull/27255). This PR was merged and released in Bitcoin Core
+[[27255][https://github.com/bitcoin/bitcoin/pull/27255]]. This PR was merged and released in Bitcoin Core
 version 26.0.