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 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/b9875c52-0374-4e5c-a369-a9c4be33db9cn%40googlegroups.com.