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.
Replies (33)
It sounds like Coretards will have ABSOLUTELY NOTHING TO FUD ABOUT...!!!
CAN'T WAIT FOR THE NEXT DRAFT OF BIP4444 😎😎😎
LONG LIVE BITCOIN
SUPPORT BIP444...!!!
View quoted note →Thank you for your work. This seems promising.
Sounds reasonable. Thank you for writing the BIP. 🤙
Thank you for your work.
If a consensus builds around fixing the spam which abuses Bitcoin wouldn't it be possible to make the fix permanent?
Because both sides actually state they are against spam.
Thank you Fren of #Bitcoin….
Thank you for your efforts to keep Bitcoin the best money. As a fellow bitcoiner, I'll do what I can to support that
Thanks for stepping up!
Thank you for putting this together.
I think it’s smart to look at this holistically.
The legal risks are real, but Bitcoin users need to do the right thing because we hold ourselves accountable, not because the Tyrannical State tells us to behave a certain way.
The economic, technical, ethical, and reputational risks of more unnecessary arbitrary data on Bitcoin are just as real and threatening in their own ways.
Vigilance & cooperation are key and it’s important that Bitcoin defends itself with smart limitations on a consensus and policy level as best we can.
Mitigating Op_Return and Inscription data are both obvious priorities.
Looking forward to the next draft! Thanks again.
Godspeed. ✊🏼🫡
One side is lying
It's possible.
You can't remove the reactive activation method, and say it may be needed anyway. This is an attempt to manufacture consent.
View quoted note →Some people on the other side say they don't like "spam", but only the spam that's not theirs.
Important to call out Dathon Ohm is now lying (misleading?) the consensus process by removing the rejected langauge about a reactive activation method, but may have to employ it anyway?
It'll get circulated once the new proposal comes out, deceit is not how you build rough consensus.
nevent1qqszllafk56y6mwwch9w3eu6u48dzn0wrmfdynlftlrhky3uy56tu8c0c6dc5
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?
Thanks for all the good work!
Shouldn't a reactive soft fork be the priority?
👀
No expiration, permanent restriction of arbitrary data.
Include Unix bug fix
💪🏿💪🏿
hi -- we were trying to zap you -- but it looks like you haven’t set up a NIP-05 or ⚡ lightning address yet — grab one free at
Rizful: Lightning Services
Free Lightning vaults, and instant, disposable Lightning Nodes.
.. then pls reply here and we will try zapping you...
The whole thing is retarded but yes remove the most retarded thing first by all means.
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)
I do not support the rules in BIP444 on a permanent basis.
so, what, we'd need to do another soft fork later to revert them?
Reverting a softfork without an upfront expiry is a hardfork
testing zaps for this note… we made six attempts to⚡zap this note, at mix@fountain.fm, over a period of 21 minutes. all six attempts were successful. please check on your end to be sure you received. average zap time was 8996ms (9 seconds). we consider this zap time slow... generally, zaps should complete in under two seconds. (other nostr users might think your zaps are broken, might not zap you again.) if you wanted to fix this... you could try getting a free rizful lightning address --
Rizful: Lightning Services
Free Lightning vaults, and instant, disposable Lightning Nodes.
... if u get it set up, pls reply here so we can do this ⚡zap test again.
see? there's no fucking way the reactive activation part will hold up. that is not what bitcoin is. look at how knots are losing nodes to v30!
the fact that this even got released at all, with the blessing of Luke too (
Luke Dashjr
The whole concept (as I originally designed it) was for an emergency/reactive UASF. I
) showed how these people are so detached from reality...
get out from that basement of yours, talk to actual human beings, stop living in your bitcoin knighthood fantasy, touch some grass... that will surely help!
View quoted note →If it expires, an attacker knows the block to attack. I don't see how it fixes the problem, just delays it.
I think "Reactive" is necessary.
Can you explain your reasoning?
Right now we need a reactive measure, not a protracted one! This softfork was initiated precisely for the emergency CSAM use case. I think there is no need to compromise on an emergency softfork.
Aside from that, I think the presence of the reactive softfork option will push consensus more towards a preactive softfork, which is good.
The long-term, more cautious action can be discussed later; that is a time-consuming topic.
The question isn't how we ship it, it's when the problem becomes undeniable enough that the entire network wants to ship it. That's the trigger.
