OverviewExploreTrending
Nostr Archives
OverviewExploreTrending
Super Testnet25d ago
> 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
💬 2 replies

Thread context

Root: ef06c4935833…

Replying to: 5718428d5c3f…

Replies (2)

pedro25d ago
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?
0000 sats
serapath【ツ】☮21d ago
you used time to propose USRF - but have you considered proposing an upgrade to BIP110 that mitigates the issue?
0000 sats