When you perform a bitcoin transaction, you’re instructing a bitcoin wallet to execute a command on your behalf and provide it with a few parameters, such as the public address you want to send to, the amount you want to send, the UTXO you wish to use, the fee you’d like to pay miners to secure the transaction and of course a valid signature from your private key.
To perform a transaction, your wallet uses established scripts or OP_CODES native to the bitcoin network. A simple transfer of bitcoin from one bitcoin user to another will contain specific scripts, while a more complex transaction like a muti-sig wallet would require a different set of scripts.
For most of us, the bitcoin wallet would abstract these commands from the process, so users need not deal with the complexity of the script. Still, for power users like exchanges, software wallet developers, bitcoin businesses and signing device manufacturers, these scripts are an important part of building on bitcoin and creating a robust and smooth experience.
If, for example, a wallet compiles a transaction that fails, that would not be the ideal experience for the user, while compiling a transaction that loses funds would be a costly experience.
What is bitcoin script?
Bitcoin uses a stack-based scripting language embedded in bitcoin transactions. When bitcoins are sent to a recipient, script commands in an unlocking script (scriptSig) validate the available bitcoins (UTXOs). In contrast, Script commands in a locking script (scriptPubKey) set the conditions for spending them.
A script is a list of instructions accepted by the bitcoin network and recorded with each transaction that describes how the next person wanting to spend the bitcoin being transferred can gain access to them.
The issue with the bitcoin script is that the code base is over a decade old and has hundreds of OP_CODES, some fundamental, some useful, some useless, and some are merely placeholders for what could be future features.
While most of us are content with the basic OP_CODES provided, that doesn’t mean new and innovative ways of using bitcoin should be ignored. Having all these commands and different combinations that can be stacked on top of one another might offer bitcoin users more control and unique uses for bitcoin transactions.
The thing with combining commands is that there needs to be a uniform standard for each building block; if there isn’t, you could create conflicts or exceptions that wallets would compile and broadcast to the network ending in some hard lessons or expensive lessons.
To fully take advantage of bitcoins’ various OP_CODES, there needs to be an audit of each script and a review of the compatibility of each combination, a “script audit”, so to speak, and this is where miniscript comes into play.
What is miniscript?
Miniscript was designed and implemented by Pieter Wuille, Andrew Poelstra, and Sanket Kanjalkar at Blockstream Research as a result of working on multi-sig implementations but is the conclusion of discussions with several other people who have had to deal with bitcoin scripting in the past and found it difficult or time-consuming to work with and compile.
Miniscript is a standardisation of bitcoin scripts; think of it as turning each script into a building block that any bitcoin wallet could use as a method of compiling transactions on the back end based on what the user would like to achieve.
Minscript allows the software to automatically analyse a script, including determining what witness data must be generated to spend bitcoins protected by that script. It saves wallet developers time as they don’t need to write new code when they switch from one script template to another and would provide better interoperability for users switching between wallets.
The structured representation of Bitcoin scripts provided by miniscript allows wallets to be much more dynamic about the scripts they use while also being efficient in compiling transactions and slightly reducing the footprint of a transaction on-chain.
In support of that dynamism, miniscripts can be created using an easily-written policy language. Policies are composable, allowing any valid sub-expression to be replaced by another valid sub-expression (within certain limits imposed by the Bitcoin system).
This brings the promise of more complex smart contracts directly on the base chain and offers users more flexible solutions for self-custody that can make it easier and safer to hold your own keys.
How miniscript works?
Miniscript is a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more.
Bitcoin Script is an unusual stack-based language with many edge cases, designed for implementing spending conditions consisting of various combinations of signatures, hash locks, and time locks. Yet despite being limited in functionality, it is still highly nontrivial to:
- Given a combination of spending conditions, finding the most economical script to implement it.
- Given two scripts, construct a script that implements a composition of their spending conditions (e.g. a multi-sig where one of the “keys” is another multi-sig).
- Given a script, find out what spending conditions it permits.
- Given a script and access to a sufficient set of private keys, construct a general satisfying witness for it.
- Given a script, be able to predict the cost of spending an output.
- Given a script, know whether particular resource limitations like the ops limit might be hit when spending.
Miniscript functions as a representation for scripts that makes these sorts of operations possible. It has a structure that allows composition. It is very easy to statically analyse for various properties (spending conditions, correctness, security properties and malleability).
It can be targeted by spending policy compilers (see below). Finally, compatible scripts can easily be converted to Miniscript form – avoiding the need for additional metadata for e.g. signing devices that support it.
For now, Miniscript is really only designed for P2WSH and P2SH-P2WSH embedded scripts. Most of its constructions work fine in P2SH, but some of the (optional) security properties rely on Segwit-specific rules. Furthermore, the implemented policy compilers assume a Segwit-specific cost model.
Building blocks for easier smart contracts on bitcoin
Now that you know what miniscript is about and its technicalities, what would it bring to the bitcoin blockchain and for users like you and me? Well, several examples have been highlighted thus far, namely:
A decaying multi-sig
In one instance of a more complicated transaction one could perform using miniscript, you could create a multi-sig wallet that requires a 3 of 5 to unlock, but as time goes by or a particular block time is reached, that multi-sig could turn into a 2 of 3 multi-sig allowing for fewer keys to move funds, in case some parties of the multi-sig have lost access to their respective keys.
Inheritance timelocks and deadman switches
Another advanced option that could be enabled by miniscript is the creation of an inheritance wallet where you specify a wallet in a multi-sig that would only acquire signing rights to the funds should after a certain time or rather set amount of blocks have been mined since funds were moved into that wallet.
This could grant someone access to your funds in case you pass on, like an on-chain deadman switch.
Saving fees on transactions
Depending on how specific wallets compile transactions, they might require more on-chain data to execute, meaning you’re taking up more resources to pay for that. Minscript promises to streamline transaction compiling, allowing for the smallest on-chain footprint possible, thus saving users on fees, regardless of the type of transaction they plan to make, be that a standard transaction, a multi-sig transaction, a Lightning channel open or a CoinJoin.
Wallet support for miniscript may take some time.
If you like the sound of Miniscript and you’re rushing off to play around with it, you might have to reel in that enthusiasm, as most wallet application still fully contains the old protocol inside. Despite the fact that miniscript would not require a soft fork and any consensus changes, it does require wallet developers to refactor some of their code base, which is easier said than done.
Until user demand or a substantial impact on the application development and savings on transaction fees drives miniscript adoption, most wallets will stick to the tried and tested scripting.
As with everything in bitcoin, everything needs to be backwards compatible, and even if most wallets adopt miniscript, there will always be legacy applications or legacy versions of specific applications available to make sure that no user is locked out of their funds in case they need to use unupgraded software that does not support miniscript.
Do your own research.
If you want to learn more about miniscript on bitcoin, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research other sources, and you can start by checking out the resources below.
