From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 12 Dec 2025 05:54:47 -0800 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vU3ba-0000Q4-6A for bitcoindev@gnusha.org; Fri, 12 Dec 2025 05:54:47 -0800 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-3ec31d72794sf1994956fac.0 for ; Fri, 12 Dec 2025 05:54:45 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765547680; cv=pass; d=google.com; s=arc-20240605; b=cPhY3JMHp36wuR9hpXHqFtJjv2NVL+LIRYggYzaTUH0PX+BpFO5rGs4rbeWP9ytZp8 XlZ2burcsF9wVk/MhABqkr8TzXOtv8Nhs2BV16RSrBrWauN8n2AcN0AhMebI/pi4YpHT I7MInDeOSgnG9zZgI9psttALEmnfIohlT/QffKFJTbK38lodOKr+qE6QvF+apu3NyCcg ucEZG0OufXw0sJwGQWIS7pPKnFld2+xPekDdrjawUbXlgAAFo90eBprd7kPOAM5rKmBN c1eJGC9gjGWday8mrhU5Zr6GXlkdcBoH3uzNeVmeorm+WPz2fwj/T2JcX/617OyfoLh8 k7tw== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=DihF1/oYmUELm1+plOtDgz5Xp62gdSwJeLrNpDs+C6s=; fh=6BNE/BjXjS5QTcCl4BITRbzlov4qO9F4WNU8KLshhBM=; b=S27V9HDV8+EkXkUPhZmNGvTJ2zXUAeey1Q27lDbvreAwSI4YAqeydreyz7ZlL4rpAf S8ZUYyYrAPTFxr8Bq5uQLlmP/gqJkBI1EgAmt/rLDoE8TpurfBc9Hp5AoJqkSrvVHIem RXXMTCtP7kHDUgSUFyLNTxTKvrHV6j6LnHXEG9jcO75N94i95XgLkhQVLAYdpcSXV/h2 vBK+0JMnykGyzFpbdDWNOz9BMWO7dtdT9RZI45Fc8Gacgoe0YqAdwKLxAasOAvmg1EZn tMNghOW/amA4tWhqCHBQ0TLh0ee/vvZon4hTw7mifI7wY5yEhcJ9a0SpZb6LMhnet4Vj 7B6g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=G69p8fuO; spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=eth3rs@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=1765547680; x=1766152480; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=DihF1/oYmUELm1+plOtDgz5Xp62gdSwJeLrNpDs+C6s=; b=eOGwIFt4+enJvR+O6E1syLRotZSYikcCN7FuJnGNTATHdzrb6pxkZohTOZovC5uY/F 43fASUYoHtSHtXCTE833RwAUg91049rBKHpRfebra+hT7nzj6gaSXomx3XfMX/0YzwjA hcSGr9bxqFDod2aCeApsjJTQqpH+gsNX0YuFPbv2cU/e/MZWGOhLG+qQBysOibvreJjK nXm5b6A3xafAUe5p6IyEF5pMV8Rc55kNmlIURAJCLTgC0v1h0pTWNaDmvqoXUmEpLTIk lSqnzHBRbvoME0cKzhxGPnJSnzGvHwOyzlw/viBIzhD9IseNiNt56sBygIieLkYE36Jh Pp2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765547680; x=1766152480; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DihF1/oYmUELm1+plOtDgz5Xp62gdSwJeLrNpDs+C6s=; b=b65LSHzI6Suj0DTJSJxG4fOEMsw1f80UhJHfAP3PP3/drKAqwY8HH3wgHNYGt8ZNEv LoyQTFQqwtRJ7hKx/yF9dcCNd1QI2sIuHRQFcEcqUNsy4vPitR51zyQc/k9EfbXa42+H ka2sdUSqaok/tJOk2rqZ0NDp9Pl85xxza7y97QHVLxCgrMrkw5jvdan+W0YedSsqHLts axzCONZ8wMvbTJVsM3CZcWR+k5N4y7BBMMiCJWthtDBWzcCh8Ik2JGSSU1HilbmenOAP /R9dulULRjpcGhFZYoiyjm/tJWnaSTKGT60vpBJJEsKV6rmzvYRxmz7nLBc+oqSvoQ9h 9bTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765547680; x=1766152480; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=DihF1/oYmUELm1+plOtDgz5Xp62gdSwJeLrNpDs+C6s=; b=pZGajxVGrobwq2DmUlcNRCQ//vkxEMx8+eXE+lSib0kXcpINxj82Ms1GXWRx+3yoSU y0u2EMBCubUjgnvkOexw2GpJL9lusD/D0a4/1UWmrswKpLs2UBpjuuFPgvE4E8bS2wtM ewokWvwYK10oNCHU2vyDrWilYwUW0NZ3ONhy3PeI2xPUQ/mAa6b/renpemJJVZHGD4eM cPiYRpqB+Wf7TH9BSYWevk1M8CRIg1P3ELNelvBPn9DI3kw/fJYthuzGLMAj80cn0vtD 2ddAXsRljUZZjxPEIbLaXwnYnl8XPnf95xqxXaG/WC+MdNobApUNJHet0MwT52A5xtzY 3Vlg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWHQsNxbgaMEtnGUesvLaCA9rZLOXQI0KcTsZ8wTH48Usprvq9TCeTgiFEMgcVEPH0OfKVNAiT3YJ+Z@gnusha.org X-Gm-Message-State: AOJu0Yz39HcE913Zgf0E6fWH7vQmerjJunWdsgv8AezQomqHUfVy3ydO alliLtClSvuaPwCMAh7cGS703xFE3ojaM7OO2RnjuHMjd5lYombRxe3o X-Google-Smtp-Source: AGHT+IFliCC1k3Bd5VSCipi8ewd8WLBDLpVeEMvZXPezLB2wWx/1DH0LpJ+jTlD376z7UTqHDWRByg== X-Received: by 2002:a05:6820:4d0a:b0:659:9a49:8edc with SMTP id 006d021491bc7-65b45187cddmr734542eaf.16.1765547679668; Fri, 12 Dec 2025 05:54:39 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWaOk6Z3o1J6ESSHODrg4lH1UBwNWKh7YwypASKH01L0mQ==" Received: by 2002:a4a:e059:0:b0:656:6e71:161f with SMTP id 006d021491bc7-65b437f7661ls261719eaf.0.-pod-prod-00-us-canary; Fri, 12 Dec 2025 05:54:35 -0800 (PST) X-Received: by 2002:a05:6808:16a1:b0:441:c8a2:ba26 with SMTP id 5614622812f47-455ab5fa1cdmr774206b6e.7.1765547675690; Fri, 12 Dec 2025 05:54:35 -0800 (PST) Received: by 2002:a05:620a:72b7:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8bb213138e1ms85a; Fri, 12 Dec 2025 05:41:07 -0800 (PST) X-Received: by 2002:a05:620a:1905:b0:8b2:ea5a:414e with SMTP id af79cd13be357-8bb397de254mr284516385a.15.1765546866201; Fri, 12 Dec 2025 05:41:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765546866; cv=none; d=google.com; s=arc-20240605; b=Tmttdcyf9Nn40JR4nXn9e2nc6ZegVcAANTZG0td1Y5SxEiXj+wiqfucIP2GVAQpqBu cRlV8ndtACJ1w804zHk80qOhY29Y6TKt23k/3pgoWV1bqgOg7K/cM++XHpyCFPBSZ6TO dTdK4/jylj8Bd/bRm4+WWGlHhuYQLiSyNNAgFBbAH/d16OVEAdf6GlU+ZKcXywhbEnP0 HN2lSK0fXD8Kt4n6NFhoqli6VytIAR8+Fgc5OQfh0VZA4FEx/Dtt6qA0M8c0rTX7r23o 6nA4SGl1SAdZwD3RLSRO+LuPosAGyD3fpjpO79k1xQvooh2bYAWpFWEB3Mi9pLlkB5S3 yAeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=MjL7Fo/QiyYS3i6n/hENQ2Msxke9fd1jnPSCgrriiSY=; fh=Qg0Dm2O09boUjG+w4JNkBkgGNP5xi4XQSv2VzdkFLUk=; b=Uiz7Yn7pW3Jxca9etsUo2zVn+8IKdmoDHbniT6PWlizaHJuGhOpGKU/EXu9FGnVm1e V16nyRS2uzuj20DGUsQjj1TTREYMUX2AG1kI/vNqfxRcneuG128l1iexz86Vbwopdul4 nAEkeEeuqSGnyZWo/kvE6Uyxw0MWzASTIZyV9UVGpwjVOX1my6MdBsIwqu4H3oNy2MLL tMpPPTBC/Vcp1abnF3LJHS0O3ANsqXbZY8EKAClobg/OM+I69+TplxuIshthI8sc8Ibj UXCWEnDtJF+rx9RZWntcZbG/jXQJvrcD4x5iWeaCMfH2EsmiJLGMzcoDyyUUHZvHiYTS TFIQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=G69p8fuO; spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com. [2607:f8b0:4864:20::1033]) by gmr-mx.google.com with ESMTPS id af79cd13be357-8bab5677006si21604585a.3.2025.12.12.05.41.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Dec 2025 05:41:06 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) client-ip=2607:f8b0:4864:20::1033; Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-340bcc92c7dso673248a91.0 for ; Fri, 12 Dec 2025 05:41:06 -0800 (PST) X-Gm-Gg: AY/fxX7Hs0Y2PhEo7MJFl4xKSGi4rU689+GqxYOhCU6uDWm7eqxBRWAbP7oqYoVTxrv IGDCiK1iWFxOvbgkJSHjtSpKmLKOgAiLF+HaOJxrUZ0K6mw0wlOFrBjfEp93J/0KA6LzXUNjWfT DcZ0o4e19qHiAuh08DW59r8rvp5y6Sd7jVhVbslTqory5/woVqXw9d/ARAcMyIwE/5N4drRrH8C vH23fniPcL/cv1/Ifap9SoCuIp/4hSuFbt0isAGdxaZDLBBBmoPKLZ0my+YqN8JTI3zpcm4j2Wh AbuVQAk2yh/D/viWmcklz58iYH8OLG8kvxAyhT3pGSD5HYakEfphT6BrOly9ItL/MaY= X-Received: by 2002:a17:90b:4c90:b0:32e:23c9:6f41 with SMTP id 98e67ed59e1d1-34abdc6855emr2150480a91.5.1765546865018; Fri, 12 Dec 2025 05:41:05 -0800 (PST) MIME-Version: 1.0 References: <4355092f-4cd6-4e3f-9ae8-4823183ca731n@googlegroups.com> <8061ABAF-4AD4-4358-B6AC-8DD8C808D507@gmail.com> In-Reply-To: <8061ABAF-4AD4-4358-B6AC-8DD8C808D507@gmail.com> From: Ethan Heilman Date: Fri, 12 Dec 2025 08:40:55 -0500 X-Gm-Features: AQt7F2r_YkwfaAEYGoJEu9worQa15V47kZIs1Om9DVTZ6yWC7jwGrRmTeurJbh4 Message-ID: Subject: Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration To: Possibly Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000b94b9f0645c16933" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=G69p8fuO; spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=eth3rs@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 (/) --000000000000b94b9f0645c16933 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 bloc= k > 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" < > 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. Thi= s >> design choice creates a critical limitation: >> >> **Maximum value: 2^32 - 1 =3D 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 >=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 >> 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 gol= d" >> 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 tha= t >> 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 hav= e >> 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-8DD8= C808D507%40gmail.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/= CAEM%3Dy%2BW8c%3DCocE-T-uKRmLPH6fzL_dr38iW2VU-3Z9OaWA9Z5A%40mail.gmail.com. --000000000000b94b9f0645c16933 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You can soft fork in a hash function. There is no need fo= r 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, node= s enforcing new consensus will require the new hash outputs match. This tig= htens consensus so is a soft fork.

On Fri, Dec 12, 202= 5, 07:41 Possibly <zelatyna123@= gmail.com> 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 th= e whole structure of the block header, including likely switching to u64 ti= mestamps.


On Dece= mber 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= > wrote:
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 overfl= ow 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 tim= e in seconds since January 1, 1970. This design choice creates a critical l= imitation:

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

### Tech= nical Impact

When the timestamp overflows, several critical failures= will occur:

1. **Block Validation Failure**
=C2=A0 =C2=A0- Nodes= will reject blocks with timestamps >=3D 2^32
=C2=A0 =C2=A0- The bloc= kchain will effectively halt
=C2=A0 =C2=A0- No new transactions can be c= onfirmed

2. **Difficulty Adjustment Breakdown**
=C2=A0 =C2=A0- Di= fficulty calculation relies on accurate timestamps
=C2=A0 =C2=A0- Overfl= ow will corrupt the difficulty adjustment algorithm
=C2=A0 =C2=A0- Minin= g becomes unpredictable or impossible

3. **Time-Locked Transactions*= *
=C2=A0 =C2=A0- nLockTime and CheckLockTimeVerify (CLTV) will malfuncti= on
=C2=A0 =C2=A0- Smart contracts with future dates will fail
=C2=A0 = =C2=A0- Any financial instrument using time-locks post-2106 is broken **tod= ay**

4. **Median Time Past (MTP)**
=C2=A0 =C2=A0- Network consens= us relies on MTP for validation
=C2=A0 =C2=A0- Overflow corrupts this me= chanism entirely

### This Isn't Theoretical - It's Financial= Reality

Consider this: **Any Bitcoin-based financial instrument wit= h 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 buildi= ng
- **2-3 years**: Code development, rigorous testing, testnet deployme= nt =C2=A0
- **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 va= lue
- **2100-2106**: Potential panic and loss of confidence

If we= wait until 2090 to start the process, we're already too late. The shad= ow of the deadline will damage Bitcoin's credibility as "digital g= old" and a store of value for generations.

### The Governance C= hallenge

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 activat= ion took years of debate, and that was a soft fork. A hard fork is more cha= llenging.

---

## Proposed Solution: Migrate to uint64

= ### The Cleanest Path Forward

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

### Technical Specification

Cur= rent: uint32 timestamp (4 bytes)
Proposed: uint64 timestamp (8 bytes)
New maximum: 2^64 - 1 seconds
New overflow date: Year 292,277,026,5= 96 CE

### Implementation Details

1. **Block Structure Change*= *
=C2=A0 =C2=A0- Increase timestamp field from 4 to 8 bytes
=C2=A0 = =C2=A0- Maintains Unix epoch (Jan 1, 1970) as reference point
=C2=A0 =C2= =A0- Backward compatible with all timestamps before 2106

2. **Activa= tion Mechanism**
=C2=A0 =C2=A0- Set activation height (e.g., block 1,000= ,000 after consensus)
=C2=A0 =C2=A0- All blocks after activation height = MUST use uint64
=C2=A0 =C2=A0- Pre-activation blocks remain uint32 (no h= istorical rewrite needed)

3. **Validation Rules**
=C2=A0 =C2=A0- = Post-activation: nodes reject blocks with uint32 timestamps
=C2=A0 =C2= =A0- Pre-activation blocks grandfathered in
=C2=A0 =C2=A0- Clear flag da= y for the transition

4. **Node Requirements**
=C2=A0 =C2=A0- All = nodes must upgrade before activation height
=C2=A0 =C2=A0- Non-upgraded = nodes will fork off the network
=C2=A0 =C2=A0- Clear communication campa= ign 2-3 years before activation

### Why This Solution?

**Pros= :**
- Solves the problem for 292 billion years
- Aligns with modern U= nix 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 m= andatory)
- Breaks backward compatibility with non-upgraded nodes
- N= eeds 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 ab= out 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 gra= ndchildren

---

## Call to Action

**We are building a f= inancial system for our children and grandchildren.** We cannot leave them = a ticking time bomb.

Bitcoin's strength is its long-term thinkin= g. We plan for decades, not quarters. A hard fork is not the end of the wor= ld - **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 be= gin formal discussion of a BIP for uint64 timestamp migration.**

---=

## Next Steps

I am seeking:
1. **Feedback** from Core dev= elopers on technical approach
2. **Community discussion** on timeline an= d 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 &= quot;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://g= roups.google.com/d/msgid/bitcoindev/8061ABAF-4AD4-4358-B6AC-8DD8C808D507%40= gmail.com.

--
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.co= m/d/msgid/bitcoindev/CAEM%3Dy%2BW8c%3DCocE-T-uKRmLPH6fzL_dr38iW2VU-3Z9OaWA9= Z5A%40mail.gmail.com.
--000000000000b94b9f0645c16933--