<p>At a high level:</p>
<ul>
<li>The policy is <strong>compiled</strong> to Miniscript.</li>
<li>Miniscript is <strong>encoded</strong> to Bitcoin Script. (One to One Mapping)</li>
<li>Bitcoin Script is <strong>decoded</strong> back to Miniscript. (One to One Mapping)</li>
<li>Policy and Miniscript can <em>both</em> be <strong>lifted</strong> to another representation for static analysis.</li>
</ul>
<p>Following invariants are respected in Miniscript:<br />
Let <code>ms</code> be a miniscript, <code>s</code> be bitcoin script, <code>pol</code> be policy</p>
<ul>
<li><code>decode(encode(ms))</code> = <code>ms</code></li>
<li><code>encode(decode(s))</code> = <code>s</code></li>
<li><code>lift(pol)</code> = <code>lift(compile(pol))</code></li>
</ul>
<p>I am not going into the details of lifting as it not directly related to the question.</p>
<blockquote>
<p>When would I use policy language rather than Miniscript? What does policy language offer that Miniscript doesn't? What are the key differences between them?</p>
</blockquote>
<p>I think this is question is best answered by an example.</p>
<p>Writing an efficient Miniscript directly from spending conditions is not trivial. Policy language is a more natural way to write the spending conditions. Consider a Hashlock example from Bob to Alice, your requirements are</p>
<ul>
<li>Alice can spend the coins if they know a preimage for hash H</li>
<li>Funds are sent back to Bob after some time T, say 10 blocks</li>
</ul>
<p>This naturally translates to the following policy:
<code>or(and(sha256(H),pk(A)),and(older(10),pk(B)))</code>. Writing a Miniscript for this directly would be complicated and probably would turn out to inefficient. This is where the compiler can help you.</p>
<p>The compiler would then compile down to a Miniscript like the shown below.
<code>andor(c:pk(A),sha256(H),and_v(vc:pk(B),older(10)))</code> which has a one to one mapping to Script.</p>
<p>Note that it is non-trivial to directly write down this Miniscript and that it involves complicated fragments like <code>andor</code>.</p>
<p>The policy language additionally allows specifying the odds (by using <code>@</code> as shown below) for a <code>or</code> branch which can help the compiler produce vbyte efficient Script. In the above example, we expect the Hashlock to succeed with high probability and the timelock branch to be almost never taken. We can use the odds in the policy language as follows:</p>
<p><code>or(99@and(sha256(H),pk(A)),1@and(older(10),pk(B)))</code></p>
<p>which then compiles down to a different Miniscript (note that <code>pk(B)</code> changed to <code>pk_h(B)</code>)</p>
<p><code>andor(c:pk(A),sha256(H),and_v(vc:pk_h(B),older(10)))</code></p>

CC BY-SA 4.0
2019-11-08T17:22:23.287Z
2022-05-18T14:54:36.823Z
2022-05-18T14:54:36.823Z
sanket1729
<p>Miniscript doesn't compile down to script. It encodes a subset of all Bitcoin script. It is a (very crafty) template language which reduces the Bitcoin script language to specific script expressions which are composable, which means the properties of a miniscript expression only depend on the property of its children. Properties include malleability, satisfaction, non-satisfaction etc.</p>

<p><strong>Composability:</strong></p>

<ul>
<li>So for example, satisfying witness elements of <code>or_b(X,Y)</code> only depend on the satisfying elements of X and Y. The satisfaction of X and Y, in turn, only depend on their respective children ... until terminal expressions such as <code>pk()</code>/<code>pk_h()</code> are reached. Other properties are inheritable in the same way.</li>
<li>To determine the top-level properties of the miniscript, one simply needs to lift or "trickle up" the properties beginning form the terminal child expressions (leafs in our syntax tree). A safe top level expression should be of the <code>Base=B</code> type, which pushes zero or a nonzero value if the overall condition is satified, be satisfiable in a nonmalleable way (<code>m</code>) and require a signature (<code>s</code>).</li>
</ul>

<p><strong>Policy-to-Miniscript Compilation:</strong></p>

<ul>
<li>For a given policy, let's say <code>AND(PK_A, OR(PK_B,PK_C))</code>, there can be multiple miniscript solutions. Simply consider the multitude of miniscript expressions for AND/OR: <code>and_vbn</code>, <code>or_bdci</code>. </li>
<li>The compiler can iterate through miniscript expressions, to find one that has the lowest spending cost, and also be safe (<code>Bms</code>) on the top level. But different compilers may optimize for different things.</li>
<li>To answer your question: In that sense, Policy is a higher-level language than miniscript. Miniscript isn't a higher language than Bitcoin script, since it translates 1-to-1.</li>
<li>It is not possible to reason about script properties on the policy language level as it is with miniscript.</li>
</ul>

<p><strong>Static Analysis:</strong></p>

<ul>
<li>Given a Bitcoin script, it is now possible to parse it into miniscript (if it is indeed composed of miniscript expressions). Since miniscript is composable, we can "lift" all properties to the "top level" miniscript expression, and reason about properties of the resulting output script, which include satisfaction or malleability (Can I safely sign for this output, and how does the witness need to look like).</li>
</ul>

CC BY-SA 4.0
2019-11-08T16:09:40.110Z
Thanks James. I'm going to correct the question as you're right. Miniscript doesn't compile to Script. Ivy compiles to Script. I'm getting confused. http://diyhpl.us/wiki/transcripts/noded-podcast/2019-05-11-andrew-poelstra-miniscript/
Michael Folkson
CC BY-SA 4.0
2019-11-08T16:20:21.973Z
Hi Michael. I suppose policy only describes raw locking conditions. Miniscript is an implementation thereof for the script interpreter, in a way which allows one to be sure it is indeed a "safe" implementation. Your policy is not guaranteed to be safe (doesn't require a signature), for example. In that case, your policy-to-miniscript compiler should find no safe solutions.
James C.
CC BY-SA 4.0
2019-11-08T17:21:17.160Z
Hi @JamesC., I did research on Miniscript for a speech I gave and reading your answer I know understand that I got the Policy / Miniscript / Script sequence wrong. Thanks
Sosthène
CC BY-SA 4.0
2019-11-08T15:58:28.030Z
2019-11-08T15:58:28.030Z
James C.
<p>Both answers by James C. and sanket1729 are very good, but I wanted to give a very high-level answer:</p>
<p>Miniscript is an intermediate more structured <strong>representation</strong> for actual Bitcoin Scripts. It is useful as a toolbox because it simplifies static analysis of scripts, and things like generic signing.</p>
<p>The policy language is intended to simplify <strong>designing</strong> Scripts for humans.</p>
<p>The fact that Miniscript has a textual notation that looks similar to the policy language is probably confusing, but it is not primarily intended to be written by humans. The textual form exists to permit including Miniscript expressions inside output descriptors, and easily communicate them. To actually construct a Miniscript expression for a particular purpose, you'd generally use the policy language and compile it.</p>

CC BY-SA 4.0
2019-11-08T17:57:41.610Z
2022-05-18T14:48:21.817Z
2022-05-18T14:48:21.817Z
Pieter Wuille
<p>I understand that policy language compiles to Miniscript and Miniscript is encoded (correction) to Bitcoin Script. This is also a great resource on Miniscript: <a href="http://bitcoin.sipa.be/miniscript/" rel="nofollow noreferrer">http://bitcoin.sipa.be/miniscript/</a> But I know very little about policy language and there doesn't seem to be too many resources on it online.</p>
<p>When would I use policy language rather than Miniscript? What does policy language offer that Miniscript doesn't? What are the key differences between them?</p>
<p>Correction: As James points out below Miniscript does not compile to Script. Ivy is a smart contracting language that compiles to Script. <a href="http://diyhpl.us/wiki/transcripts/noded-podcast/2019-05-11-andrew-poelstra-miniscript/" rel="nofollow noreferrer">http://diyhpl.us/wiki/transcripts/noded-podcast/2019-05-11-andrew-poelstra-miniscript/</a></p>

<script><bitcoin-core-development><miniscript>
What does Bitcoin policy language offer the developer that Miniscript doesn't? What is the difference between Bitcoin policy language and Miniscript?
Michael Folkson
# What does Bitcoin policy language offer the developer that Miniscript doesn't? What is the difference between Bitcoin policy language and Miniscript?

(Asked by: username_0 on 2019-11-08)

I understand that policy language compiles to Miniscript and Miniscript is encoded (correction) to Bitcoin Script. This is also a great resource on Miniscript: <http://bitcoin.sipa.be/miniscript/> But I know very little about policy language and there doesn't seem to be too many resources on it online.

When would I use policy language rather than Miniscript? What does policy language offer that Miniscript doesn't? What are the key differences between them?

Correction: As username_2 points out below Miniscript does not compile to Script. Ivy is a smart contracting language that compiles to Script. <http://diyhpl.us/wiki/transcripts/noded-podcast/2019-05-11-andrew-poelstra-miniscript/>

**Tags:** script, bitcoin-core-development, miniscript


---

## 3 answers

### Answer by username_4 on 2019-11-08. Score: 15 | Accepted answer

Both answers by username_2 C. and username_1 are very good, but I wanted to give a very high-level answer:

Miniscript is an intermediate more structured **representation** for actual Bitcoin Scripts. It is useful as a toolbox because it simplifies static analysis of scripts, and things like generic signing.

The policy language is intended to simplify **designing** Scripts for humans.

The fact that Miniscript has a textual notation that looks similar to the policy language is probably confusing, but it is not primarily intended to be written by humans. The textual form exists to permit including Miniscript expressions inside output descriptors, and easily communicate them. To actually construct a Miniscript expression for a particular purpose, you'd generally use the policy language and compile it.


---

### Answer by username_1 on 2019-11-08. Score: 12

At a high level:

* The policy is **compiled** to Miniscript.
* Miniscript is **encoded** to Bitcoin Script. (One to One Mapping)
* Bitcoin Script is **decoded** back to Miniscript. (One to One Mapping)
* Policy and Miniscript can *both* be **lifted** to another representation for static analysis.

Following invariants are respected in Miniscript:  
Let `ms` be a miniscript, `s` be bitcoin script, `pol` be policy

* `decode(encode(ms))` = `ms`
* `encode(decode(s))` = `s`
* `lift(pol)` = `lift(compile(pol))`

I am not going into the details of lifting as it not directly related to the question.

> When would I use policy language rather than Miniscript? What does policy language offer that Miniscript doesn't? What are the key differences between them?

I think this is question is best answered by an example.

Writing an efficient Miniscript directly from spending conditions is not trivial. Policy language is a more natural way to write the spending conditions. Consider a Hashlock example from Bob to Alice, your requirements are

* Alice can spend the coins if they know a preimage for hash H
* Funds are sent back to Bob after some time T, say 10 blocks

This naturally translates to the following policy:
`or(and(sha256(H),pk(A)),and(older(10),pk(B)))`. Writing a Miniscript for this directly would be complicated and probably would turn out to inefficient. This is where the compiler can help you.

The compiler would then compile down to a Miniscript like the shown below.
`andor(c:pk(A),sha256(H),and_v(vc:pk(B),older(10)))` which has a one to one mapping to Script.

Note that it is non-trivial to directly write down this Miniscript and that it involves complicated fragments like `andor`.

The policy language additionally allows specifying the odds (by using `@` as shown below) for a `or` branch which can help the compiler produce vbyte efficient Script. In the above example, we expect the Hashlock to succeed with high probability and the timelock branch to be almost never taken. We can use the odds in the policy language as follows:

`or(99@and(sha256(H),pk(A)),1@and(older(10),pk(B)))`

which then compiles down to a different Miniscript (note that `pk(B)` changed to `pk_h(B)`)

`andor(c:pk(A),sha256(H),and_v(vc:pk_h(B),older(10)))`


---

### Answer by username_2 on 2019-11-08. Score: 11

Miniscript doesn't compile down to script. It encodes a subset of all Bitcoin script. It is a (very crafty) template language which reduces the Bitcoin script language to specific script expressions which are composable, which means the properties of a miniscript expression only depend on the property of its children. Properties include malleability, satisfaction, non-satisfaction etc.

**Composability:**

* So for example, satisfying witness elements of `or_b(X,Y)` only depend on the satisfying elements of X and Y. The satisfaction of X and Y, in turn, only depend on their respective children ... until terminal expressions such as `pk()`/`pk_h()` are reached. Other properties are inheritable in the same way.
* To determine the top-level properties of the miniscript, one simply needs to lift or "trickle up" the properties beginning form the terminal child expressions (leafs in our syntax tree). A safe top level expression should be of the `Base=B` type, which pushes zero or a nonzero value if the overall condition is satified, be satisfiable in a nonmalleable way (`m`) and require a signature (`s`).

**Policy-to-Miniscript Compilation:**

* For a given policy, let's say `AND(PK_A, OR(PK_B,PK_C))`, there can be multiple miniscript solutions. Simply consider the multitude of miniscript expressions for AND/OR: `and_vbn`, `or_bdci`.
* The compiler can iterate through miniscript expressions, to find one that has the lowest spending cost, and also be safe (`Bms`) on the top level. But different compilers may optimize for different things.
* To answer your question: In that sense, Policy is a higher-level language than miniscript. Miniscript isn't a higher language than Bitcoin script, since it translates 1-to-1.
* It is not possible to reason about script properties on the policy language level as it is with miniscript.

**Static Analysis:**

* Given a Bitcoin script, it is now possible to parse it into miniscript (if it is indeed composed of miniscript expressions). Since miniscript is composable, we can "lift" all properties to the "top level" miniscript expression, and reason about properties of the resulting output script, which include satisfaction or malleability (Can I safely sign for this output, and how does the witness need to look like).

> **Comments:**
> **username_0**: Thanks username_2. I'm going to correct the question as you're right. Miniscript doesn't compile to Script. Ivy compiles to Script. I'm getting confused. http://diyhpl.us/wiki/transcripts/noded-podcast/2019-05-11-andrew-poelstra-miniscript/  
> **username_2**: Hi username_0. I suppose policy only describes raw locking conditions. Miniscript is an implementation thereof for the script interpreter, in a way which allows one to be sure it is indeed a "safe" implementation. Your policy is not guaranteed to be safe (doesn't require a signature), for example. In that case, your policy-to-miniscript compiler should find no safe solutions.  
> **username_3**: Hi @JamesC., I did research on Miniscript for a speech I gave and reading your answer I know understand that I got the Policy / Miniscript / Script sequence wrong. Thanks  

---

