* [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
@ 2025-12-14 19:45 Josh Doman
2025-12-14 20:43 ` Greg Maxwell
2025-12-15 16:31 ` 'Russell O'Connor' via Bitcoin Development Mailing List
0 siblings, 2 replies; 8+ messages in thread
From: Josh Doman @ 2025-12-14 19:45 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2901 bytes --]
*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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2ac708f3-8e73-4cd5-ba62-be64a2acea04n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3481 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
2025-12-14 19:45 [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? Josh Doman
@ 2025-12-14 20:43 ` Greg Maxwell
2025-12-14 21:53 ` Josh Doman
2025-12-15 16:31 ` 'Russell O'Connor' via Bitcoin Development Mailing List
1 sibling, 1 reply; 8+ messages in thread
From: Greg Maxwell @ 2025-12-14 20:43 UTC (permalink / raw)
To: Josh Doman; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 4423 bytes --]
> 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 <joshsdoman@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+unsubscribe@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/CAAS2fgSTqeE-vxPsn3hfH0d096ycM-rmTVqGSVH3nELeiG885g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5787 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
2025-12-14 20:43 ` Greg Maxwell
@ 2025-12-14 21:53 ` Josh Doman
2025-12-15 1:44 ` Antoine Riard
0 siblings, 1 reply; 8+ messages in thread
From: Josh Doman @ 2025-12-14 21:53 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
2025-12-14 21:53 ` Josh Doman
@ 2025-12-15 1:44 ` Antoine Riard
0 siblings, 0 replies; 8+ messages in thread
From: Antoine Riard @ 2025-12-15 1:44 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 7012 bytes --]
Hi Josh,
> using a u64 timestamp in the coinbase transaction to enforce the real
difficulty target.
IIUC, your idea is to have the header nTime used for difficulty adjustment
enforced in the coinbase tx.
However, the endpoint for absolute timelock would stay the same u32, afaict
(?). Even, if it's
long down the road, may I say you would like the tx's nLocktime and the
CBlockheader's nTime to
be encoded on the same length (how timelocks validity is supposed to work
in 2106 ?). Old idea
in the community was potentially to move the timelock in the annex, but
that one still has not
be given consensus meaning.
Best,
Antoine
OTS hash: 8a7a02fddb8dae70c4f8fb43e4c11047b2909ec1732461484a6fda701b40c90e
Le dimanche 14 décembre 2025 à 21:56:53 UTC, Josh Doman a écrit :
> > 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/b9875c52-0374-4e5c-a369-a9c4be33db9cn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10059 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
2025-12-14 19:45 [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? Josh Doman
2025-12-14 20:43 ` Greg Maxwell
@ 2025-12-15 16:31 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-12-15 17:27 ` Josh Doman
1 sibling, 1 reply; 8+ messages in thread
From: 'Russell O'Connor' via Bitcoin Development Mailing List @ 2025-12-15 16:31 UTC (permalink / raw)
To: Bitcoin Development Mailing List; +Cc: Josh Doman
[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]
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 <joshsdoman@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+unsubscribe@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/CAMZUoK%3DKqPTXCuBhy9O5YDXrLhRQMZJ25qAvTtRrE78s8SZniQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5169 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
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
0 siblings, 2 replies; 8+ messages in thread
From: Josh Doman @ 2025-12-15 17:27 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5453 bytes --]
> 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.
[-- Attachment #1.2: Type: text/html, Size: 7406 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
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
1 sibling, 0 replies; 8+ messages in thread
From: Henry Romp @ 2025-12-16 6:04 UTC (permalink / raw)
To: Josh Doman; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow?
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
1 sibling, 0 replies; 8+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-12-17 14:55 UTC (permalink / raw)
To: Josh Doman; +Cc: Bitcoin Development Mailing List
Hi Josh,
Interesting observation!
I am of the opinion that the header timestamp overflow is one of those things
that are better addressed through a backward-incompatible consensus change. As
pointed out earlier in response to your post, the MTP rule would prevent a chain
split by making sure the legacy chain halts.
Furthermore, even if it was a goal to fix the timestamp overflow through a soft
fork, the issue will arise so far in the future that it does not justify making
inferior protocol decisions to fix bugs that exist today (and that could become
more problematic within the next decade).
You came up with a clever hack to address the DoS concern, which somewhat
reminds me of forward blocks. It makes it possible to still validate cumulative
work from a chain of headers, but it relies on actively exploiting Timewarp
there. This is unfortunate in itself but also means breaking timestamp-based
timelocks which, as people pointed out here and on your Delving thread, entails
freezing coins that rely on them.
Therefore my preference is to fix properly Timewarp with BIP 54, and properly
deal with the timestamp overflow when (if?) necessary.
Best,
Antoine Poinsot
On Monday, December 15th, 2025 at 2:30 PM, 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.
>
> --
> 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.
--
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/a7m01C4Xm3-WF9Slrg1b2G8OaZiCXKQncrHW4kD5iVrNq8E-yde2W4pF1ZIU6PeiU-jUeyDCsFntfrTw28wW38iIkBeo6OENzlWUsL-hetc%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-12-19 1:49 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-14 19:45 [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? 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
2025-12-17 14:55 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox