What's the purpose of the Simplicity jets for Miniscript translation?

[michaelfolkson]

In #107 some Simplicity jets are added for Miniscript translation. Is the (long term) aim to be able to convert Simplicity programs into Miniscript and vice versa when the Simplicity program has a direct mapping to Miniscript (i.e. only uses functionality in the subset of Script that Miniscript covers).

Why does that need to be a jet? I (perhaps mistakenly) thought jets were exclusively for adding functionality (hash functions, signature verifications etc) to the Simplicity language rather than facilitating conversions into other languages/encodings? Is the terminology "jet" just being used interchangeably with something like "module"?

[roconnor-blockstream]

We have a near term project to translate Miniscript to Simplicity (but not the other way). Since Simplicity is such a low-level language, Miniscript can serve as an entry point to generating Simplicity expressions for common policies or policy fragments. Miniscript extensions can then be built to generate Simplicity specific extensions unavailable in Bitcoin Script. Even without using extensions, the generated Simplicity programs are still slightly more powerful as the generated "CheckSig" operations in Simplicity will give access to Simplicity's programmable sighash modes (although further development will be needed to generate witness data taking full advantage of these programmable sighash modes).

There may be a misunderstanding of the purpose of #107: To be clear, no jets are being designed to specifically support this Miniscript translation. This PR merely prioritizes the implementation of jets already slated for implementation in order to support the Miniscript translation. In particular the PR is adding jets for things like, comparing two 256-bit strings for equality, and implementing the less-than-or-equal jet for 32-bit unsigned integers, etc, all of which were eventually going to be implemented anyways.

[ProofOfKeags]

This also solves one of the issues people might have about using Simplicity: "If I'm doing something Bitcoin Script can do on its own, why should I use Simplicity at all, isn't it slower?". Well if all Bitcoin Script operations are jetted out, it can be said that Simplicity pareto dominates Script. Any programs that can be implemented with Bitcoin Script operations can be implemented cheaply with a Simplicity that supports these jets and anything that can't can use Simplicity's much more powerful computational model to get you the rest of the way. This makes Simplicity a much more attractive "standard" to target.

[roconnor-blockstream]

Additionally we should note that Simplicity is implemented as a new Tapleaf version and different Tapleaf versions can be mixed inside a Taproot. This allows one address to contain a (disjunctive) mixture of Simplicity and Script. I think Script will end up being slightly more concise and hence lower weight to use for policies that it is capable of expressing, so it is likely sensible to mix them together.

[apoelstra]

Well if all Bitcoin Script operations are jetted out, it can be said that Simplicity pareto dominates Script.

Almost. Even with jetting, if you have a Script without branches (which may be pretty common in Taproot scenarios where the branching happens below the level of scripts) I'd expect that Script would still be a bit smaller than the equivalent Simplicity and therefore cheaper. As soon as you have branches, Simplicity's pruning should mean that you can actually beat Script.

[michaelfolkson]

@apoelstra: Sorry, I need some (closer to) ELI5 explanations on some of these phrases. Not sure if this is the best place but I'll continue for now.

Script without branches (Taproot)

You mean a script hashed at the root of the Taproot tree and no leaves below it here? How does branching happen below the level of a root script? You can't have a script embedded in the root of the tree if there are also scripts in (Tap)leaves of the tree?

Simplicity's pruning

The Taproot Merkle tree of scripts is arranged like Tapleaf A OR Tapleaf B OR Tapleaf C OR Tapleaf D etc. Simplicity is/will be a Tapleaf version. How will pruning happen in the Taproot Merkle tree? Taproot doesn't allow you to pick part of Tapleaf A and part of Tapleaf B and satisfy a combination of those parts. So doesn't the full Simplicity program need to be in a particular Tapleaf even if there is redundancy (part of the program in one Tapleaf is the same as part of the program in another Tapleaf)? A Simplicity of ORs can obviously fit into the Tapleaf A OR Tapleaf B OR Tapleaf C.... structure.

[roconnor-blockstream]

"Script without branches" refers to a Bitcoin Script program that doesn't have any OP_IF statements.

Simplicity programs themselves also form a Merkle Tree of sub-expressions. Simplicity has a rule that requires unexecuted branches within Simplicity programs to be pruned and not appear on the blockchain (replaced by the pruned expression's Merkle root). In Simplicity we refer to this as pruning.