From: Garlo Nicon <garlonicon@gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>,
Henry Romp <151henry151@gmail.com>
Subject: Re: [bitcoindev] [Discussion] Year 2106 Timestamp Overflow - Proposal for uint64 Migration
Date: Mon, 15 Dec 2025 10:59:17 +0100 [thread overview]
Message-ID: <CAN7kyNhQ+mwkvXG+x-im4TUuNrEVeqzJWs1ki4+XRmRN816kXA@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkXQv+LO_3iWf1_PnPMR7ocO0ddHZhfZo63Umst=pVCPg@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2025-12-15 19:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-08 18:43 אושר חיים גליק
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 [this message]
2025-12-15 19:09 ` Henry Romp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN7kyNhQ+mwkvXG+x-im4TUuNrEVeqzJWs1ki4+XRmRN816kXA@mail.gmail.com \
--to=garlonicon@gmail.com \
--cc=151henry151@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=roconnor@blockstream.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox