Damus
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?
Super Testnet profile picture
> 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
pedro · 1d
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?