Lots of work to do

Needed: an open source, disintermediated hashrate market where messaging happens on a more robust foundation than telegram

I'd like to make a proof of concept based on nostr

Yes, I think so

> La mayoría económica siempre se impone

De acuerdo. Los que activan el UASF deben ser la mayoría económica. Si no, los mineros pueden ignorarlos. En esto caso, creo que tratan a activar el UASF cuando la basura en la cadena no importa a la mayoría económica. Entonces hay mucho riesgo que los mineros ignoraran esta minoría de usuarios. Mi preferencia es (1) arreglar los problemas con BIP110 (2) incluyendo, no programar una fecha para el UASF (3) enfocar en convenzar la mayoría económica (4) despues que esto, programar una fecha para el UASF

Sí, exacto

hay riesgos rasonables y riesgos estupidos. La soberania consiste en la decision de que riesgos quieres asumir, no en asumir todos los riesgos que te pasan.

> it’s not guaranteed. Nothing in Bitcoin is. That’s sovereignty.

It's needlessly taking on massive risk, like 95% chance that you'll end up forking yourself off the network. I suppose technically that is a sovereign thing you can do with your node. But I don't want to do that. Not doing that is sovereign too.

> That’s why lock-in isn’t until August 2026. The timeline exists precisely to give wallet devs runway.

Gee, how generous. "Make this bad change by August. If you won't do it, get lost, you AND your lost income!"

> On the circular temporariness argument: extension requires an entirely new UASF with new signaling, new node adoption, new miner threshold. That’s not the same political and social cost as the original.

The original also required new signaling, new node adoption, and a new miner threshold.

> You’re treating “could theoretically be extended” as equivalent to “will be extended.”

I disagree that it "will" be extended. I *do* think the logic which says "we just won't extend it because we don't want to potentially/permanently freeze the money of innocent miniscript users" should also lead you to say "wait, if would definitely be a bad idea to extend the freeze, then the freeze is probably a bad idea to begin with. So let's just not freeze their money in the first place."

> On fund safety: only NEW UTXOs created in unpatched wallets AFTER activation are at risk. Existing UTXOs — permanently exempt.

Yes. The first part is a significant problem.

> [It's] entirely avoidable by shipping the update

The update is a bad downgrade, and even if it was a good idea, the time frame is bad.

> Your strongest point remains the miniscript complexity. Acknowledged.

Then join me in opposing BIP110 until that is fixed.

> But “hard for wallets” is not the same as “bad for Bitcoin.”

BIP110 is "bad for Bitcoin." It treats OP_IF in taproot transactions as a bad thing when it is a good thing. OP_FALSE OP_IF is the bad thing. Do not throw the baby out with the bathwater.

> Inscription spam has been hard for every node operator since 2022 with no expiry date.

Agreed. But two wrongs do not make a right.

> That’s what UASF means. Nodes signal. Miners comply or get orphaned. 2017 proved this works.

It *can* work, but it is not guaranteed to work. If the people who want the thing are a small enough economic minority, miners may very well ignore them and let them fork off. That's why I want to see more signals of economic support for a modified BIP110 before scheduling a UASF for it.

> Miniscript wallets need a trivial update — split the branch, ship the patch.

Neither of those is trivial. Changing miniscript requires considering several possible variations, lots of testing, lots of review, and lots of time. Shipping the change requires warning users that this is a breaking change which, in some cases, requires them to start using a new wallet and tell people "don't send money to my old wallet anymore or I may not be able to access it." It's a massive headache that requires lots of fiddling to make the transition as painless as possible, and there's no way to make it completely painless. And all of that takes lots of time.

> Temporary interventions exist because conditions change. A one-year firebreak while inscription economics are corrected is not a logical commitment to permanent restriction. The auto-expiry is in the spec for exactly this reason.

That all depends on what happens in the future. Suppose that around this time next year the Inscription people start prepping a new round of spam, with an advertising campaign about how "inscriptions are back on bitcoin in September 2027!" If there is evidence that their efforts are generating sufficient interest, that'd likely prompt talk of extending bip110. And once again we'd fire up the same talking points: "you guys said we wouldn't renew the ban on OP_IF." -- "No, banning OP_IF is the whole point, plus everyone who was affected has had plenty of time," etc. The exact reasons that supposedly justify doing the ban in the first place are likely to be trotted out again. If they are bad reasons in the future, they are bad reasons now. If it's bad to extend the ban later, it's bad to implement it now.

> Honest point. But existing wallet software has until ~August 2026 lock-in + two weeks to update.

(1) Eliminating OP_IF from taproot is a bad idea in the first place (2) Even if it was a good idea, protocol devs and wallet devs deserve more time to do it right, because doing it wrong brings significant risk of loss of funds for innocent users.

> New UTXOs only become an issue if wallets don’t ship the patch. That’s on the wallets, not the protocol.

It's on the protocol which is trying to force this bad change for no good reason.

> the auto-expiry is consensus-enforced, not a promise. No extension without another UASF.

See my previous paragraph on this. The exact reasons that supposedly justify doing the ban in the first place have a significant chance of being trotted out again in a year to extend the ban. If they are bad reasons in the future, they are bad reasons now. If it's bad to extend the ban later, it's bad to implement it now.

> “Most nodes are apathetic” is an interesting reason to never activate anything. By that metric, no soft fork would ever pass.

I disagree. I think you can persuade nodes to support your cause. But setting a countdown before you've done that is foolhardy and likely to get you kicked off the network.

> The OP_IF restriction in BIP-110 applies specifically to Tapleaves in Taproot scripts

And it is a bad idea because miniscript uses that feature in a perfectly innocent way and there is no good reason to break it.

> It's temporary (one year, auto-expiry)

If bip110 fans think it's okay to do the partial ban now, then the same reasons that make them think so will probably make them think it's okay to extend the ban a year from now. Conversely, if they have reasons for thinking it would be bad to continue the ban next year, then just apply those reasons right now, and don't do the ban in the first place.

> The fix for affected wallets is splitting OP_IF branches into separate Tapleaves, which Taproot best practice already recommends

That is not always recommended. OP_IF is in taproot in part to retain a lot of compatibility with previously written scripts and compilers, including miniscript. Moreover, there are frequent occasions when it is more efficient to use OP_IF than it is to use another tapleaf. BIP110 acts as if OP_IF is a bad thing when in fact it is a good thing.

> Lightning unaffected. Multisig unaffected.

It is strange to list all the things that "aren't" affected instead of addressing the things that "are" affected. Miniscript. Nunchuk. Bitvault.

> Existing UTXOs [are] permanently exempt

Utxos received into affected wallets after BIP110 activates (*if* it activates) are not exempt. I'd be okay with BIP110 if it just exempts those potential future utxos too.

I think the timing of the UASF is problematic, but a bigger problem is the partial ban on op_if.

> do you fully agree that [the limits] are reasonable?

Which limits? I fully agree with the first six items in the spec. I only have a problem with the seventh (which is the ban on op_if) and the activation method (I think it is a bad idea to set a countdown when most node runners are still apathetic about the problem which bip110 tries to address)

I proposed how to fix bip110 in this document: https://github.com/supertestnet/ursf-110 -- scroll to "What do you propose as an alternative to BIP110?"

> I assume they have different financial incentives that everyone else

Perhaps the people in charge of those mining pools genuinely think two things:

(1) Spam makes bitcoin less valuable -- i.e. it's sort of a parasite that harms bitcoin. (If that is what they think, I agree with them.)

(2) Bip110 would damage that parasite, so it is good. (If that is what they think, I disagree with them.)

If they agree with both of those premises, then they could reasonably conclude that bitcoin will grow in value if the parasite that is currently harming it gets damaged. And that chain of logic might give them a financial incentive to support bip110.

Spam hurts their pocketbook -> Bip110 fights spam -> Bip110 helps their pocketbook