You can soft fork in a hash function. There is no need for a hard fork to switch from SHA256 to say MD6. Just commit to the new hash outputs in a block. Nodes enforcing old consensus won't see them, nodes enforcing new consensus will require the new hash outputs match. This tightens consensus so is a soft fork. On Fri, Dec 12, 2025, 07:41 Possibly wrote: > By then we will have to make a hard fork to move to a new hash algo > anyway. When we will, we'll likely change the whole structure of the block > header, including likely switching to u64 timestamps. > > > On December 8, 2025 7:43:35 PM GMT+01:00, "אושר חיים גליק" < > osher.gluck@gmail.com> wrote: > >> Subject: [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 >> Migration >> >> Hello Bitcoin Developers, >> >> I would like to open a discussion about a long-term but critical issue: >> Bitcoin's timestamp overflow in 2106. >> >> # Bitcoin Year 2106 Problem: A Call for Proactive Action >> >> ## The Problem Explained >> >> Bitcoin's block timestamp field is stored as a **32-bit unsigned integer >> (uint32)**, representing Unix time in seconds since January 1, 1970. This >> design choice creates a critical limitation: >> >> **Maximum value: 2^32 - 1 = 4,294,967,295 seconds** >> **Overflow date: February 7, 2106, at 06:28:15 UTC** >> >> ### Technical Impact >> >> When the timestamp overflows, several critical failures will occur: >> >> 1. **Block Validation Failure** >> - Nodes will reject blocks with timestamps >= 2^32 >> - The blockchain will effectively halt >> - No new transactions can be confirmed >> >> 2. **Difficulty Adjustment Breakdown** >> - Difficulty calculation relies on accurate timestamps >> - Overflow will corrupt the difficulty adjustment algorithm >> - Mining becomes unpredictable or impossible >> >> 3. **Time-Locked Transactions** >> - nLockTime and CheckLockTimeVerify (CLTV) will malfunction >> - Smart contracts with future dates will fail >> - Any financial instrument using time-locks post-2106 is broken >> **today** >> >> 4. **Median Time Past (MTP)** >> - Network consensus relies on MTP for validation >> - Overflow corrupts this mechanism entirely >> >> ### This Isn't Theoretical - It's Financial Reality >> >> Consider this: **Any Bitcoin-based financial instrument with maturity >> dates beyond 2106 is fundamentally broken RIGHT NOW.** >> >> - 30-year bonds issued in 2080? Broken. >> - Inheritance time-locks? Broken. >> - Long-term smart contracts? Broken. >> - Pension funds holding BTC? At risk. >> >> A child born today will be **81 years old** in 2106. This is their >> retirement, their inheritance, their financial future. >> >> --- >> >> ## Why We Must Act NOW >> >> ### The Hard Fork Timeline Reality >> >> Implementing a hard fork is not a quick process. Conservative estimates: >> >> - **2-3 years**: Community discussion, BIP drafting, consensus building >> - **2-3 years**: Code development, rigorous testing, testnet deployment >> - **3-5 years**: Gradual adoption, getting miners and nodes to upgrade >> - **1-2 years**: Safety buffer for stragglers >> >> **Total: 8-13 years minimum** >> >> ### The Market Confidence Problem >> >> Even if we *technically* have until 2106, the **market** won't wait that >> long: >> >> - **2080s-2090s**: Financial institutions will start pricing in the risk >> - **2090-2100**: Uncertainty will severely impact Bitcoin's value >> - **2100-2106**: Potential panic and loss of confidence >> >> If we wait until 2090 to start the process, we're already too late. The >> shadow of the deadline will damage Bitcoin's credibility as "digital gold" >> and a store of value for generations. >> >> ### The Governance Challenge >> >> Bitcoin's consensus model means we need: >> - Agreement from Core developers >> - Buy-in from major mining pools (>90% hashrate) >> - Node operators to upgrade (thousands of entities) >> - Exchange and wallet provider coordination >> >> **This takes TIME.** The SegWit activation took years of debate, and that >> was a soft fork. A hard fork is more challenging. >> >> --- >> >> ## Proposed Solution: Migrate to uint64 >> >> ### The Cleanest Path Forward >> >> Upgrade the timestamp field from 32-bit to 64-bit unsigned integer. >> >> ### Technical Specification >> >> Current: uint32 timestamp (4 bytes) >> Proposed: uint64 timestamp (8 bytes) >> >> New maximum: 2^64 - 1 seconds >> New overflow date: Year 292,277,026,596 CE >> >> ### Implementation Details >> >> 1. **Block Structure Change** >> - Increase timestamp field from 4 to 8 bytes >> - Maintains Unix epoch (Jan 1, 1970) as reference point >> - Backward compatible with all timestamps before 2106 >> >> 2. **Activation Mechanism** >> - Set activation height (e.g., block 1,000,000 after consensus) >> - All blocks after activation height MUST use uint64 >> - Pre-activation blocks remain uint32 (no historical rewrite needed) >> >> 3. **Validation Rules** >> - Post-activation: nodes reject blocks with uint32 timestamps >> - Pre-activation blocks grandfathered in >> - Clear flag day for the transition >> >> 4. **Node Requirements** >> - All nodes must upgrade before activation height >> - Non-upgraded nodes will fork off the network >> - Clear communication campaign 2-3 years before activation >> >> ### Why This Solution? >> >> **Pros:** >> - Solves the problem for 292 billion years >> - Aligns with modern Unix timestamp standards (already uint64) >> - Simple, clean, understandable solution >> - No complex workarounds or technical debt >> - One-time fix, done right >> >> **Cons:** >> - Requires hard fork (network-wide upgrade mandatory) >> - Breaks backward compatibility with non-upgraded nodes >> - Needs strong consensus from community >> >> ### Why Hard Fork Is Acceptable Here >> >> Hard forks are serious, but they're **not unprecedented**: >> - Bitcoin has successfully executed hard forks before >> - We have **80+ years** to plan and execute perfectly >> - The alternative (doing nothing) is **complete system failure** >> >> This isn't a contentious change like block size debates. This is >> **infrastructure maintenance** - fixing a known time bomb that everyone can >> agree on. >> >> --- >> >> ## The Risk of Inaction >> >> **Scenario: We Wait Until 2090** >> >> - 2090: "We should really address this..." >> - 2092-2095: Contentious debates about the solution >> - 2096-2100: Development and testing (rushed) >> - 2101-2104: Slow adoption, resistance from some miners >> - 2105: Panic. Bitcoin price crashes as deadline looms >> - 2106: **Catastrophic failure** >> >> **Scenario: We Act NOW** >> >> - 2025-2027: Calm, rational discussion and BIP approval >> - 2028-2031: Thorough development and extensive testing >> - 2032-2037: Gradual, coordinated rollout >> - 2038+: Activation with 99%+ network support >> - 2106: Non-event. Bitcoin continues strong for our grandchildren >> >> --- >> >> ## Call to Action >> >> **We are building a financial system for our children and >> grandchildren.** We cannot leave them a ticking time bomb. >> >> Bitcoin's strength is its long-term thinking. We plan for decades, not >> quarters. A hard fork is not the end of the world - **it's responsible >> maintenance of critical infrastructure.** >> >> The time to act is now, while: >> - The community is large and active >> - We have decades to get it right >> - There's no panic or pressure >> - We can build consensus calmly and democratically >> >> **I propose we begin formal discussion of a BIP for uint64 timestamp >> migration.** >> >> --- >> >> ## Next Steps >> >> I am seeking: >> 1. **Feedback** from Core developers on technical approach >> 2. **Community discussion** on timeline and activation strategy >> 3. **Formal BIP drafting** if there is support >> >> This is not about panic - it's about **responsibility to the future**. >> >> --- >> >> **Discussion welcome. Let's solve this the right way, while we still have >> time.** >> >> Best regards, >> Asher Haim >> >> -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/8061ABAF-4AD4-4358-B6AC-8DD8C808D507%40gmail.com > > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BW8c%3DCocE-T-uKRmLPH6fzL_dr38iW2VU-3Z9OaWA9Z5A%40mail.gmail.com.