BIP110 does two bad things. First, in certain circumstances, it freezes the funds of wallets that use the miniscript language in a certain way. Miniscript is a bitcoin smart contracting language with a bunch of built in functions, and it is designed to "compile" a bitcoin wallet that uses one or more of those functions as selected by users and/or developers. Some of those functions sometimes violate one of BIP110's proposed rules (the rule against using the OP_IF function in taproot wallets), which could cause users of some miniscript wallets to lose funds, depending on how they use it. This potential problem was brought up before the BIP110 software was written, including by me, and a fix was proposed, but the BIP110 devs decided to move forward without fixing it. I think it is a bad idea to potentially freeze the funds of innocent miniscript users. I think it would be better to provide wallet devs with a variant of miniscript that doesn't violate BIP110's proposed rules, and enough time to upgrade. Alternatively, BIP110 itself could be modified so that it doesn't break current versions of miniscript, but BIP110's developers have rejected that option because one of the most popular spam formats uses OP_IF in taproot transactions and they want to be sure to block that. Apart from breaking miniscript in certain cases, there is another reason I do not like BIP110: I think most bitcoin node runners are currently largely indifferent to the forms of spam that BIP110 tries to block, and are therefore unlikely to run BIP110 on their nodes. With insufficient support from node runners, I think BIP110 will fail to sway miners to enforce its rules, and the small number of people who do run BIP110 will probably fork off the bitcoin network sometime close to September. I would prefer to continue winning people over to the anti-spam movement, and only do an anti-spam soft fork once there are more signs that a sufficient number of people will run it, including economic signals.

Replies (2)

It is true. Saying "miniscript could do something different than how it does it" does not contradict my point. My point includes that miniscript could and should be modified to work differently. But it is wrong to demand that wallet devs do that, who may not have the requisite expertise, and then give them a 6 month deadline, after which, if they haven't done this thing they may not even know how to do, some of their users may have their money frozen. It would be better to do the work first if changing miniscript and then offering a bip110 compatible variant to them; or modify BIP110 so that it only targets the inscription envelope pattern, which is never used by miniscript.