Replying to Avatar Dathon Ohm

After much discussion and consideration, I have decided to remove the reactive deployment method and the legal/moral motivations from the BIP document.

I still think those things are important and the reactive deployment may become necessary in an emergency, but I want to continue building consensus and those features were hampering progress.

I hope to have the new draft ready in the next day or two.

Thanks to everyone for your support so far.
Avatar
Luke Dashjr 2mo ago 💬 6

The whole concept (as I originally designed it) was for an emergency/reactive UASF. I'm not sure it makes sense any other way. For a non-eventful softfork, you'd want to start it 1-1.5 years into the future. And then with a 1 year expiry still?

Reply to this note

Please Login to reply.

Discussion

Avatar
nonymous 2mo ago

Why not separating both? 1.- Reactive/emergency UASF and 2.- UASF planned 1y ahead but permanent, not temporary.

I think Emergency UASF will have way less consensus around it and when/if the offending block happens IMO it will generate a split chain. The chain with the offending block will be considered bitcoin by most people (including miners, exchanges and businesses)

Planned UASF can have way more consensus around it. I think we could limit OP_Return to 80 in CR and also make inscriptions way more expensive. Maybe we could just remove the segwit discount, or at least, change the 4x to 2x (with the additional benefit of having blocks smaller)

Avatar
Luke Dashjr 2mo ago 💬 1

I do not support the rules in BIP444 on a permanent basis.

Avatar
Kajoozie Maflingo 2mo ago 💬 1

so, what, we'd need to do another soft fork later to revert them?

Avatar
Luke Dashjr 2mo ago 💬 1

Reverting a softfork without an upfront expiry is a hardfork

Avatar
flaming_hodl 1mo ago

If it expires, an attacker knows the block to attack. I don't see how it fixes the problem, just delays it.