* [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration
@ 2025-12-08 18:43 אושר חיים גליק
2025-12-12 12:25 ` Possibly
[not found] ` <CAPnXYtNWr33O4aNCpKb_zQ+g0x14ZFLQQjMP===rvi3KF_amuQ@mail.gmail.com>
0 siblings, 2 replies; 6+ messages in thread
From: אושר חיים גליק @ 2025-12-08 18:43 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 7181 bytes --]
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/4355092f-4cd6-4e3f-9ae8-4823183ca731n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8471 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration
2025-12-08 18:43 [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration אושר חיים גליק
@ 2025-12-12 12:25 ` Possibly
2025-12-12 13:40 ` Ethan Heilman
[not found] ` <CAPnXYtNWr33O4aNCpKb_zQ+g0x14ZFLQQjMP===rvi3KF_amuQ@mail.gmail.com>
1 sibling, 1 reply; 6+ messages in thread
From: Possibly @ 2025-12-12 12:25 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 8301 bytes --]
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/4355092f-4cd6-4e3f-9ae8-4823183ca731n%40googlegroups.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/8061ABAF-4AD4-4358-B6AC-8DD8C808D507%40gmail.com.
[-- Attachment #2: Type: text/html, Size: 8831 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration
2025-12-12 12:25 ` Possibly
@ 2025-12-12 13:40 ` Ethan Heilman
0 siblings, 0 replies; 6+ messages in thread
From: Ethan Heilman @ 2025-12-12 13:40 UTC (permalink / raw)
To: Possibly; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 9234 bytes --]
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 <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 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
> <https://groups.google.com/d/msgid/bitcoindev/8061ABAF-4AD4-4358-B6AC-8DD8C808D507%40gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
[-- Attachment #2: Type: text/html, Size: 10206 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration
[not found] ` <CAPnXYtNWr33O4aNCpKb_zQ+g0x14ZFLQQjMP===rvi3KF_amuQ@mail.gmail.com>
@ 2025-12-14 13:59 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-12-15 9:59 ` Garlo Nicon
0 siblings, 1 reply; 6+ messages in thread
From: 'Russell O'Connor' via Bitcoin Development Mailing List @ 2025-12-14 13:59 UTC (permalink / raw)
To: Bitcoin Development Mailing List; +Cc: Henry Romp
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]
On Sat, Dec 13, 2025 at 5:05 AM Henry Romp <151henry151@gmail.com> wrote:
> The blockchain won't "halt" at overflow, it will have validation problems.
> The overflow doesn't automatically stop the chain. Nodes would continue
> with wrapped-around timestamps (though this would cause some problems).
>
Yes the blockchain halts.
The timestamps are required to eventually increase; more specifically each
new timestamp is required to be strictly greater than the MTP timestamp.
Assuming these timestamps stay reasonably accurate up to the end then at
best you can squeeze out a few more blocks by lying about the time, but
eventually the MTP timestamp will reach its maximum value. At that point
there are no more valid blocks that can be appended to the chain.
--
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/CAMZUoKkXQv%2BLO_3iWf1_PnPMR7ocO0ddHZhfZo63Umst%3DpVCPg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 1853 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration
2025-12-14 13:59 ` 'Russell O'Connor' via Bitcoin Development Mailing List
@ 2025-12-15 9:59 ` Garlo Nicon
2025-12-15 19:09 ` Henry Romp
0 siblings, 1 reply; 6+ messages in thread
From: Garlo Nicon @ 2025-12-15 9:59 UTC (permalink / raw)
To: Russell O'Connor; +Cc: Bitcoin Development Mailing List, Henry Romp
[-- Attachment #1: Type: text/plain, Size: 3012 bytes --]
> The blockchain won't "halt" at overflow, it will have validation
problems.
These "validation problems" will be quite serious. For example: it will be
possible to produce a chain with a bigger chainwork, and pass it to the old
nodes.
Which means, that the chain can go forward for the new nodes, while being
perceived as a constantly reorged, by the old implementation.
And then, the question is: do we want to design a new soft-fork in a way,
where it would be seen as constantly-reorged chain by the old nodes?
> The overflow doesn't automatically stop the chain.
It will, because overflowed timestamps from 1970 will be rejected by all
old nodes.
> At that point there are no more valid blocks that can be appended to the
chain.
As long as the chainwork won't overflow, you can always reorg the old
blocks. If that reorg will be deterministic, and accepted by hashrate
majority, then it will be seen only by old nodes. New nodes can see a
stable chain, always going forward, beyond 0xffffffff.
Anyway, it will be just one-bit increment per 136 years.
niedz., 14 gru 2025 o 15:09 'Russell O'Connor' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> napisał(a):
> On Sat, Dec 13, 2025 at 5:05 AM Henry Romp <151henry151@gmail.com> wrote:
>
>> The blockchain won't "halt" at overflow, it will have validation
>> problems. The overflow doesn't automatically stop the chain. Nodes would
>> continue with wrapped-around timestamps (though this would cause some
>> problems).
>>
>
> Yes the blockchain halts.
>
> The timestamps are required to eventually increase; more specifically each
> new timestamp is required to be strictly greater than the MTP timestamp.
> Assuming these timestamps stay reasonably accurate up to the end then at
> best you can squeeze out a few more blocks by lying about the time, but
> eventually the MTP timestamp will reach its maximum value. At that point
> there are no more valid blocks that can be appended to the chain.
>
> --
> 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/CAMZUoKkXQv%2BLO_3iWf1_PnPMR7ocO0ddHZhfZo63Umst%3DpVCPg%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAMZUoKkXQv%2BLO_3iWf1_PnPMR7ocO0ddHZhfZo63Umst%3DpVCPg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAN7kyNhQ%2BmwkvXG%2Bx-im4TUuNrEVeqzJWs1ki4%2BXRmRN816kXA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4185 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration
2025-12-15 9:59 ` Garlo Nicon
@ 2025-12-15 19:09 ` Henry Romp
0 siblings, 0 replies; 6+ messages in thread
From: Henry Romp @ 2025-12-15 19:09 UTC (permalink / raw)
To: Garlo Nicon; +Cc: Russell O'Connor, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3513 bytes --]
Ah, I see you're right—once MTP reaches 2^32 - 1, no valid timestamp can
exceed it, making the next block mathematically impossible.
I was wrong about the halt. I still maintain my other points about timeline
and opportunity costs.
Henry
*Henry Romp802-458-7299 <8024587299>*
*151henry151@gmail.com <151henry151@gmail.com>*
On Mon, Dec 15, 2025, 04:59 Garlo Nicon <garlonicon@gmail.com> wrote:
> > The blockchain won't "halt" at overflow, it will have validation
> problems.
>
> These "validation problems" will be quite serious. For example: it will be
> possible to produce a chain with a bigger chainwork, and pass it to the old
> nodes.
>
> Which means, that the chain can go forward for the new nodes, while being
> perceived as a constantly reorged, by the old implementation.
>
> And then, the question is: do we want to design a new soft-fork in a way,
> where it would be seen as constantly-reorged chain by the old nodes?
>
> > The overflow doesn't automatically stop the chain.
>
> It will, because overflowed timestamps from 1970 will be rejected by all
> old nodes.
>
> > At that point there are no more valid blocks that can be appended to the
> chain.
>
> As long as the chainwork won't overflow, you can always reorg the old
> blocks. If that reorg will be deterministic, and accepted by hashrate
> majority, then it will be seen only by old nodes. New nodes can see a
> stable chain, always going forward, beyond 0xffffffff.
>
> Anyway, it will be just one-bit increment per 136 years.
>
> niedz., 14 gru 2025 o 15:09 'Russell O'Connor' via Bitcoin Development
> Mailing List <bitcoindev@googlegroups.com> napisał(a):
>
>> On Sat, Dec 13, 2025 at 5:05 AM Henry Romp <151henry151@gmail.com> wrote:
>>
>>> The blockchain won't "halt" at overflow, it will have validation
>>> problems. The overflow doesn't automatically stop the chain. Nodes would
>>> continue with wrapped-around timestamps (though this would cause some
>>> problems).
>>>
>>
>> Yes the blockchain halts.
>>
>> The timestamps are required to eventually increase; more specifically
>> each new timestamp is required to be strictly greater than the MTP
>> timestamp. Assuming these timestamps stay reasonably accurate up to the
>> end then at best you can squeeze out a few more blocks by lying about the
>> time, but eventually the MTP timestamp will reach its maximum value. At
>> that point there are no more valid blocks that can be appended to the chain.
>>
>> --
>> 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/CAMZUoKkXQv%2BLO_3iWf1_PnPMR7ocO0ddHZhfZo63Umst%3DpVCPg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAMZUoKkXQv%2BLO_3iWf1_PnPMR7ocO0ddHZhfZo63Umst%3DpVCPg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/CAPnXYtPdbFwc1mOsP2eHQBwuJhn2XxLCWC-pt6%2BN-bu3BRRbiA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5973 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-12-15 19:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-08 18:43 [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration אושר חיים גליק
2025-12-12 12:25 ` Possibly
2025-12-12 13:40 ` Ethan Heilman
[not found] ` <CAPnXYtNWr33O4aNCpKb_zQ+g0x14ZFLQQjMP===rvi3KF_amuQ@mail.gmail.com>
2025-12-14 13:59 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-12-15 9:59 ` Garlo Nicon
2025-12-15 19:09 ` Henry Romp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox