From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 12 Dec 2025 04:41:12 -0800 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vU2SM-0007YX-Uo for bitcoindev@gnusha.org; Fri, 12 Dec 2025 04:41:12 -0800 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-3f0cc00376dsf1678925fac.0 for ; Fri, 12 Dec 2025 04:41:10 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765543265; cv=pass; d=google.com; s=arc-20240605; b=HLTgxYsa4xXKOmjsMVT1C0zBIJ1OH1G6NrrjA8f3F0FyLBBthjnu02riUxN8vFluUM Oxr66czPKdefvBNXqpX5fF2UhVFjfItrbfWjPSdie5vvjimf7EYnDnscSLtQRLgY2pSf nKQEtAs+CB2Wame+RSpLPRiDsppIzFlC+b0mdPcMLxrtQ6HnrJ4ZTfzhSDQ7aDBgUWfv fFX4pnvhuiqbyEf0v5p5qxuJC+70LgxQHQSNQehqynkba3jLO6lLtxaQvSiNfFuM1F60 EP4u0VGKXOP9lkjiH3mzFnBxP+5ktSqGAnjNF5w+EmKuvCKXF4d8G+YB5+DrKNzoPjua 0WCw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding :mime-version:message-id:references:in-reply-to:user-agent:subject :to:from:date:sender:dkim-signature:dkim-signature; bh=cdmqi8qkAEIJM9pQrWLVpIu0Uve1mOBeP9ziWlxWghA=; fh=e1L4ik60nTMzn468COEclDeIyFDAPUgwJYuAMBDGHkE=; b=Vni8p9FioATLWIKWCb/+DVBOs+AKENNAVCNFu9Rt1tm08Oc9VLAe/oWFBQnUo7VNpd OFBXBhPTgkY+HCQhPpqVncEDDOO+NmyEf8rHusrMd6n0OQibQCXwdV+9d1ypdp0njFOh UQxnCrWmlcPaQzkT9u0vjTgnClr6Df379Uls2sap4bNXCXzTF8ym4BbaR2Ncahyx4DTG zP432lNRQCOBKC6TyPgL2Xh5iczODwcSzOSKmEf7111q979339Fc+heYjCNKGM/nlIdS utFJ5jzD3GCGf90dl17UWbV/d/Z35hkcws71F1KkeIGrA7jErv01LYkO0lti82Jm8fhy 06kA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=NM0gfr1c; spf=pass (google.com: domain of zelatyna123@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=zelatyna123@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765543265; x=1766148065; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:mime-version:message-id :references:in-reply-to:user-agent:subject:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=cdmqi8qkAEIJM9pQrWLVpIu0Uve1mOBeP9ziWlxWghA=; b=kiyXUAZdPIX5TSWjjefZcfgx4CH6I0BNrItiGa3lp9C84gLzP0RuxxDNqKtxC2kW2m e3QCXwi3AXke96LcZthJwb/k4Nn2661VmS8PUhKNiWpuQchNZObQ8VC30GhLCA50uh44 vWmWyruZaodgtE2Btfj/plis2mjCZI/UGBvsEx23O+mHusf/Z2VhdDlK62vDLp8x1fFl kSifWDUxXLkfGeba1WgV1ao4axFv1oV8lophiMMncDvG/ZnYs3H4qJF8HyDuhsrjdRSr iY1XmjQn1q6gGDsWWEEBByNKRlY3vRZXwejAZOkLRkaVuPZ6/rtWf7BDg4KX5A/x4qY+ hBFQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765543265; x=1766148065; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:mime-version:message-id :references:in-reply-to:user-agent:subject:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=cdmqi8qkAEIJM9pQrWLVpIu0Uve1mOBeP9ziWlxWghA=; b=C3HYGz7OfEofPSFWa46kDUR1naXKlPB0iEqxaZhCoZBEJZIBrVTowi1Hg6BYbeTFM2 HL/8JaJb5WDAEoBEyE4KeDgdDUtGt8YQBFGVyFuA8R/g0ukUEIiTHT138tL35dDca57e my12mKDm4a3KB/eIPBNUeBIkWR0IspEGGSWoXctsNRB0gUpyrB0ayCgPjfbNIFkeVyz9 Ml4J9qT4URf5jE013Lti2bgoDrRxiSc4oKGFohvePHVB4BMORH58HagnFbn3/LhPlp+h b9zXXll0ThMN+aK1Y1dHKRF9oFXEdmX0Z/ouHlVP+59TZzqdKTd+EO6BORdSCUejwoOC wsoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765543265; x=1766148065; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:mime-version:message-id :references:in-reply-to:user-agent:subject:to:from:date:x-gm-gg :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=cdmqi8qkAEIJM9pQrWLVpIu0Uve1mOBeP9ziWlxWghA=; b=f/YgQiB13jaDQoBDDe6dh7IawqKM6fT3kYdSl1qv51wVQKZUCKIEjT5yEJOMNXxV0i KSpbWr0So9N9Zvi1iZwigQC/sdWcHigOG/fmVT4FFb38RawG3uUSXCmJC9pfxE3+pJAO h8s1yMxgSeToVoz1wE5IjhEki29N1iU/ShOK1hePDVxsbkTZoyimn4DBUlhYEZEi8WZt kzLFYA5wRasUNOhFcxySn5mKjcvy9CPWLNDuRGEoNORLCoJessDugDY1ZL4PQC5b2wak Aa3oCPd1t1/TY01D8tyR6/P8MgczOH/2BEVaWTNntxt9eAe5IWAVpqBwZa9VNcdIQrIV MePQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUU2u9vK2tacd5Bym3B7Os1HMjnWSDBZxt7Sspk3j7WZVlVP/mDAevJ6uJOsP86mSkIR4tDB8SR/png@gnusha.org X-Gm-Message-State: AOJu0YxZ3rX3tSNqv9+h4167cukynOEXmwgHSWITXmxmj0IUoIzWevD4 ooqizT1a/JpzNIJQhUWoXjQK3PsrOlQdqHxa/DQzrcet06Bvn/qcJPa4 X-Google-Smtp-Source: AGHT+IG274+zF55iX+lbMPiiTYPVja0S6DN1whswqc3DMOUi/GseJS8SIybW8yUw5qSGKregUH2zaw== X-Received: by 2002:a05:6870:1991:b0:3e8:8e56:6716 with SMTP id 586e51a60fabf-3f5f8991fdemr1176129fac.54.1765543264377; Fri, 12 Dec 2025 04:41:04 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWa+rbBKSnYhUpxqgUXye0FpVb6L0iluC8aqcDMuFQ2Zew==" Received: by 2002:a05:6871:81f:b0:3d5:92b8:657b with SMTP id 586e51a60fabf-3f5f83d7e01ls369929fac.0.-pod-prod-09-us; Fri, 12 Dec 2025 04:41:00 -0800 (PST) X-Received: by 2002:a05:6808:4f20:b0:450:dd66:6fad with SMTP id 5614622812f47-455ac9bceffmr902290b6e.64.1765543260258; Fri, 12 Dec 2025 04:41:00 -0800 (PST) Received: by 2002:a05:600c:15c3:b0:477:b663:eee5 with SMTP id 5b1f17b1804b1-47a8de0345bms5e9; Fri, 12 Dec 2025 04:25:49 -0800 (PST) X-Received: by 2002:a05:6000:2dca:b0:42f:9ec3:8a42 with SMTP id ffacd0b85a97d-42fb46db61emr2004806f8f.28.1765542347788; Fri, 12 Dec 2025 04:25:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765542347; cv=none; d=google.com; s=arc-20240605; b=LddtTTG3vYeJ3JhT68v+TbC9RsVqkbfeHr+vz0BiyFN15B+tCatah1U/joYzYDYH7y wPPCZ4ikEiGnEVxei1Ili3/21FSMHAVPDCtD0eaG9DZBg4DNxjG2xHJk1REeB6XYGguZ 1xBjg7Zn0jOIiHpoGxxUSwkF+4fBjMOSkoRQHGBE5ERv50pWxDD3gFoJryC81UvTqydC s9Nghk2wvctcnAaCzvNYcXkucmla40lzIq+XfG2rJ8fQYgEj5gaU0Ss22fqWG7g6OgUl dJTM+qQFPmhEu6RvhLq1UnTWTZrBtzgfRQqJuI9bdldYE1k4OxWG0Vn2ze7rtzgT4FX5 efMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:message-id:references :in-reply-to:user-agent:subject:to:from:date:dkim-signature; bh=FoclRyejggS3sx6mGAj6e790V0e6F7KDYhoUhxMpTDY=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=ZkHFSq3rlB8k9YrrVmGU9aoUR4mk1mBkrVsSqQ53FBCoa3dJoEeYA73oQFBGG0/V8v Lkdg6dZRqBXhEDPIa5KN1/j8+0y+veyugbCflnpzRzOZJkIu372fnSxBKN+8lbRJjVWV NlZInJDE9mUluQ2BSCBKgNQXglHQQDSmGEIw3VGe71/mvsY9C6QoBrcscsmf8x8FscS4 t2390xvy9CrM45UnmNtQfhFA4O3JOvIOhxBvypM8DE42nOOoAAaG4dmHs0J99LJJOd3K fBm/Zl8OJxUJvxCPYNP/gST73x+R05dsh23B5oDti/ycgsIf3apc2+39JNuMCR5fHdzj mSHQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=NM0gfr1c; spf=pass (google.com: domain of zelatyna123@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=zelatyna123@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com. [2a00:1450:4864:20::635]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-42fbae85baasi5387f8f.0.2025.12.12.04.25.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Dec 2025 04:25:47 -0800 (PST) Received-SPF: pass (google.com: domain of zelatyna123@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) client-ip=2a00:1450:4864:20::635; Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b7636c96b9aso193599066b.2 for ; Fri, 12 Dec 2025 04:25:47 -0800 (PST) X-Gm-Gg: AY/fxX5OelLmMn7u6oariHVrefS3ceJkS8D9I6CF/oUMfLpKHrRu16YyhIx3s2jfKNT CJjM+/Esn3Dhn82fQsdZzCLE1tWK8XCiXdukNYFeiN7EA7+Bh0yVXKFTAIgfUD75jnBLPNe9c3D VChWv07IW1UIOyBvXqkT2Wg5YyQWjvd7Inu32nscojguyelACV2b2aipRewPaASOMDBp21s6TAw PuYF13qTDG9Qo1GOGaIGjkIAHvLSTEtc7+KO1wTwry2Sc+a6M9y4k3oPE0Vt7Nvis9YpyV8DWyc H1EN9Wsd7/ezKyPpiiI/shARYa07upQPiW5jTmAUht3CaaQDtBtKgK7FNKYNCs7PJz6BLKIJvU4 jZbXBkHxRBtbs5Jg6fpIyHwyygbU8BQLMfD0kHd82oHFP8Zidny7v6clZ9Uu1lu0xQF8nlwXfvn fI1i0Ewix+cAtCb4bong+IGpUata1uEqkIAkWSSsQ8kyEKwNRTpwRnjxGThyvLzL4kow== X-Received: by 2002:a17:907:7ea5:b0:b7c:e3ad:cd17 with SMTP id a640c23a62f3a-b7d237756edmr207870566b.32.1765542347087; Fri, 12 Dec 2025 04:25:47 -0800 (PST) Received: from ehlo.thunderbird.net (user-109-243-211-218.play-internet.pl. [109.243.211.218]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b7cfa5d0b2csm552289266b.66.2025.12.12.04.25.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Dec 2025 04:25:46 -0800 (PST) Date: Fri, 12 Dec 2025 13:25:44 +0100 From: Possibly To: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration User-Agent: Thunderbird for Android In-Reply-To: <4355092f-4cd6-4e3f-9ae8-4823183ca731n@googlegroups.com> References: <4355092f-4cd6-4e3f-9ae8-4823183ca731n@googlegroups.com> Message-ID: <8061ABAF-4AD4-4358-B6AC-8DD8C808D507@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----YE1KS1LRV8SVA4N1RTAHHHXDDYCTPE Content-Transfer-Encoding: 7bit X-Original-Sender: zelatyna123@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=NM0gfr1c; spf=pass (google.com: domain of zelatyna123@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=zelatyna123@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.4 (/) ------YE1KS1LRV8SVA4N1RTAHHHXDDYCTPE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, "=D7=90=D7=95=D7=A9=D7=A8 =D7=97= =D7=99=D7=99=D7=9D =D7=92=D7=9C=D7=99=D7=A7" wrote: >Subject: [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64= =20 >Migration > >Hello Bitcoin Developers, > >I would like to open a discussion about a long-term but critical issue:=20 >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= =20 >(uint32)**, representing Unix time in seconds since January 1, 1970. This= =20 >design choice creates a critical limitation: > >**Maximum value: 2^32 - 1 =3D 4,294,967,295 seconds** =20 >**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 >=3D 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 date= s=20 >beyond 2106 is fundamentally broken RIGHT NOW.**=20 > >- 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=20 >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 = =20 >- **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= =20 >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=20 >shadow of the deadline will damage Bitcoin's credibility as "digital gold"= =20 >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= =20 >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=20 >**infrastructure maintenance** - fixing a known time bomb that everyone ca= n=20 >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.**= =20 >We cannot leave them a ticking time bomb. > >Bitcoin's strength is its long-term thinking. We plan for decades, not=20 >quarters. A hard fork is not the end of the world - **it's responsible=20 >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=20 >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= =20 >time.** > >Best regards, >Asher Haim > >--=20 >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= /4355092f-4cd6-4e3f-9ae8-4823183ca731n%40googlegroups.com. --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 8061ABAF-4AD4-4358-B6AC-8DD8C808D507%40gmail.com. ------YE1KS1LRV8SVA4N1RTAHHHXDDYCTPE Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
By then we will have to make a h= ard fork to move to a new hash algo anyway. When we will, we'll likely chan= ge the whole structure of the block header, including likely switching to u= 64 timestamps.


On= December 8, 2025 7:43:35 PM GMT+01:00, "=D7=90=D7=95=D7=A9=D7=A8 =D7=97=D7= =99=D7=99=D7=9D =D7=92=D7=9C=D7=99=D7=A7" <osher.gluck@gmail.com> wro= te:
Subject: [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Mi= gration

Hello Bitcoin Developers,

I would like to open a disc= ussion about a long-term but critical issue: Bitcoin's timestamp overflow i= n 2106.

# Bitcoin Year 2106 Problem: A Call for Proactive Action
=
## The Problem Explained

Bitcoin's block timestamp field is stor= ed as a **32-bit unsigned integer (uint32)**, representing Unix time in sec= onds since January 1, 1970. This design choice creates a critical limitatio= n:

**Maximum value: 2^32 - 1 =3D 4,294,967,295 seconds**  
*= *Overflow date: February 7, 2106, at 06:28:15 UTC**

### Technical Im= pact

When the timestamp overflows, several critical failures will oc= cur:

1. **Block Validation Failure**
   - Nodes will re= ject blocks with timestamps >=3D 2^32
   - The blockchain w= ill 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 become= s unpredictable or impossible

3. **Time-Locked Transactions**
&nb= sp;  - nLockTime and CheckLockTimeVerify (CLTV) will malfunction
&n= bsp;  - 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 relie= s 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 i= ssued 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 Mu= st Act NOW

### The Hard Fork Timeline Reality

Implementing a = hard fork is not a quick process. Conservative estimates:

- **2-3 ye= ars**: Community discussion, BIP drafting, consensus building
- **2-3 ye= ars**: 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 minimu= m**

### The Market Confidence Problem

Even if we *technically= * have until 2106, the **market** won't wait that long:

- **2080s-20= 90s**: Financial institutions will start pricing in the risk
- **2090-21= 00**: Uncertainty will severely impact Bitcoin's value
- **2100-2106**: = Potential panic and loss of confidence

If we wait until 2090 to star= t the process, we're already too late. The shadow of the deadline will dama= ge Bitcoin's credibility as "digital gold" and a store of value for generat= ions.

### The Governance Challenge

Bitcoin's consensus model = means we need:
- Agreement from Core developers
- Buy-in from major m= ining pools (>90% hashrate)
- Node operators to upgrade (thousands of= entities)
- Exchange and wallet provider coordination

**This tak= es TIME.** The SegWit activation took years of debate, and that was a soft = fork. A hard fork is more challenging.

---

## Proposed Soluti= on: Migrate to uint64

### The Cleanest Path Forward

Upgrade t= he timestamp field from 32-bit to 64-bit unsigned integer.

### Techn= ical Specification

Current: uint32 timestamp (4 bytes)
Proposed: = uint64 timestamp (8 bytes)

New maximum: 2^64 - 1 seconds
New over= flow date: Year 292,277,026,596 CE

### Implementation Details
1. **Block Structure Change**
   - Increase timestamp field f= rom 4 to 8 bytes
   - Maintains Unix epoch (Jan 1, 1970) as re= ference point
   - Backward compatible with all timestamps bef= ore 2106

2. **Activation Mechanism**
   - Set activatio= n height (e.g., block 1,000,000 after consensus)
   - All bloc= ks 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
&nb= sp;  - Clear flag day for the transition

4. **Node Requirements= **
   - All nodes must upgrade before activation height
&nb= sp;  - Non-upgraded nodes will fork off the network
   - = Clear communication campaign 2-3 years before activation

### Why Thi= s Solution?

**Pros:**
- Solves the problem for 292 billion years<= br>- Aligns with modern Unix timestamp standards (already uint64)
- Simp= le, clean, understandable solution
- No complex workarounds or technical= debt
- One-time fix, done right

**Cons:**
- Requires hard for= k (network-wide upgrade mandatory)
- Breaks backward compatibility with = non-upgraded nodes
- Needs strong consensus from community

### Wh= y Hard Fork Is Acceptable Here

Hard forks are serious, but they're *= *not unprecedented**:
- Bitcoin has successfully executed hard forks bef= ore
- We have **80+ years** to plan and execute perfectly
- The alter= native (doing nothing) is **complete system failure**

This isn't a c= ontentious change like block size debates. This is **infrastructure mainten= ance** - 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 deb= ates 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 discuss= ion and BIP approval
- 2028-2031: Thorough development and extensive tes= ting
- 2032-2037: Gradual, coordinated rollout
- 2038+: Activation wi= th 99%+ network support
- 2106: Non-event. Bitcoin continues strong for = our grandchildren

---

## Call to Action

**We are build= ing a financial system for our children and grandchildren.** We cannot leav= e them a ticking time bomb.

Bitcoin's strength is its long-term thin= king. 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 f= ormal discussion of a BIP for uint64 timestamp migration.**

---
<= br>## Next Steps

I am seeking:
1. **Feedback** from Core develope= rs on technical approach
2. **Community discussion** on timeline and act= ivation strategy
3. **Formal BIP drafting** if there is support

T= his 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8061A= BAF-4AD4-4358-B6AC-8DD8C808D507%40gmail.com.
------YE1KS1LRV8SVA4N1RTAHHHXDDYCTPE--