One way to do a URSF is to reject the block *after* BIP110's activation block unless it contains a tx that violates one of BIP110's restrictions. If enough people run it, miners have to choose: make the BIP110 people fork off or make the URSF people fork off. They can't keep both

No miners are currently signaling support for BIP110, so investing time and effort in developing a URSF client seems like a waste of time and effort at this time (to me, anyways). Much easier to just use the rejectblock command post-fork if a BIP110 block that forks the chain is ever mined.

I cannot WAIT to dump this retard fork for more BTC, and the miners will do the same

What if they don't signal support for BIP110 but just stop mining txs that violate the BIP110 rules, to avoid losing 8% of their users? I don't want OP_IF in taproot to become "effectively invalid" just because miners opt to comply with a bad BIP out of economic interests

It seems to me that Coinbase alone could decide to make a URSF defacto "popular" whenever they wanted to - and the majoriry of miners would almost be certain to follow. It would be at that point that BIP110 users and miners - presumably still in the minority - would have to choose whether or not to continue on with the new coin they have created. I would be shocked if more than a handful of BIP110 supporters (especially any would-be miners) would be willing to die on that hill.

PS. Short of overwheming consensus support from the community as a whole, I don't see Coinbase (or any other regulated entities) being particularly keen on tolerating ANY potential for a soft fork to cause signifact disruption.

Last I checked BIP110 will have a mandatory signaling window in August, so if miners don’t signal, BIP110 nodes will in fact fork themselves off the network. Your scenario could still happen if miners do signal (which non-BIP110 won’t care about one way or the other). That’s why IMO it’s still good to pay attention to signaling, and if there is any it’s probably time to start considering a URSF. The worst case scenario is if miners don’t signal until very shortly before the mandatory signaling period starts. (Or even when it’s already started.) In that case I suppose the rejectblock command can still offer a solution, but it’d be a bit of a last-minute scramble…

Ah yes, I forgot about the mandatory signaling period. Still, if miners keep ignoring BIP110 they may be in for a rude surprise in September: a sudden, completely avoidable loss of income from BIP110 runners. A sufficiently large loss of income should worry any business. They could be sued by their shareholders for negligence.

It is shaping up to look like a significant disruption *unless* miners comply with BIP110. If they ignore BIP110, or if there is a popular URSF, they may lose 8% or more of their users. Right now the best way to get 0 disruption looks like for miners to, perhaps begrudgingly, start enforcing BIP110 just to keep the network united.

If miners start enforcing BIP110 out of an economic interest in keeping the network from forking, you may find yourself on a BIP110 compliant chain, and without any fork coins to dump. What then?

I doubt it would represent a significant loss, and in fact I suspect that adopting BIP110 would harm the value of bitcoin more than losing these people would. But without fork futures markets --which I'm very much in favour of!-- it's anyone's guess unless and until there actually is a split. (That's another argument for a URSF btw, it would enable a very well defined fork futures market.)

That might be the biggest load baring “If” I’ve ever seen. Any miner with the tiniest amount of intelligence isn’t going to run miniscript breaking dogshit software that does nothing to stop spam anyway. Give them some credit.

> I doubt it would represent a significant loss It sounds like you don't think the loss will be significant but otherwise agree with my premise -- that miners are incentivized to signal for BIP110 *if* they judge that the loss of revenue due to a split outweighs the loss of revenue due to enforcing BIP110. I think BIP110 runners probably represent less fee revenue than the 8% number might suggest on a surface level. But I'm not sure. Definitely thinking about writing a URSF proof of concept to "do my part" in the fight against BIP110. If I make one I might market the effort as an effort to "save miniscript" rather than an effort to "fork the bip110 people off," as I personally align with the BIP110 people in most ways and do not want them to fork off.

They might do it to avoid losing income from ~8% or more of the network

By risking to lose 92%? Terrible risk reward on that trade.

Yes I agree with your premise. I would also encourage the development of a URSF for that reason, if you (or anyone else) don't consider it a waste of your time and effort.

They don't lose 92% by enforcing BIP110 All BIP110 compliant blocks are accepted by standard bitcoin nodes, so miners can keep all nodes happy by enforcing BIP110 A URSF might change that

Would you be running a URSF if it existed and why? Where do you stand on this stuff? From your comments right here, it seems like OPIF is the reason why you might be against it. What functionality makes OP_IF important to you if you are anti-BIP 110?

For sure, if no URSF ever materializes, miners could very well just collectively choose to start enforcing BIP110. Even better would be if Core just endosed BIP110 outright; or, possibly even came up with their own acceptable alternative. None of the above are my basecase, however. I'm not exactly sure what % (or possibly other metric) would be considered a credible threat in the minds of the anti-BIP110 crowd; but, I would fully expect a URSF if/when that line is eventually crossed - which I suppose might not even happen until well after a potential chain-split. The path to the least disruption may very well be to play chicken with the BIP110 8%

What % of block are currently non compliant with 110?

I think all of them are currently non-compliant with BIP110, if non-complaint means "not signalling for it"

You wrote “BIP110 compliant blocks” so I’m just asking what percentage of blocks would be non complaint? Roughly?

but you technically would "fork them off" to "save miniscript"? and in what ways do you align and not align with bip 110?

it depends if 55% of miners start signaling for BIP110, then I suspect the dominant chain will have 100% BIP110 compliant blocks if less than 45% switch, I suspect there will be a permanent fork (this is currently what I suspect is the likeliest outcome) if it's between 45% and 55% then I don't know what to expect

> 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

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?

8% of their users? as in the fees they get? So this is almost an irrelevant fraction at current fee market. But we'd also have to ask what percentage of users will be lost in a BIP110 main chain scenario. No more jpegs and other spam, right?

It will hurt my bags but I can’t help but be glad that noderunners will not be passive and hand the decision over to miners.

Recent research indicates that revenue from spam accounts for about 0.1% of mining revenue:

Issue #7: Why Miners Won't Stop Spamming

Why do miners fight over 0.12% of revenue while harming the protocol?

So I would not be surprised if 8% of active "monetary maximalists" already outweigh that, and outweigh it even more if more of them start running BIP110

> why not instead propose a bip that does not have the two parts you dislike? Why not both? If I do not like X it seems wise to help prevent X from happening And if I *do* like Y it seems wise to also help ensure Y happens

It’s just devs don’t wanna give their toys away, even though they don’t play with them and they may never play with them.

They lose 0.01% revenue if they activate bip110. That’s how much they have to “sacrifice”.

> I suspect that adopting BIP110 would harm the value of bitcoin more Stay in your lane and try not to opine on economic topics. You’re out of your depth.

If you have concerns about OP_IF why don’t you just hash it out with Dathon instead of doing the heavy lifting for the enemy? Seems like a pretty stupid thing to do. If they want to create more chaos in August and fork off eventually, at least give them the opportunity to work on it themselves.

How did you come up with that number?