Unlock Bitcoin for more apps, Miniscript yesterday, today and tomorrow!

Translator's Foreword: Due to the existence of Bitcoin scripts, today, Bitcoin can implement simple trading functions and various multi-signatures, atomic swaps, and lightning network transactions. However, the functions of scripts are not only these, but the complexity. However, it limits the possibilities of more applications, and Miniscript is proposed to make Bitcoin scripts more accessible and eventually unlock more Bitcoin applications.

In this regard, Pieter Wuille and Andrew Poelstra wrote a " Miniscript: Streamlined Bitcoin Scripting " to explain the origin and role of Miniscript, and its future direction.

The following is a translation:

Miniscript

(Image from blockstream)

Introduction to Bitcoin scripts

Bitcoin has always had a mechanism for making money available through more complex strategies (rather than just a single key): this is the script system. Although scripts are primarily used for single-key payments, they are also the basis for a variety of multi-signature wallets, atomic interchange structures, and lightning networks.

However, these are not all that the script can do. Scripts can be used to represent the complex conditions required to publish a transaction, such as (two of A, B, C) and (D or (E and F)), where AF represents a unique key, and a hash original Checks, timelocks, and some more exotic constructs.

Bitcoin script problem: difficult to verify

But one of the reasons we can't take full advantage of the potential of Bitcoin scripts is that it's cumbersome to build scripts for complex tasks: it's hard to verify their correctness and security, and it's even hard to find the most economical way to write them.

This is part of the problem: even if you know the right scripts, design applications, and protocols to negotiate and construct transactions, each time you design a new construct, you need a lot of extra development work. Each time you add, you need more engineering resources to meet your analysis and quality assurance.

So what would happen if a Bitcoin application could use any script, not just a few scripts? We will no longer be limited to using one-off designs, and we can begin to design applications based on user-specified needs. Wallet developers can also introduce more script-based options while maintaining interoperability with other wallets.

What is Miniscript?

Enter the world of Miniscript, a language that represents Bitcoin scripts in a structured way, supporting efficient analysis, composition, and general signatures.

An example of a bitcoin script:

OP_CHECKSIG OP_IFDUP OP_NOTIF OP_DUP OP_HASH160 <hash160(B)> OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_CSV OP_ENDIF

Where A and B represent the public key, and the representation converted to Miniscript is:

 or_d(c:pk(A),and_v(vc:pk_h(B),older(144)))

This example clearly shows that the semantics of the script allows for payment to be made when the B signature after the A signature or 144 blocks occur. Most of the meaningful scripts can be written this way.

Making the script readable is just one of the features of Miniscript. Its main purpose is to implement automated reasoning of the script, as shown in the application example below.

Miniscript application

Currently, if we use bitcoin scripts to build complex spending conditions, it is very difficult to do so, which requires developing, testing, and deploying special-purpose software for each new use case. Miniscript can cover these conditions in a way that spans any set of spending conditions and is usually much simpler and more reliable than a dedicated solution.

Application 1, optimization script

An example of this is finding the best script to implement a given set of spending conditions.

In Bitcoin scripts, there are many different ways to sign, describe connections or detach, or implement a threshold. Even for experienced Bitcoin script developers, the right choice may depend on the relative probability of meeting different conditions and is difficult to calculate. And our online compiler , which instantly finds the best Miniscript for a given spending strategy.

The examples in the introduction can be obtained by the following compilation strategy:

 or(99@pk(A),1@and(pk(B),older(144)))

This is a way of writing that the probability of a left A signature occurring is 99%, while the probability of the right side (B signature after 144 blocks) is 1%.

Application 2, general expenditure

Once a valid script is found, one common barrier to the existence of many scripts is the lack of interoperability between different spending mechanisms. Users who wish to implement long-term time locks or complex multi-signature requirements may be concerned.

Miniscript, by directly indicating the spending conditions, allows the expression of any strategy so that anyone can:

Calculate the relevant address of the script;
Determining which signers are required to sign at a given time;
Generate a valid transaction, given a sufficient set of signatures;

Users don't have to worry about whether all participants are using compatible software or worry that they will continue to exist when such timelock settings are needed.

They also don't have to worry that their needs may change in ways that are incompatible with the signature software, so that using Bitcoin scripts does not limit them.

Application 3, reserve certificate

Related to the signature issue is the problem of proving the reserve fund , which is a process by which a company can prove that it can use some of the bitcoin without actually using the reserve bitcoin. Although there are tools in this area, such as Blockstream's reserve certification tools , there is no universal standard in the industry. Without Miniscript, there may not be a standard of reserve certification that covers the current diversity of hosting solutions.

Composition of expenditure strategy

Let's look at a concrete example of a Bitcoin script developer that is constrained by interoperability requirements. In the case of a company that hosts a large number of BTCs, the company hopes that these bitcoins can only be used passively with the consent of most of its directors. However, some independent directors want to use their own existing wallet software and hardware, and do not want to participate in a single key signing scheme (provided they provide with a dedicated application).

In the absence of Miniscript, generating a script containing all the signer's requirements, while ensuring to all signers that the complete script is sound and complete, and that their wallet software is compatible with the results, this will be an insurmountable problem.

With Miniscript, these directors can simply write strategies in their wallet software, construct a single policy that describes the threshold requirements, and then compile it into a Miniscript. They can directly verify that the compiler's output matches the original policy and that the original policy meets everyone's needs. They can then use any Miniscript-compatible software to calculate the address of the receiving currency, collect the signatures at the time of purchase, and combine the signatures into a valid transaction.

To give a simple hypothetical example: a company is using a custom multi-signature storage wallet with two directors, one of which uses a Blockstream Green wallet (configured for 2-of-2 multi-sign, with some delay The latter becomes 1-of-2), while the other uses the Electrum wallet (standard 1-of-1). Without a tool that allows for a combination of secure, interoperable scripting strategies, directors using Green Wallet cannot add their policies as "participants" to the company's multi-signature scheme. And if Green and the software used to build the company's multi-signature support Miniscript, then the two directors can use their favorite wallet directly, even without knowing the underlying script of the wallet.

Dynamic federation

The role of Miniscript, we can find a specific example in the Streamstream's Liquid side chain . One feature that Blockstream is currently developing (internally called Dynamic Alliance) is a script that allows existing Liquid members to manage new members to add or update control-hosted Bitcoin usability. Miniscript provides members of the Alliance with the tools to build such scripts quickly and efficiently (in fact, the Miniscript compiler found a 22-byte shorter version of the existing Liquid script, which is 5% less than our original manual optimization script. Workload). But more importantly, Miniscript allows members to automatically verify the important attributes of the proposed script, thereby reducing the need for coordination between members or performing expensive manual security audits of proposed scripts.

In particular, members can automatically verify that any script proposal includes:

Their own keys;
A time-locked emergency spending condition ensures that it is correct and far enough in the future.

It also allows them to verify that participants in the new alliance have the ability to spend coins controlled by the old league. This check is critical to ensure that this transition does not result in currency loss, even for users who transfer coins to the system at the time of conversion, which is almost impossible without Miniscript.

The history of Miniscript

The idea of Miniscript dates back to the summer of 2018. In mid-July of that year, Pieter Wuille introduced an output descriptor scheme for Bitcoin Core, a common method for describing the many different address types supported by Core. At the same time, Andy Chow, a blockstream intern developer at the time, was developing a partially signed Bitcoin transaction (PSBT , also known as BIP 174 ), a wallet interoperability agreement that was acquired in the wallet space. A lot of attention.

An important component of PSBT is the finalizer , which is the participant in the actual bitcoin transaction assembled from the set of signer data contained in the PSBT. This kind of assembly needs to know the scripts that are satisfied, which means that the wallet that supports PSBT must implement its own dedicated finalizer, which requires additional development and limits interoperability.

At that time, Andrew Poelstra was trying to introduce the PSBT implementation into the rust version of Bitcoin (a universal bitcoin library written in the Rust programming language) software (this implementation was originally proposed by Carl Dong). Poelstra observed on the IRC channel :

"If you have a highly structured script template, you don't need to really understand the script."

It was this idea that eventually became the core of Miniscript.

In fact, Poelstra and Wuille have been working on a hosting-related project, but they are frustrated by the lack of standard tools for complex multi-participant scripting. The two met in August 2018 to discuss the matter, and Wuille suggested implementing these "highly structured script templates" as an extension of the Bitcoin Core output descriptor.

As the extension evolved, it evolved into a structured subset of Bitcoin scripts, eventually becoming Miniscript, and a simpler "policy language" to directly represent spending conditions and compile into Miniscript. In January 2019, Wuille presented the preliminary results of the program at the Stanford Blockchain Conference.

In May of this year, Sanket Kanjalkar joined Blockstream for a three-month internship, and the focus was on implementing the Miniscript tool and helping it integrate with Bitcoin Core. With his help, MiniScript has become smaller, more efficient, easier to analyze, and better able to prevent scalability problems.

After these iterations, the Miniscript of today is finally formed.

Related work

Miniscript is based on and complements many other projects in the Bitcoin ecosystem. In particular, as mentioned above, Miniscript extends Bitcoin Core's wallet output descriptors and complements PSBT to implement fully generic updaters and finalizers.

Miniscript can be compared to Ivy , another language designed to make the advanced features of Bitcoin scripts easy to access. However, compared to Ivy, Miniscript is a direct representation of scripts (subsets), which means that the correctness and reliability of "miniscript" can be effectively verified. Miniscript also accepts many other forms of static analysis, which is not possible with both script and (Ivy).

Miniscript's strategy language is similar to Ivy because both are abstract and they must be compiled before they can be used on the blockchain. However, Miniscript's policy language is very similar in structure to Miniscript itself, so it's easy to verify that the compiler's output matches the compiler's input (in fact, this can even be checked manually), and it's easy to verify if Meet the expectations of users.

Another blockchain language associated with Miniscript is Blockstream's Simplicity . Like Miniscript, Simplicity is a low-level language designed to be embedded directly into blockchain transactions. In addition, Simplicity also supports many forms of static analysis, which are very important when deploying blockchain contracts, but this is difficult or impossible to achieve in alternatives such as Ethereum EVM.

In addition, Miniscript is not as powerful as simplicity to represent any computable function, and its scope is very limited: it can represent signature requirements, time locks, hash preimages, and any combination of them. This narrowing of the scope makes it easier for Miniscript to explain the use cases it covers, and importantly, it allows it to work on existing bitcoin blockchains. In contrast, Simplicity is a complete departure from Bitcoin scripting, which is still in the early stages of development.

Future work and conclusions

When designing Miniscript, we set out to make Bitcoin scripts easier to access. While much work has focused on investigating and proposing future changes to scripting and Bitcoin consensus rules to add additional functionality, we have also seen that infrastructure is not even used in a universal, secure, combinable, and interoperable manner. The existing features, which are currently lacking.

This work has not been completely completed. We have two Miniscript implementations (C++ and Rust versions respectively) and a policy compiler, but for easy access to this technology, we need to integrate it in common software. With the PSBT implementation (updater and finalizer) compatible with Miniscript, many PSBT signatures (including hardware wallet-based signers) can be used for complex scripts even without explicit support. In addition, the compiler can be improved, as there are many optimizations from strategy to script conversion that have not been considered.

This way, we have learned a lot:

Script resource limitations complicate policy optimization : Numerous consensus and standard impose resource limitations (maximum opcode, maximum script size, maximum stack size…), making it difficult to find the most given strategy once we approach these limits Good script. This is interesting because it may guide suggestions for future script improvements. Related to this, we are also surprised to learn that the Bitcoin consensus rule actually counts the number of keys participating in the execution of OP_CHECKMULTISIG(VERIFY) as a limit of 201 non-push OP_CHECKMULTISIG(VERIFY) per script.
The variable size of the verification complicates the cost estimate : a simple payment and multi-signature structure has a verification size that is independent of the exact set of existing keys. And once we move to a more complex script, the size of the verification becomes larger, which can complicate the cost estimate. Potential signers of a particular transaction output may need to optimistically guess the cheap path that will be used and construct the corresponding transaction. If not all keys or hashes for the path are ultimately available, you may need to change the transaction itself to account for the increased cost.
Segwit's stack encoding complicates optimization : because segwit's input stack is no longer coded as a script, it is encoded directly into a list of stack elements. This has the unfortunate side effect of changing the "true" encoding from 1 byte to 2 bytes. Therefore, Miniscript needs to care which sub-expressions enter which side of the if/else/endif structure.
Scalability : Because segwit, transaction scalability is no longer a breach of protocol correctness, but it may still have adverse effects (such as uncertainty about the rate of charge during broadcast transactions, slowing down the compact block) Propagation and interference hash locks are used as a global publishing mechanism). For these reasons, we considered the problem of non-extensibility when designing Miniscript and learned the reasoning of the general non-extensibility of the verification. To achieve this, Miniscript relies on certain segwit-specific rules.
The elimination of common subexpressions is difficult : despite trying many times, Miniscript does not support optimizing repeated subexpressions. Although this is possible in some specific situations, it seems to be difficult to do in a typical script. Adding some stack operations to opcode may change this.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!

Was this article helpful?

93 out of 132 found this helpful