pedro
· 1d
but you technically would "fork them off" to "save miniscript"?
and in what ways do you align and not align with bip 110?
> 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