From: Henry Romp <151henry151@gmail.com>
To: Josh Doman <joshsdoman@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
Date: Tue, 16 Dec 2025 01:04:24 -0500 [thread overview]
Message-ID: <CAPnXYtOd9egA1RZ2LypBQjO7YWpgsYWThz7Tn-hKYd44o0-xsQ@mail.gmail.com> (raw)
In-Reply-To: <e7a70843-a304-4d04-9365-08b8b4259caen@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 6518 bytes --]
It looked at first to me like the normative unwrapping approach Greg
mentioned would be the best solution, but would that still be breaking
timelocked transactions? A change to how timestamp values map to real time
across the 2106 boundary, for transactions spanning the transition?
Henry
On Mon, Dec 15, 2025, 14:30 Josh Doman <joshsdoman@gmail.com> wrote:
> > your idea is to have the header nTime used for difficulty adjustment
> enforced in the coinbase tx.
>
> Correct. As written, BIP54 makes that soft fork impossible, leaving a hard
> fork as the only option to resolve nTime overflow.
>
> > I was about to write this email myself, but then I realized that since
> BIP 113, timelocks are based on MTP time, and any soft-fork mechanism that
> messes with MTP time will destroy existing transaction's timelock semantics.
>
> Yes, it's unfortunate. There is certainly a tradeoff. On the one hand,
> there is a risk of coin confiscation, if the soft fork isn't signaled early
> enough (a few decades in advance is probably sufficient). On the other
> hand, there are material benefits to avoiding a hard fork (i.e. you get a
> smooth and secure upgrade path, developers can write immutable programs
> that verify the chain, etc).
>
> I think it's presumptive to assume which option a future generation would
> prefer, in the year 2070, 2080, 2090, 2100, etc, given the tradeoffs
> involved. I'm not suggesting we decide today, but I am suggesting that
> BIP54 may be unnecessarily restrictive.
>
> The following modification to BIP54 would resolve the timewarp attack
> while leaving open the possibility of an nTime soft fork:
> 1) Add a u64 timestamp to the coinbase and enforce BIP54 there (in
> addition to other timestamp rules)
> 2) Given a block of height N, where N % 2016 = 2015, the difference
> between the nTime and the nTime at height (N - 2015) must be the same as in
> the coinbase.
>
> On Monday, December 15, 2025 at 11:36:31 AM UTC-5 Russell O'Connor wrote:
>
> I was about to write this email myself, but then I realized that since BIP
> 113, timelocks are based on MTP time, and any soft-fork mechanism that
> messes with MTP time will destroy existing transaction's timelock
> semantics. Now I think the best is to have a hardfork.
>
> On Sun, Dec 14, 2025 at 3:33 PM Josh Doman <joshs...@gmail.com> wrote:
>
> *TLDR:* The "timewarp attack" could enable a future soft fork that fixes
> the timestamp overflow bug.
>
> I saw there is a discussion about a hard fork to handle the timestamp
> overflow bug, by migrating from u32 to u64 timestamps.[1] I considered
> making this post in that thread, but as it has more to do with the Great
> Consensus Cleanup [2], I thought it better to make this its own post.
>
> My question is: *does BIP54 inadvertently preclude the possibility of a
> soft fork to handle timestamp overflow?*
>
> Conceptually, I think you could implement a soft fork that resolves the
> timestamp overflow bug, by using the "timewarp attack" [3] to intentionally
> minimize the timestamp and reduce the legacy difficulty, while
> simultaneously using a u64 timestamp in the coinbase transaction to enforce
> the real difficulty target.
>
> In short, the "timewarp attack" makes it possible to increment the u32
> timestamp by 1 second each block, ensuring the chain will practically never
> halt (provided the soft fork is adopted sufficiently in advance).
>
> Formally, given a block of height N and a timestamp T at activation height
> H:
> - if N % 2016 < 2015: miners set the legacy timestamp to T + (N - H).
> - if N % 2016 = 2015, miners set the legacy timestamp to min(2^32 - 1,
> timestamp in the coinbase transaction).
> - nodes require that the block hash meets the difficulty target determined
> in the coinbase (in addition to the artificially low legacy difficulty
> target).
>
> This solution, of course, doesn't work if the Great Consensus Cleanup is
> adopted and the "timewarp attack" gets fixed. Also, it will make header and
> SPV validation more complex, as nodes will need the coinbase transaction
> and a merkle proof in order to validate the header chain. Perhaps worst of
> all, it could confiscate coins that are locked to a timestamp, rather than
> a block height.
>
> The upside is that this is a soft fork, rather than a hard fork, which has
> its own advantages. Meanwhile, confiscation concerns could potentially be
> mitigated by signaling activation several decades in advance.
>
> Is the possibility of a soft fork worth forgoing the timewarp fix? I'm not
> sure. A compromise could be to expire the timewarp fix after a certain
> block height, but that introduces a new set of tradeoffs.
>
> Josh
>
> [1] https://groups.google.com/g/bitcoindev/c/PHZEIRb04RY
> [2] https://github.com/bitcoin/bips/blob/master/bip-0054.md
> [3]
> https://bitcoin.stackexchange.com/questions/75831/what-is-time-warp-attack-and-how-does-it-work-in-general/75834#75834
>
> --
>
> 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+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/2ac708f3-8e73-4cd5-ba62-be64a2acea04n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/2ac708f3-8e73-4cd5-ba62-be64a2acea04n%40googlegroups.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/e7a70843-a304-4d04-9365-08b8b4259caen%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/e7a70843-a304-4d04-9365-08b8b4259caen%40googlegroups.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/CAPnXYtOd9egA1RZ2LypBQjO7YWpgsYWThz7Tn-hKYd44o0-xsQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9027 bytes --]
next prev parent reply other threads:[~2025-12-19 1:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-14 19:45 Josh Doman
2025-12-14 20:43 ` Greg Maxwell
2025-12-14 21:53 ` Josh Doman
2025-12-15 1:44 ` Antoine Riard
2025-12-15 16:31 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-12-15 17:27 ` Josh Doman
2025-12-16 6:04 ` Henry Romp [this message]
2025-12-17 14:55 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
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=CAPnXYtOd9egA1RZ2LypBQjO7YWpgsYWThz7Tn-hKYd44o0-xsQ@mail.gmail.com \
--to=151henry151@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=joshsdoman@gmail.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