Topic: Miniscript Project (Read 524 times)

Or lack of usage, there's no reason to support miniscript when software developer isn't their main target. Besides, Minsc (https://min.sc/) also exist which offer easier usage and have more star on GitHub (150 vs 106 stars).

I think miniscript is not really intended for end users, but rather for services that create such miniscripts.

I am bringing up this thread.
I don't know if there are other more active ones, just to report that Shiftcrypto, the firm behind BitBox, just released a firmware update for BitBox 02 supporting Miniscript.


Source: BitBox 08.2023 Motterascio update

Miniscript support
To improve the BitBox02’s compatibility with future self custody solutions, we have added Miniscript support to the BitBox02’s firmware. Miniscript is a Bitcoin scripting language that enables and simplifies more complex spending conditions, such as decaying multi-signature wallets which can be used to create recovery options, among other things.

How can we do more than Miniscript while preserving its useful properties? How can we make the system more powerful while preserving its structure? These thoughts lead us to Simplicity, an entirely new blockchain language designed from the ground up as an alternative to Bitcoin Script.

Or lack of usage, there's no reason to support miniscript when software developer isn't their main target. Besides, Minsc (https://min.sc/) also exist which offer easier usage and have more star on GitHub (150 vs 106 stars).

The interesting thing is, even to this day, there is no wallet that supports miniscript (not even Bitcoin Core) and that is considering Taproot has already been active. Could it just be a lack of developers?

By the look of this, I guess it's going to be a hell of a lot of constantly checking what all those abbreviations mean when you are formulating a script. I understand the gain in terms of versatility and decrease of size, but for me Bitcoin Script is way easier to read and see what's going on. I guess I will need to put in effort and practice a lot and maybe it becomes second nature with Miniscript, but for complex stuff I can already tell I will struggle with it for a while, maybe that is how my brain works, I like to see every "extended" on display with no shortcuts.

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

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

By the look of this, I guess it's going to be a hell of a lot of constantly checking what all those abbreviations mean when you are formulating a script. I understand the gain in terms of versatility and decrease of size, but for me Bitcoin Script is way easier to read and see what's going on. I guess I will need to put in effort and practice a lot and maybe it becomes second nature with Miniscript, but for complex stuff I can already tell I will struggle with it for a while, maybe that is how my brain works, I like to see every "extended" on display with no shortcuts.

Your understanding is correct.
Miniscript is a simpler way to use bitcoin script, that is part of the protocol, leaving it absolutely untouched.
In this sense is making protocol better: if more people and more developer use bitcoin script, it is going to be more widely used, being ultimately more useful, hence better.

Cointelegraph published an article detailing better:
 Segwit creator introduces new language for bitcoin smart contracts

We're excited to share our #engineering blog post about #Miniscript - a language for representing #Bitcoin Scripts in a structured way, enabling efficient analysis, composition, generic signing and more. 📜🖊️🔒 medium.com/blockstream/mi…

From what i've read and understood, it doesn't change Bitcoin protocol at all, it offers more friendly way to write Bitcoin script.
Regardless, it'll allow more people and developer use Bitcoin script.

While Miniscript is basically a reformulation of Bitcoin script and remains the same script language, it allows wallets and other software to construct and analyze scripts more effectively, Wuille explained on Reddit.
In the post, Wuille provided an example of how the same notation would look in basic Bitcoin script in comparison with one in Miniscript.

Just announced our Miniscript project website on the bitcoin-dev mailinglist: bitcoin.sipa.be/miniscript/

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 multisig where one of the "keys" is another multisig).
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 sort of operations possible. It has a structure that allows composition. It is very easy to statically analyze for various properties (spending conditions, correctness, security properties, 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.

In short, it's a way to write (some) Bitcoin scripts in a structured, composable way that allows various kinds of static analysis, generic signing, and compilation of policies.

Imagine a company wants to protect its cold storage funds using a 2-of-3 multisig policy with 3 executives. One of the executives however has a nice 2FA/multisig/timelock based setup on his own. Why can't that entire setup be one of the multisig "participants"?

A lot of work is focused on extensions to the functionality of the blockchain itself to support more complex application, but I feel we're forgetting that using these features in an accessible, composable, analyzable way is basically impossible today.