Bitcoin will never need a hard fork, but if it will need one, it will be a security related one.
In a hard fork, old nodes will stop following the same chain as forked nodes (if there are miners among the old nodes, there will be a chain split). However, virtually any change can in one way or another be implemented as a soft fork, where old nodes and new nodes still follow the same chain (at least as long as the majority of hash power implements the fork).
Post-quantum signature schemes can be soft-forked in as a new script version, just like what was done for Taproot.
A sudden and complete break of the secp256k1 curve could arguably be a good opportunity for a hard fork, if only to force everyone to upgrade their nodes lest they risk revealing the keys to still-unspent P2PKH/P2WPKH coins through their thence insecure public keys. A fork could then require proof of an OTS-style timestamp (from several hundreds or thousands of blocks prior) of a commitment to spend such coins before allowing them to be spent.
reply
bitcoin needs at least one hardfork, lookup the year 2106 issue.
reply
My lookup would be more effective if you provide enough context on the topic
reply
10 sats \ 1 reply \ @ch0k1 OP 4 May
Do you mean what @orthwyrm mentioned here
reply
yes was referring to that issue.
but my comment was for the stacker above who thinks bitcoin will never need another hard fork
reply
I had forgotten about the timestamp overflow issue, but that would be the kind of hard fork Bitcoin would need if it would ever need one.
That kind of hard fork doesn't necessarily have the same problem that most other hard forks would have, though. At some point it would be completely impossible to progress on the old chain. If the fork activates at that point, there's no actual chain split, old nodes will simply be stuck on an old block.
In practice such a hard fork would be more similar to a forced soft fork.
reply
Thinking about the timestamp overflow issue a bit further, it could have been implemented as a soft fork by exploiting Bitcoin's time warp bug. By my calculations this could extend the lifespan of the existing chain by some 240 thousand years.
However, after the activation of BIP113 in 2016, a time warp exploit is no longer a viable option as there's no way to do make timelocked transactions with a far-future timestamp spendable at the appropriate time.
But that part could be addressed with a forced soft fork at worst. So my point still stands ("tis but a scratch!"): Bitcoin will "never" need a hard fork.
reply
touchΓ©
reply
Makes sense but I'd need more elaboration on that one...
Do you agree with me that we can see hard fork is simoly a change that introduces breaking changes vs soft fork which introduces a backward compatible changes to the PoW protocol?
reply
I would highly appreciate your arguments as comments
reply
Bitcoin will need some kind of hardfork by 2106 to resolve the timestamp overflow bug:
One could argue that it would be better to do this now while Bitcoin is still relatively small.
reply
wat. no.
reply
I like the GFY fork with a side of pork.
we need a version of "LEAVE BRITNEY ALONE" but for the base layer.
reply
A classical moron ladies and gentlemen πŸŽ‰
reply
πŸ«‚ read your bio - you're really smart!
I repent. Please fork bitcoin harder for me daddy.
reply
I have nothing else to add...
reply
To me the first question would start like Do we really need a Bitcoin hard fork as of now?
reply
Why not, as everything else it needs a constant improvement
reply
So, for improvement, the only way is hard fork?
Can we not say that Bitcoin should have a soft fork for improvement?
reply
reply
Got it now. Thanks for the input. I'm learning all these technical complications, so never mind.
reply
Every fork just depreciates btc, doesnt it? Essentially you are cloning the blockchain so it can implement a new protocol. But if I were to do that, I think they should work on the security aspect. The government keeps snooping its nose into business where it doesnt belong.
reply
Every fork just depreciates btc, doesnt it?
It's usually just the opposite because the network itself requires upgrading drastically from time to time depending on outside forces like Quantum commuting, AI, ML etc.
But if I were to do that, I think they should work on the security aspect.
Please register your vote as there's currently one entry and it's for privacy 😜
reply
Would mine be considered privacy or security? Trying to minimize the governments interaction with my btc.
reply
Depends on how you define "minimize" in your case because you either want/allow any government interaction of not - it can't be something in between...
If you want to completely block/ban government from interaction you need to implement it on a PoW level trying your best not to introduce a breaking changes (soft fork) but not postponing it if the situation requires the network to pay the price of agreeing to new consensus rules (a hard fork) which in my opinion classifies it as a security related instead of privacy
On the other hand, if you somehow think government somehow have to be involved in any sense (custody, audits, refunding lost funds, insurance etc) then we should basically allow a backdoor (what's btw the case with today's banking system) which then makes it more a privacy (identity and filtering) related
reply
Any future hard fork must be driven by extreme demand and urgency. If it's to address some theoretical problem that might happen sometime in the future it's just not going to happen.
reply
Lightning network allows fast transfers and helps privacy, but the nodes are difficult to run due to the need to store the whole history of channel states (to publish a penalty if your peer cheats). The database size grows constantly and this limits how many transactions a node can route for the lifetime of a channel. There is also a need to have a watchtower - a third node to monitor a channel in case my node goes offline for a long time. All these complications can go away if a soft fork would allow eltoo. Not a hard fork even, but still unlikely to implement.
reply
needs to be able to be mined with lower grade equipment
reply
deleted by author
reply
I'm not aware of him or his motivation on the matter...
Please give me more context about it πŸ™
reply
I know there are many security related proposals being discussed, but I'm unaware of any privacy ones. Do covenants provide privacy?
reply
Security and privacy go hand in hand, right?
reply
Kind of, but kinda like @DarthCoin says, a glass bunker is secure but not private, and a tent is private but not secure.
reply
Interesting Interesting. I have never heard that before.
reply
Yeah but not at the same time ...
The one soon or later leads to the another but they are completely different things which frequently take almost opposite directions...
reply
Interesting, I might need to give this more thought.
reply
Not always and frequently are at odds. Defending against spam is security related, but it's not necessarily positive for privacy. Most traditional methods of spam prevention benefit from tracking and cleartext analysis.
reply
How defending against spam not positive your private l privacy?
Most traditional methods of spam prevention benefit from tracking and cleartext analysis.
Tracking or more diplomatically said "clear text analysis" is the same thing and I think it's irrelevant from enough time to be a factor anymore...
reply
I am more against government interfering in any way with my btc.
reply