From: Josh Doman <joshsdoman@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
Date: Sun, 14 Dec 2025 13:53:48 -0800 (PST) [thread overview]
Message-ID: <90e7936d-6383-41aa-a9c6-a825ef39f6d2n@googlegroups.com> (raw)
In-Reply-To: <CAAS2fgSTqeE-vxPsn3hfH0d096ycM-rmTVqGSVH3nELeiG885g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5989 bytes --]
> I don't think that's a softfork in the same sense as any that have
historically been deployed, as it leaves the older participants entirely
insecure and even easily DOS attacked.
I hadn't considered the DOS vector for older participants. That's a good
point, but I think there's an easy fix. Just set the legacy timestamp in
the last block of a difficulty adjustment period equal to the nTime of the
first block plus the actual duration of the period. Ex:
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 T + (N - H - 2015)
+ coinbase timestamp at height N - coinbase timestamp at height (N - 2015)..
As a result, the difficulty adjustment for legacy nodes is the same as the
difficulty adjustment for upgraded nodes, making the difficulty target the
same. I think this resolves your DOS concern.
> You're also left with the locktime functionality totally destroyed
leaving bitcoin hobbled
Yes, as I mentioned, that's an unavoidable consequence. Locktime
functionality will still work for block heights, but you'd need a new
mechanism to continue to lock to timestamps. I recall a developer saying
that timestamp locking was perhaps a mistake, so perhaps removing it isn't
the worst idea.
Accidental confiscation would probably be the biggest concern, but with
sufficient notice, it's likely a non-issue. I doubt there are many coins
permanently locked until 2050, for instance.
Josh
On Sunday, December 14, 2025 at 3:45:37 PM UTC-5 Greg Maxwell wrote:
> nodes require that the block hash meets the difficulty target determined
in the coinbase (in addition to the artificially low legacy difficulty
target).
I don't think that's a softfork in the same sense as any that have
historically been deployed, as it leaves the older participants entirely
insecure and even easily DOS attacked. You're also left with the locktime
functionality totally destroyed leaving bitcoin hobbled-- so it's not
really fixing the timestamp issue.
The long time assumption I know in the community is that normative
unwrapping behavior could be adopted decades ahead of 2106--
compatibility would be fine until 2106 and after that point unupdated
software would be safely stuck. That seems better to me.
On Sun, Dec 14, 2025 at 8: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/90e7936d-6383-41aa-a9c6-a825ef39f6d2n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8002 bytes --]
next prev parent reply other threads:[~2025-12-14 21:57 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 [this message]
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
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=90e7936d-6383-41aa-a9c6-a825ef39f6d2n@googlegroups.com \
--to=joshsdoman@gmail.com \
--cc=bitcoindev@googlegroups.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