What does Bitcoin policy language offer the developer that Miniscript doesn't? What is the difference between Bitcoin policy language and Miniscript?

Question

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/

Answer 1

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.

Answer 2

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 3

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).