Slides: https://docsend.com/view/svs27jr

Blockstream blog post on the Jets release: https://medium.com/blockstream/simplicity-jets-release-803db10fd589

Simplicity GitHub repo: https://github.com/elementsproject/simplicity

Asciinema video used in the presentation: https://asciinema.org/a/rhIsJBixoB3k8yuFQQr2UGAQN

Join the Simplicity mailing list here: https://lists.ozlabs.org/listinfo/simplicity

I am going to describe Simplicity which we made an announcement recently. It is a next generation script language for Bitcoin and Bitcoin-like networks which include Elements and Liquid. It is primarily the work of Russell O’Connor but Andrew Poelstra has been helping also since Fall of last year where we made a previous release. Greg Maxwell has also been testing as well.

Recalling Bitcoin scripts are predicates for spending coins. Your role is as the person who owns a coin and wishes to spend it is cause the small program to return TRUE and then you can spend it. Simplicity is actually an elaboration of a idea described in some IRC discussions as many Bitcoin ideas date back to from January 2012 talking about MAST. It turns out that more people are aware of MAST than Simplicity. The concept for MAST was at that point already with the Simplicity design with mind. It is a fresh look at Script design and a focus on provable security. Russell has a PhD on the topic of formal security for programming and formal proof systems to assist in making verifiable software. Russell has been working on this full time for almost four years ago, since May 2016. Andrew and Greg have been working on it more recently. We made a developer preview release last August and the Simplicity Jets release which we are going to describe now. One new artifact of Simplicity this release is jets which we will describe shortly. This release also works on a Bitcoin branch as well as an Elements branch. Elements is the open source platform which is based on the Bitcoin codebase with lots of extensions for confidential transitions, federated signing, asset issuance and so forth. The Liquid sidechain which involves about 50 different exchanges and so forth at this point is implemented using Elements. That is a bit of history about the context. Simplicity relates to Bitcoin and this release both a Bitcoin branch and an Elements branch.

Why is it interesting to think about Simplicity? Bitcoin scripts are constrained and security focused but they have expressiveness limitations. What Simplicity tries to do is to make a replacement next generation Bitcoin script system which is fully general. You can program generally arbitrary scripts and programs. It introduces introspection so you can look at the context. Bitcoin Script today doesn’t have introspection generally. Simplicity is very low level. It is a functional Assembly language. It is best to think of it as almost below Assembly language that you would have on a CPU. Because it is operation on bits and simple types and builds up simple operations from those. We will show a few examples in a minute. The point about having these very low level operators is that the semantics are formally specified. It is a very small core language. There are only nine operators and some basic types. A point about having formal semantics is that everything is fully defined. We can then use that as an input to prove things about the Script behavior in all conditions. Normally when you are writing software you test it in all the ways you can imagine using it. If you try to fuzz test it, try random things to see how well it performs. With a formal proof system you can prove things about how the scripts will behave in all possible conditions. You can make statements about how it will behave and then prove that is always the case. One thing to bear in mind about Bitcoin scripts is that they are verification and not execution. Technically when you cause a script to return true you are not exactly executing a program. You are showing evidence that can be verified that you were able to execute it yourself. But the evidence you provide doesn’t necessarily have to be executed by the verifier. In particular with the MAST concept if there are multiple OR branches you won’t execute ones that are not involved in being able to spend the coins. You may not even disclose some of the script if you don’t need to rely on that OR branch. Simplicity relies on this heavily. The top level Simplicity program is a kind of commitment, a hash of a tree of program snippets and the branches of the tree are connected by OR statements. You are going to navigate down the tree and pick one that you can cause to return TRUE and then reveal only that branch to the blockchain. Then the blockchain will verify what you claim and not necessarily see or need to know the rest of the program. Technically Simplicity is not Turing complete. This is intentional. There is a concept called Post’s Theorem which shows that you do not lose expressive power because you are not executing programs. You are proving that they are able to return TRUE. So contrary to some people’s assumption you do not lose expressive power by not having Turing completeness because these are not executed programs, they are proofs of the ability to cause a function to return TRUE.

Q - What is the most recent branch for Elements with Simplicity jets integrated?

Russell O’Connor: Master has SHA256 jets

Some more about what Simplicity is. It has access to an array of intrinsic functions. As I described the very lowest level is Assembly language bit level machine. But from that are built a number of higher level intrinsic functions. Things that would be inside the Bitcoin library or Bitcoin full node, lots of different functions. All of those can eventually be made available as jets. A jet is a… think of it like an intrinsic function. If you implement things at the very low level they will tend to be large and a bit slower because they are interpreted. For something that may be executed frequently you might make a C implementation and make a soft fork that replaces the Simplicity implementation with the C implementation. You can then prove things about it. You can prove that the C implementation is equivalent to the Simplicity implementation and with the Simplicity implementation you can prove its correctness and prove invariance about its behavior. Simplicity uses the MAST model. You are only revealing the branch that you are using and you don’t need to reveal branches that you are not using. This is a bit like Taproot. Taproot adds a one branch top level and then the BIPs that go with Schnorr and Taproot also include MAST. But that is in the context of existing Bitcoin Script. This is MAST in a Simplicity model. With the release that we did a few days ago we include both an Elements branch and a Bitcoin branch showing how Simplicity could in the future be added to Bitcoin if there was ecosystem interest after people get to grips with it, understand the security properties of it and so forth.

Now we are going to go to some things about the operators and type system. Technically there is not even a boolean type. There is a unit type. A unit type is a type that only has one value. If you think of a boolean as something that holds a value zero or one. A unit type is something that just holds one value, like TRUE. It is a very low level basic thing. Then you have a composition, the top right that lets you compose two functions. A function s with input A and output B. Another function t with input B and output C. You can compose those two functions s, t so that you give it A it calls the functions in turn and gives you the output. There is an inject left (injl) and inject right (injr) which are a way of composing types into tuples. There is a case statement which is a kind of switch construct. And a pair which is a kind of product. To combine two types into a tuple with both of them in there. The bottom two (taket and dropt) are from a tuple take the left part or drop take the right part. Those are like car and cdr if you are familiar with Lisp. Using just the operators on this page you can actually implement everything in a CPU starting with a one bit adder if statement and building up to a 32 bit adder and so forth.

Q - Simplicity isn’t Turing complete but it can verify the execution of something that is Turing complete? I don’t understand that.

Russell O’Connor: Michael, loosely speaking, if you provide a trace of the execution of a “Turing Machine” you can verify that trace without needing a Turing complete language.

Bob McElrath: You don’t need Turing completeness. In other words the Halting Problem is removed and all loops are unrolled. Any reasonable program/logic can be performed in this model.

This next slide is showing the semantics. If you understand the syntax it tells you the semantics. The identity function just returns its argument. The unit function returns a constant single value. Inject left and inject right are returning the left part of the tuple or the right part of the tuple. The case statement is returning the left part of an expression or the right part of an expression depending on the types of the inputs. pair is returning both function calls with the same argument. take and drop I described earlier. You can see that it has some kind of low level typing.

The Simplicity interpreter is operating on bit strings using these operators. There is an interpreter that can execute this. Here is a Lisp like syntax showing a half-adder. A half-adder is going to add two booleans. It can have a carry output so you can see using a Lisp like syntax that you’ve defined one of those. This is the Simplicity binary for the half-adder. You can see it has got a machine code level. The machine code is a canonicalized representation of the Abstract Syntax Tree of the program. Here it is in diagrammatic form. Bear in mind this is a one bit adder. Here is 8-bit adder so you can see that the DAG gets larger but nevertheless it is the same principle. You can notice that there is reuse going on here. Even though there is no looping you can have a log scale reuse of snippets of code. If a section of code is repeated it can just be reused without serializing it twice. An 8-bit adder is made up of a 2-bit adder and a 4-bit adder and so forth. You can see the structure in there. This is very small so you can’t read it but this is the representation of a SHA256 compression function which includes everything including 32 bit addition and shift and all of the other operators that go into that, bit level things.

Q - haskell-ffi-jets-secp256k1 returns no results on Google. Can I have a link for that?

Russell O’Connor: github.com/ElementsProject/simplicity/tree/haskell-ffi-jets-secp256k1

To give a bit of intuition how Simplicity programs look at the lowest level. I wouldn’t say a Simplicity program is compiled, it is more assembled into a Simplicity tree. The reason we say that is because it is very simple. It doesn’t involve any of the complexity you would normally think about in terms of a compiler which is doing clever optimizations of things. It is a straightforward process. In terms of the binary format, what does a Simplicity binary look like? It is a serialization of the abstract syntax tree. When the binary is loaded into the interpreter it reads the serialization and reconstructs the syntax tree. The execution proceeds by navigating the syntax tree using the inputs of the program. The Simplicity interpreter is called a Bit Machine. It is an abstract machine with an execution model which is convenient for executing the Simplicity program based on its tree structure. All the operators are executed using two implicit stacks. Implicit in the sense that you don’t get to access them and program with them but they are used internally to navigate evaluating a Simplicity function or program. There is a read and write stack. The elements on the stack are variable sized bit strings because you are composing larger and variable sized types using the type operators I showed. You can think of it like tuples of bits that have some type semantics. The Bit Machine executes this binary syntax tree. The binary syntax tree is loaded into memory and then it is evaluated. The interpreter is able to then evaluate those operators, process them while navigating the syntax tree and end up returning TRUE or FALSE for the context of an output like a Bitcoin or a Liquid asset that you are trying to spend. Slide 12 here is trying to explain Simplicity more in the terminology that people would be familiar with from compilers and Assembly programming and interpreters and so forth.

Q - I can’t find any Simplicity related commits in Elements. I tried github.com/ElementsProject/elements/commits?author=roconnor-blockstream Could I also have a link for the PR merging Simplicity jets into master please?

Russell O’Connor: Janus, github.com/ElementsProject/simplicity/pull/40 is where SHA256 was merged.

Now we are taking a step into the more specialized area which is about formal correctness and tools and languages people use to describe systems with formal correctness and prove things are formally correct. Simplicity has a formal specification in a proof assistant language for Coq. It is a general purpose proof assistant. Russell has built three different Bit Machine implementations, three different interpreters for Simplicity, one written in Coq, one written in Haskell and one written in C. The Coq implementation has been formally verified. I put this in bold because it is a very interesting and strong claim that most language interpreters don’t have. That is that the interpreter is formally verified to correctly execute all possible Simplicity programs. That is a pretty interesting claim. There is a path to proving security of C implementations of jets and of the interpreter itself using the verifiable C project. It is kind of indirect. We have this proof I mentioned above about the generic correctness of the Coq implementation. Then to prove the C implementation is correct you use the verifiable C platform and prove that the C implementation behaves in exactly the same way in all circumstances as the Coq implementation. Because of that transitively you end up with a proof that the C implementation will correctly execute all Simplicity programs. We can also prove other interesting constraints and behaviors about Simplicity programs. We can prove that it never overflows any safety bounds like array bounds. We can prove how much maximum memory it can consume when evaluating a given Simplicity program.

Q - Can you elaborate how this can be used with Bitcoin? Is it regtest only or can Simplicity scripts be used on mainnet/testnet?

Russell O’Connor: Bob currently we have a custom fork of Bitcoin Core which is suitable for running regtest though I suppose there is no reason you couldn’t start your own testnet.

What does this provide in the context of Bitcoin or Elements or Bitcoin like blockchains? One thing it allows you to do is implement new functionality, even low level functionality without needing a soft fork necessarily. The Schnorr digital signature algorithm which there is a BIP for now. If Bitcoin had Simplicity today you would be able to implement Schnorr in Simplicity itself without needing a soft fork. It shows the generality of Simplicity in terms of its expressiveness. Other examples include there is a particular soft fork extension which would be available for Lightning called SIGHASH_NOINPUT or alternatives. That would also at some point need a soft fork for Bitcoin for Lightning to work more efficiently, the eltoo version of Lightning. If Bitcoin had Simplicity today you could implement NOINPUT directly inline. You wouldn’t need a soft fork. If you do that the program size is surprisingly compact. The example I showed of the SHA256 is only a small amount of kilobytes but to get things smaller we execute things as jets. Then there will be C implementations of common functions and that means that something like SIGHASH_NOINPUT with access to a common library of jets ie C implementations and provable equivalents to the Simplicity implementations with the same functionality. We can implement quite compactly a range of things directly without needing to soft fork. The generality means you can build a lot of different things. To give some concrete examples that people have discussed as interesting and nice to have Bitcoin functionality. The timelock vault feature where you would instead of storing Bitcoin on a simple UTXO where it can be spent if you have access to the private key, with the vault you have access to a private key but it is restricted in what it can do. It can only initially give notice that it intends to spend a coin after a time delay. Let’s say after a week. During the notice period that can be cancelled. It gives you some protection because if the private keys are compromised or stolen from a safe or something like that someone can notice that and cancel if it is not authorized. You can also build velocity limits directly into the storage scheme so that you don’t have to have a distinction between a hot and a cold wallet and rebalancing. In Liquid there is something called a Liquid swap tool which is a way to trustlessly do an atomic swap of let’s say 1 Bitcoin for the current price of Bitcoin in US dollars using a stablecoin like Tether. Using today’s Liquid script which is essentially Bitcoin Script plus a few extra opcodes it is a little difficult to do more than a full match. You have to sell a whole Bitcoin. If somebody wants to buy half a Bitcoin they wouldn’t be able to do that without somebody providing the extra liquidity. With Simplicity and its expressiveness you could do a partial match as well. You could use a covenant like construction to do a partial match and be authorized to create a new transaction that has the same offer with the remainder of the transaction that is offered for sale. You can do things with the ability to prove things about their behavior, constraints or things they will do in all circumstances or the only way that this can be spent is if this claim is true.

Q - How are fees calculated for jets? With simple operations there are likely linear correspondence between revealed script size and the computing load but each jet has to have its own price it seems.

Russell O’Connor: Dmitry, fees aren’t done yet but I plan to run static analysis of the program to determine any excess weight needed to compensate for the program execution.

Q - Would Schnorr as a jet be a 256 bit hash?

Russell O’Connor: Ruben, in the Simplicity binary, Schnorr as a jet is a single node in the DAG occupying a handful of bits. Jets are “well known” so they have a concise binary representation.

Here is some data about the jets that are in this release. There are more jets coming. There is a SHA256 compression function and a verifiable C proof that it is correct and the Simplicity version is equivalent to the C version. There are jets for 32 bit arithmetic and there is a jet for the Schnorr signature which includes all the elliptic curve library aspects that verify a Schnorr signature that is similar to an ECDSA signature. In particular what does that do? If we compare Simplicity without jets. In a previous release we did a version of Schnorr in pure Simplicity and that took 11.5 minutes to execute and was 13.6 kB big. That sounds large but it is actually quite impressive because it included from the bit level up including the SHA256 implementation, a Big Number library, 32 bit arithmetic, an elliptic curve library and all the serialization to serialize a transaction and hash it so it can be verified. If you compare that to an ECDSA boiler plate to make a ECDSA signature is 25 bytes. With the release that we did this week Schnorr in Simplicity with jets is 448 bytes. You might wonder why it is bigger. The reason that it is bigger is what is jetted is the Schnorr crypto operation but not the serialization so most of those 448 bytes are to do with serializing the transaction and satisfying the Schnorr mathematical relation plus the public key and the raw signature. With more jets of the serialization the size would be the same as ECDSA. Already you can see that the performance in evaluation time is much closer so it is slower but that is primarily because of micro-optimization and because of the interpreted serialization.

Q - Can you elaborate how this can be used with Bitcoin? Is it regtest only or can Simplicity scripts be used on mainnet/testnet?

Adam Back: Yes it is regtest only. There is some limitation where the full version would probably use a different script version number and maybe move across to Taproot because Taproot has a more flexible versioning system than SegWit which it is using today.

Q - In the case of Simplicity being enabled on Bitcoin does it provide any assurances or guidance to a user using the equivalent of NOINPUT? (arguments against NOINPUT being soft forked in seem to revolve around it being dangerous)

Adam Back: This is a kind of power versus risk question from Michael. I think the point is that you can think about a couple of different levels of Simplicity. One level is very low level programming which is arguably best used by system library writers. Somebody who understands the internals to build something that is safe and then have people use that. It is possible to write unsafe Bitcoin scripts today where by accident they can be spent with OP_TRUE or something. This kind of risk remains. You do have to be careful. With great power comes great responsibility. You have to be careful that the script template you are using has been verified and understood by people that understand the internals quite well. One of the controls today is that the soft forks have been designed to minimize risk or to provide warnings and things. This is a level below. In practice you would have validated intrinsics on library level things. People would need to be careful on what they put money into but your existing wallet wouldn’t output a script that it doesn’t design. One gate is that wallet authors would have to form an opinion about a script. In the example of NOINPUT that is primarily of interest to Lightning. People with low level knowledge of Bitcoin and Lightning would have a discussion about the best semantics for NOINPUT and then implement it and use it in a Lightning spec and then people could start adopting it.

Q - It seems that if you have a special fee cost for jets you will need to analyze all the scripts in the transaction witnesses vs just checking witness size. It seems that there will need to be some way to pre-indicate how much extra costs will the jets in Simplicity script consume.

Adam Back: There are some things we are going to talk about in a bit about fees. There does need to be more thought put into the fee model for Simplicity scripts. With jets they get implemented as a soft fork so it becomes possible to have a cheaper lower byte count, lower CPU overhead way to do the same thing. Where if you were to do it as a Simplicity program it would have a larger cost. Part of soft forking in a jet would be evaluating what a sensible and safe fee cost for it should be.

Russell O’Connor: Dmitry, yes, such an analysis would be part of the consensus logic and deterministic. However, the Taproot annex might be used to denote the extra weight in a standard, compressed way.

We previously described the space saving and runtime aspects here. I think the point is that the runtime performance is quite good. If you are writing very low level things you might need to jet them. If you are writing general application things you may not need to jet them, you could just use them because interpreting a small program with extensive use of jet intrinsic functions is pretty compact and will be interpreted fast enough. That gives you the kind of ability to do things more rapidly without waiting for standardization of a soft fork. There are more details to work out but in principle it would also be possible to do something which is a little bit like a jet but without a C implementation. Bear in mind when you are calling a Simplicity program the program is inlined. Not all of it is necessarily revealed but the hash of the program is attached to a Bitcoin or an asset and then when you spend it you are revealing some branches of the program and some inputs to make it return true. If that is a small program and it is frequently used you could potentially save it, pay a cost for a special type of UTXO which is the macro of that program and then save on a network level and storage level the sum of the overhead. But you would not be able to change the fee cost because that is difficult to do without a soft fork and a new opcode. It would be a network and decompression option for frequently used small programs. That could be explored also. Now another question is what is needed for Simplicity on Liquid. As you see in this release there is Simplicity for Elements. Elements is the underlying toolkit that Liquid is built with. Some people have run other blockchains using Elements. You can run your own blockchain. This Elements is a kind of precursor. We will improve it. That will become the basis for adding Simplicity to Liquid which we are targeting for later this year. What is needed for that? One thing that I mentioned is Taproot. Taproot has a more flexible update and version system than SegWit. We are intending to integrate Taproot into Elements and Liquid possibly ahead of it being in Bitcoin depending on the timing. Then adapt Simplicity to work with the Taproot script version. We have also got to implement the cost model to take account of jets. This is the question about fees in jets and how that works. There are some more completeness things. The core of Simplicity is complete in terms of the interpreter functionality, the ability to evaluate things. But there are some things that are missing. Resource estimates of the execution time and memory of features. Some anti denial of service improvements. There is a binary format but we may want to finalize that we are going to commit to keeping binary compatibility with. A lot more jets and proofs of equivalence to Simplicity programs of the Simplicity version of the jets. So more proofs, more jets so that there is a wide library of jets composed of common things that are used at the next level down inside a Bitcoin full node. There are a lot of helper functions in the codebase that would be convenient to gain access to to write Simplicity programs in a compact way. Another big area is developer tooling. We are going to show some command line demo of the current release on Bitcoin that Russell put together and explain what is going on there. The developer tooling is missing or very basic at this point. It is more like machine code than like Assembly programming. One direction that we are interested in is to extend Miniscript. Miniscript is a layer above today’s Bitcoin Script that expresses them in more logic based grammar instead of the stack machine of looking at raw Bitcoin scripts. Miniscript is both compilable and decompilable. So you can express your intended behavior and then compile it into Bitcoin Script. You can decompile a Bitcoin script and have it explained in Miniscript language. There are two languages involved. Miniscript is a separate project. You can use that today on Bitcoin, you can go look that up. We are intending to extend Miniscript to add some Simplicity enabled functionality. We will pick some subset hopefully with powerful and useful properties. Extend Miniscript with that and with that extended Miniscript you would be able to compile that down into Simplicity and have the Simplicity assembled into a Bit Machine binary. Then we need more developer tools and more documentation.

At this point I will switch to Russell’s demo. This is a recording using an ascii thing of Russell showing some of the command line things you can do. I will try to explain it. Basically it is using the Simplicity package for Haskell. He has started up the Haskell toolkit and interpreter, loading the Simplicity package. Here you can see he is calling a Bitcoin raw transaction. The ! syntax calling a shell script, like a command line from within a Haskell interpreter. So this is the Bitcoin transaction and the hash at the end there is a P2SH of a Simplicity script. This is what I was mentioning with Bob McElrath’s question that -1 is the SegWit version. We are going to switch it to use the Taproot version when we get to integrate Taproot into Elements and Liquid. If it was integrated into Bitcoin, of course Bitcoin is a moving target but that seems like a better way to do things for Bitcoin purposes as well. The program is a sighash and Russell is now typing helper function in Haskell to show things. There is a function that serializes a Simplicity expression into a binary format. Basically he is showing you internals of some Haskell library and manually constructing Simplicity binaries. This is where there is a comment in the Medium post that this is a very low level manually crafted script. He is crafting it using the Simplicity package for Haskell. The signature above he computed somewhere else in Sage which is mathematical package that understands elliptic curves. He made the elliptic curve signature, cut and paste the hex in and there he made a Simplicity binary. Then we are going to parse the binary, show that we can decompile and show things about it. He is going to show some hex of the parsed binary. There you see the commitment which is the top level of the Simplicity binary’s path tree or MAST. Then he is going to save the binary to a file so he can create a transaction with it and so forth. Obviously what needs to happen above this is more easily to use RPC commands and command line tools and all that kind of thing. This is the next level down. We need more developer tools. There is a decompilation, the hex of that. The last bytes are the witness and the signature. Now he is going to try to spend it. Because it is P2SH like you have to provide the script as part of the script signature. The witness that we sent in includes the whole Simplicity binary or the section of it if it has OR branches that we need in order to spend it. Now he is going to disassemble it to show that the binary can be parsed into its component parts and show something about what it looks like symbolically. It is going to give you a text representation of the opcodes that we showed at the beginning, organized in a tree structure. This is a printer that he just typed, a very simple one. Then we will see in a second the disassembly. Here you see all of the Simplicity combinators. There are 196 starting at zero. These are all the little bit level and bit string operations. You can see some jets in there. There is a SHA256 compression jet which is taking a bit string off the stack and doing a compression round. Also the Schnorr verification jet. The Simplicity program is reading the transaction data, hashing it and then verifying it using the Schnorr signature. That’s another section of disassembly. He thinks that’s the public key. This program is 448 bytes but it will become much smaller converging on a similar size to Bitcoin ECDSA template which is 25 bytes as more of it is jetted. As I was saying the part that is large at the moment is the serialization and all the calls to the low level operations to construct the data, serialize it together, hash it and then finally call the Schnorr verification jet.

In terms of what comes next we are continuing development on Elements. The initial developer preview was last September. The Simplicity release with jets that we’re discussing in this presentation, we’re targeting availability of this in Liquid late this year. There is a lot to do. As you can see from the availability of a Bitcoin branch that Simplicity is compatible with Bitcoin. It was actually designed long before Elements and even sidechains as a concept back in 2012. But in active development since 2016, almost four years now. The idea is that we can prove things out in Liquid, add it to Elements, add it to Liquid, allow people to try it out in that context. If you are very familiar with low level intrinsics you might be able to do things with the current regtest release. If you ask questions on the Elements IRC or Bitcoin Core Slack. The idea is that later it would become an interesting candidate BIP for Bitcoin. Bear in mind this is a few years down the road. There are lots of technical questions that have to be validated about how to do this safely in practice. There are some precedents for things being tried in a sidechain before. For example the precursor to SegWit was tried in an early version of Elements. There was a previous version of Schnorr in an early version of Elements and there’s been preview versions of things in a sidechain two to four years before they’ve come into Bitcoin historically. We’ll have to see. Obviously Simplicity is a pretty large and complex change. But there may be sandbox or container concepts that could be put around it to improve the safety. That’s the end of the slide presentation.

Q - If you can use Miniscript (you only need a subset of Script) you should use Miniscript rather than Simplicity right? Just because it is more mature or any other reasons?

Adam Back: The reason is that it is a higher level language. If you think about writing something in Assembly language versus writing something in Python or something like that. Miniscript is a way to state things intentionally. It is much higher level but it doesn’t give you access to the full expressiveness in the case of Simplicity. We would add more functionality over time and grow Miniscript a high level language with an intentional way to express Script programs and constraints. We’ll have to see how far that can go. Maybe there is room for other high level languages that can also compile into Simplicity. Certainly you could compile today’s Miniscript into Simplicity because that can be compiled into Bitcoin Script already. But the interesting thing is what new functionality? Could we add covenants to Miniscript? How do you express covenants in an intentional way. There are lots of questions about how you would do things. We just start and build up from there.

Q - Is a higher level language like Ivy on the Liquid roadmap too?

Russell O’Connor: Technically we can release Simplicity on Liquid independently of constructing or deploying a higher level language for it.

Adam Back: Yes that is certainly an interesting thing to have compile into Simplicity. Maybe Ivy itself could be expanded on and compiled down to Simplicity. There’s room for multiple languages to compile down to it basically. It is a functional language with access to lots of intrinsics.

Q - Are there plans for tooling to work with multi-transaction covenants?

Adam Back: I think you could safely typify Simplicity as a bottom up approach to the world. Bitcoin itself I think personally is bottom up. There’s robust things that work and build upwards from there. I think you would want to start with a covenant mechanism and then some safe way to bind multi-transactions together. There has been thought in the past to having intentional high level toolkits to compile protocol descriptions like the Lightning protocol into a language and then down into an interpreted language. Conceivably but that is a couple of levels of high level language design removed. It is possible but it is something that would need work and could be pretty interesting. It could speed up the time from protocol ideas into availability. I think the other interesting thing would be to preserve the security guarantees and the semantic analysis for these multi-transactions so that you can make statements about how they will behave in all circumstances.

As Daniel mentioned we will upload the video and the cast file. The other materials are online. The other references are available. I guess we will wrap up there. I hope it gave a flavor for how Simplicity works. For ongoing Q&A the Bitcoin Core Slack with #elements or there is an IRC channel that it is equivalent to as well. Those are probably the best place. There is also a tech discussion chat on Core Slack that Russell is in sometimes. Thank you.