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 James 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/

3 Answers 3


Both answers by James C. and sanket1729 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.


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.


  • 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).
  • 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. diyhpl.us/wiki/transcripts/noded-podcast/… Commented Nov 8, 2019 at 16:09
  • 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.
    Commented Nov 8, 2019 at 16:20
  • 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
    – Sosthène
    Commented Nov 8, 2019 at 17:21

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:


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


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.