> you technically would "fork them off" to "save miniscript"?
Yes
> in what ways do you align and not align with bip 110?
I like the idea of using a soft fork to reduce the amount of spam on the blockchain. The benefit to node runners is "more efficient node." But I think bip110 is bad in its current form.
One of my concerns centers around the decision to ban people from using op_if in taproot txs. I would be okay with that *if* there was reason to think no one is doing that for non-spammy purposes, but right now, there are pretty standardized miniscript tools that use op_if in taproot, and innocent bitcoiners occasionally use miniscript for some stuff, so the ban has a real chance of victimizing innocent users.
I think the other provisions of bip110 in the Specification section are reasonable.
I'd like to see an alternative variant of miniscript that avoids op_if in taproot, and *then* -- after everyone has time to upgrade -- op_if could be more safely banned from taproot.
I'd also be okay with doing a variant of bip110 *without* the partial ban on op_if, except there is one other issue I have with it, concerning the activation method. I can share more if you want to hear more
Login to reply
Replies (3)
thank you, i do want to hear more, yes.
another question i have now is: you're considering writing a proof of concept for a ursf, but since you're aligned on the anti spam topic why not instead propose a bip that does not have the two parts you dislike?
> i do want to hear more, yes
See the last paragraph of this post:
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.
View quoted note →
you used time to propose USRF - but have you considered proposing an upgrade to BIP110 that mitigates the issue?