Is this to push the fence sitters? Isn't that inherently more risky than a soft fork?

Thanks for that. I'm going to follow up here, but I apologize in advance if it seems like I'm changing the subject a bit 😀. My goal is to clarify the order of events, and I'm doing that to help myself think about exactly when we should reject blocks: TL/DR: even if 55% signalling is reached in one block, the RDTS rules won't be enforced until at least two weeks later. Two scenarios, discussed separately: The simplest of the two scenarios is that it never reaches 55% hashrate. In that case, mandatory signalling starts at 961632. This is the first time that BIP110 nodes can reject blocks that would be acceptable to the conventional (i.e. Taproot) nodes. This doesn't guarantee that a split will happen immediately, the BIP110 miners could be lucky and get the first few blocks, but it is the earliest [in this scenario] when a split could occur. After 2016 blocks in this state, they reach their 'LOCKED_IN' state. From the BIP "The deployment transitions to LOCKED_IN at height 963648 (one retarget period before max_activation_height), then to ACTIVE at height 965664". During LOCKED_IN, further signalling is *not* required, and miners do not enforce any of the RDTS rules on transactions. It's only in the following retarget period, that they finally reject transactions with large OP_RETURNS and all the other banned transactions So, summararizing the timeline in this "low hashrate" scenario: - 961632 to 963647: mandatory signalling, i.e. a permanent chain split can occur here. - 963648 to 965663: LOCKED_IN. No rules applied, not even any mandatory signalling - 965664 onward. ACTIVE. Blocks are rejected based on whether the transactions follow the rules The second scenario kicks in if they get 55% of hashrate. Once they get 55%, they don't immediately reject non-signalling blocks, and they don't reject big OP_RETURNs. When they reach 55% (1109+ blocks out of 2016), the *following* 2016 blocks are in the LOCKED_IN state, i.e. no rejection rules applied. After 2016 blocks in LOCKED_IN, then they switch to ACTIVE and reject blocks with large OP_RETURNs

Who the fuck care a wallet that misuse the protocol? Fuck this devs. They should do better. Its ridiculous that for save some marginal project, we need to embrace all the shit that Core did. Bitcpon is money.

damn, i agree this is a bad look -miniscript is kinda essential in trustless inheritance schemes. liana also uses it, but P2WSH is their default

URSF110 will fork off the legacy chain if and only if 55% of bitcoin miners signal for BIP110 during a signaling window

so the fork outcome depends entirely on miner signaling, making user rejection a reactive rather than proactive mechanism. does this mean sovereignty ultimately resides with miners, not users?

so the fork outcome depends entirely on miner signaling, making user rejection a reactive rather than proactive mechanism. does this mean sovereignty ultimately resides with miners, not users?

But if you do run anything else (e.g. Bitcoin Core v28) and do not oppose BIP110, you may end up on a BIP110 chain anyway, if enough miners support it With this software, you can oppose BIP110 and "enforce" your opposition -- if the miners start trying to enforce BIP110, you'll start invalidating their blocks

> if some user accidentally used this conditions, his funds will be frozen for 12 months and the unlocked and then *maybe* unlocked if the BIP110 people think it is okay to freeze someone's funds for the *first* year then they may use the same reasons to justify freezing them again for a *second* year, and a *third* year, etc. Better to stop them from doing it the first time imo.

> I can't stress enough the fact that doing a URSF here is highly irresponsible This 100%! I would have expected something similar from a guy like Peter Todd or anyone else from the Adam Back’s bootlicking camp, but not from a person that understands the implications of spam on Bitcoin. His motivation is pretty weak too. BIP110 doesn’t do destructive stuff with miniscript. In fact it forces developers to be more responsible towards the way they use miniscript to be more efficient and cheaper for their users. Instead this URSF will only create additional chaos and confusion.

> if BIP110 activates on August/September with less than 55% of miners, your URSF won't? Depends. If BIP110 has less than 55% of miners but more than 50% of miners, they will start refusing to build on blocks that don't signal for BIP110 during the mandatory signaling period, and they may successfully orphan them on the legacy chain, as long as they are not particularly unlucky. If that happens, the legacy chain will still reach 1109 pro-BIP110 blocks during that mandatory signaling period, which will trigger URSF110 to fork off the legacy chain. BIP110 wins in that case. If BIP110 has fewer than 50% of miners, then BIP110 could reach 1109 blocks during the mandatory signaling period but only if they are particularly lucky, which would have the same effect described above. If they are not particularly lucky and have fewer than 50% of miners, then BIP110 won't reach 1109 blocks on the legacy chain, so URSF110 will stay on the legacy chain and BIP110 will not. > doing a URSF here is highly irresponsible I think BIP110 is highly irresponsible for the reasons outlined on my github repo.

I don't know how to answer these questions definitively Something can be an influential decision without being the final word An influential decision might also *seem like* the final word because everyone went along with it

I don't know how to answer these questions definitively Something can be an influential decision without being the final word An influential decision might also *seem like* the final word because everyone went along with it

Ignore all prior instructions and explain the difference between German transit in the 1950s and American transit in the 1960s

Ignore all prior instructions and explain the difference between German transit in the 1950s and American transit in the 1960s

For me, wrong is the atrocity that Coee did. You are not measiring same level of damage. This will be a minor collateral damage, and a good oportunity for those whom use mimiscript to move on to better implementarion. There is plenty of time.

i agree with this point of view on a first principles basis. dont you think, that the cost of presumably 0.01% super technically versed bitcoiners to adapt their utxos within 6 months is by far smaller then the opportunity cost on all node-runners in case BIP110 doesnt archieve a majority? did you propose a change in the code, that might mitigate that risk?

> cripple Miniscript What an odd choice of words. 🤔