pull down to refresh
174 sats \ 12 replies \ @jeff 23 Oct 2023 \ on: "If all the people around tells you that you’re drunk - maybe you're just drunk" bitcoin
I think we should plan a fork that is set to launch ~12 years from now, that attempts to address the security budget challenge.
If you do it far enough out, it's not a shock to the market nor miners, and can serve as an expected dividend, rather than an unknown cliff-like risk.
There are lots of ideas, but all are contentious.
I would support this. At a minimum, I think we should at least be having the conversation and let the community come up with a contingency plan.
reply
Go ahead and fork. Not running it on my node, though.
reply
Exactly. Love it.
reply
The interesting thing is to talk through these possibilities now, so they can be vetted, attacked, hardened. It would be dumb to mess w/ stuff that isn't broken. But it would be equally dumb to close your eyes and pretend that everything will invariably be fine.
I can see a tail-emission fork getting launched when / if things start getting dodgy. In fact, a number of forks will be launched, with different capabilities and tradeoffs, between now and that day. It will be quite the clusterfuck trying to keep them straight -- perhaps we'll also have some kind of meta-system that replays transactions across all relevant chains for people who don't want to gamble and commit a-priori to some vision.
This would be an interesting use case to think through in detail. Has anyone ever written on it?
reply
perhaps we'll also have some kind of meta-system that replays transactions across all relevant chains for people who don't want to gamble and commit a-priori to some vision.
That may be impossible, e.g. if fork A is mining tail emission coins that fork B isn't; you can't map those coins onto fork B where they don't exist.
reply
I think they are talking about pre-fork UTXOs.
reply
a number of forks will be launched, with different capabilities and tradeoffs
No need to have clusterfuck of forks trying, because in my opinion that's the most simple way to handle it:
If we would have four years long network difficulty regression - then it's emergency, and new code handling such danger - should delay halving to the next halving, until difficulty will recover
if there is no such emergency situation - there is no trigger, and old and new code would work together like a charm = so there is no hard fork at all
simple, conservative (and beautiful) solution in my opinion, so it fits to Bitcoin very well
such a solution is fueled 100% by free market only
and the natural inflation level is set by Bitcoin itself, on some certain, completely unpredictable level (so, free market in its finest)
reply
That's a good point.
If only forks off when the condition for delaying halving is met, and if it does, it does so for an arguably good reason.
Tail emissions may not address the issue at all if it crops up before they would kick in.
reply
No need to have clusterfuck of forks
I don't think anybody can stop forks. It comes down to market demand and social consensus.
reply
Thanks for the shitcoin dividend, arrogant retard
reply
I'd like to understand better, why it is arrogant to suggest planning something?
reply
A better scenario is when the vast majority understands...
reply