pull down to refresh

Does BIP 110 cause problems for existing miniscript-based wallets?Does BIP 110 cause problems for existing miniscript-based wallets?

Kevin Loaec, founder of Liana Wallet, recently posted this:

For context, for the 110 fork people:
Miniscript uses things called fragments. Some of these fragments use op_if, that your fork disables for some reason.

A user defines what their wallet should be, for example "a 2-of-5 multisig". Miniscript will output a Bitcoin Script (a wallet basically) that is the best and safest way currently known to do this policy in Bitcoin.

Disabling an opcode that is very much a building brick for safe Bitcoin wallets is dumb, but also has a big engineering cost on:
  • the engineers who build the Miniscript engine
  • the devs that implemented it, in Core and in multiple libraries like Rust-Miniscript
  • wallet devs
  • wallet users who may unknowingly have such a policy.
This cost cannot just be denied or ignored by "there is a 2 weeks window" it'll take a lot more than 2 weeks to do (took 3 years to get Miniscript anywhere), and users may be impacted without knowing so.
Bip 110 is all about virtue signaling and ignoring real costs on the ecosystem, including potential loss of coins for users who did nothing wrong, just used a good wallet software.

There has been a debate about whether BIP 110 actually interferes with the scripts produced by miniscript wallets like Liana, Nunchuk, and Bitcoin Keeper, particularly because BIP 110 proposes making OP_IF invalid in Taproot scripts. @dathon_ohm maintains that

BIP-110 does not affect UTXOs that are already confirmed before the softfork activates, so there is zero chance of Liana users being affected, even if Liana devs are irresponsible and let them create Tapleaves with OP_IF.

As well as saying this in the BIP:

Specifically regarding Liana Wallet and OP_IF, Loaec says:

I believe we don't have "if" currently in any Liana taproot scripts. We could in the future either through change of our rules (enabling more complex policy) or changes of the Miniscript version itself (outside of our control). Tagging @giacomozucco here.
AFAIK our current paths are segregated in different leaves, not using IF (in tap-miniscript).

This is about Liana, I don't know what other wallets do.

I do not support the disabling of useful opcodes though.

Nunchuk wallet weighed-in saying:

It is possible to generate OP_IF tapscripts using custom miniscripts and the standard Miniscript compiler. @mononautical went into an example a few months ago. Nunchuk supports these types of scripts.

And here is the mononautical post (part of a larger thread) that Nunchuk references:

this taproot OP_IF example is much more worrying for the RDTS proposal than I first realized.

it's actually a miniscript wallet policy:
thresh(3,pk(A),pk(B),pk(C),pk(D),older(T1),older(T2))

meaning "a 3-of-4 multisig, decaying to 2-of-4 after time T1, and 1-of-4 after time T2"

Users of miniscript wallets are not de facto irresponsibleUsers of miniscript wallets are not de facto irresponsible

BIP 110 says this about breaking user space:

Yes, this proposal intentionally breaks user space, specifically the data storage user space. This is necessary in order to communicate that data storage is not supported. Pains have been taken to avoid breaking monetary use cases, and it is unlikely that any such use cases have been affected, but in theory they might be. See the Tradeoffs section for more details.

One of the things that has been most worrying to me about BIP 110 is how its supporters have continually downplayed the disruption caused by BIP 110 changing what Bitcoin users were previously able to do, even as I quoted above, calling devs irresponsible if they don't rewrite miniscript and all its various libraries.

@giacomozucco expressed this well in a response to dathon's tweet:

Using miniscript would not have been "irresponsible", and some user may have wanted to use it after next September. A Bitcoin that allows that is objectively better money. Not the case for Liana through, as clarified.

Loaec also did a nice job explaining how breaking user space in this manner is highly disruptive:

People use whatever they use without knowing what script is actually in place.
For example, do you know what exact Bitcoin script your wallet uses? You probably don't, and shouldn't have to anyways.
You wouldn't know if you are using op_if unless you check on chain.

Bitcoin users should be able to have confidence that a utxo they create today will be spendable in 10 years. If a BIP risks this property, it needs to be for a very clear and near-universally supported reason.Bitcoin users should be able to have confidence that a utxo they create today will be spendable in 10 years. If a BIP risks this property, it needs to be for a very clear and near-universally supported reason.

Here is dathon's response to Loaec's post from above:

And here is Luke Dashjr's response:

FUD. "It is a bug to use op_if for that. You have more than 2 weeks. Start fixing it today." https://x.com/i/status/2021610190466920834

reply

if you look at my OP, I included that post from Luke.

You may feel that soft forks that break user space should be taken lightly, but it seems to me that if we want bitcoin to be a useful money for any large group of transactors, we are going such actions are not going to help.

reply

You seem not to know what user space is. The term is not applicable to Bitcoin.

Bitcoin with the BIP-110 security update is fine. Miniscript is minishit and its sellers should not blame others for defects in it.

reply
102 sats \ 0 replies \ @optimism 59m
The term is not applicable to Bitcoin.

Doesn't that make the orditards a feature, not a bug?

reply

do you interact with bitcoin by typing your transactions out in json?

reply

Sometimes. It is not what mInIsCrIpT is about, though.

reply

I ask because I don't think most people who use bitcoin interact with it that way. they use some kind of wallet software. most people do not care what scrip their wallet is using. whether it is miniscript based or raw bitcoin script based is immaterial. users just want their wallet to produce addresses at which they can receive coins. soft forks that require users to update or less the software will produce invalid scripts is something we should be very careful about.

reply
102 sats \ 6 replies \ @BITC0IN 6h

Sounds like wizards fucking around are the only ones doing this.

reply

Miniscript is a long-standing attempt to make Bitcoin Script easier to use and reason about. It's been around since 2019. It is not something that was developed for shitcoiners, nor is does it require changes to bitcoin.

It is particularly helpful for multisig wallets and timelocked wallets. Both of which I'd say are pretty useful for normal Bitcoiners.

reply
-14 sats \ 4 replies \ @BITC0IN 5h

I'm aware, vast majority of Bitcoiners aren't using it.

It's a wizard feature.

I will not be running a shitcoin fork on my nodes.

reply

veering close to fearmongering - the anti 110 crowd taking a turn at pearl clutching - also, note the derisive tone of '110 fork people'

reply

BIP-110 sounds good on paper — a temporary soft fork to reclaim block space from Ordinals and inscriptions — but it fundamentally misunderstands the problem it's trying to solve. The proposal introduces seven consensus-level restrictions targeting data embedding vectors, yet Peter Todd demonstrated its fatal flaw by encoding the entire text of BIP-110 itself into a single compliant transaction. If the rules can't even stop someone from embedding the proposal's own text, they won't stop determined data embedders — they'll just make the process slightly more expensive and fragmented. That's not a solution; it's an inconvenience.

The deeper issue is what BIP-110 represents for Bitcoin's future. Bitcoin's consensus rules have historically been objective and content-neutral — a valid transaction is valid regardless of what its data "means." The moment we start restricting transactions based on subjective judgments about "legitimate" versus "illegitimate" use of block space, we set a precedent that could be turned against any disfavored use case tomorrow. And with only ~7% of nodes running the activation client and zero miner signaling, a forced UASF activation risks a chain split that would burn the community's coordination capital — making it harder to rally support for consensus changes we actually need.

If blockchain bloat is the concern, there are better paths forward. BIP-54 (Great Consensus Cleanup) addresses overlapping security concerns like worst-case block validation time through targeted bug fixes without making content-based judgments, and it has far broader developer support. Bitcoin's censorship resistance isn't just a feature — it's the foundation. We should be solving the spam problem with better economics and smarter protocol design, not by giving anyone the power to decide which transactions deserve to exist.