Skip to content

bip-0379.mediawiki:formatting #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

bip-0379.mediawiki:formatting #1

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4d901a4
bip-0379.mediawiki:formatting
RandyMcMillan Jun 27, 2024
fdcc12c
bip-0379.mediawiki:mediawiki link formatting
RandyMcMillan Jun 27, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 25 additions & 23 deletions bip-0379.md → bip-0379.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -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.

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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,
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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.
Expand All @@ -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).
Expand All @@ -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
Expand All @@ -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.