From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 14 Dec 2025 19:51:20 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUzcF-0000Qp-Ux for bitcoindev@gnusha.org; Sun, 14 Dec 2025 19:51:20 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-3ed1781e961sf2421587fac.2 for ; Sun, 14 Dec 2025 19:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765770673; x=1766375473; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=t8lF5Z51z/f8DpsiWepSNI86A7B3zAwTHVd3p5Azk/I=; b=s+1STJ0jKDph2iODbFpVs4a7ffECLXxzEI3IaTH7WlNh7zvYKkzc+J8BvUKd9PALnC Xs43wlrDoy7KTGPLz5d1MqlpU7ul7Ui4D+UujnXhotNx3o92/jWwjPByTx9PWSZOW4p/ M+UPH1lAeh0AWTrdDqkehzHJPS8uc2Eeg+UXxiNCA8RcZv4gsJPDHVbMh3WlZy2Xsnwj ATXJm5HvjimTVlF3moMnYwPtxUenxSsCqXpv/xRyD3LGJs/HBne1CnEqzk+P1tOSGIvw tzRhuvLEw31INihSaXxNKCJABeBKsnDQwru0o4DkJm7rilx6F/qF0lDeM8ZrxES9/RAF NBZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765770673; x=1766375473; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=t8lF5Z51z/f8DpsiWepSNI86A7B3zAwTHVd3p5Azk/I=; b=MG81KDFwI85F0RI1d9X45prbvuh2CTXVz09YiUylXYN4tXvZBDicd1i8Nnc/Az9oCx enuGlXgP4LXmmz+DaweE2DUyHP7VPtxWQalrNXfM3we9Q7f6LBcyqguaYkAEzeNY961X ULl0f3AW72BpSkK7gWkMfCZWVwFOHuPj8alInkkALddgIOp1nTPUva70dkQTBPckvYga p0gczBX2XJ75lXWMfdzmVMw7HcdgQ/+hkRgGmlGnJqX1GavrYFhXa65Lxoq26wf3IH5H pambw6ZP4hihRPftpgN2ycLY3JPSC85csJn3ouQiqVN5cvv0psUfVPBMOn11qoURWyEv ICZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765770673; x=1766375473; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=t8lF5Z51z/f8DpsiWepSNI86A7B3zAwTHVd3p5Azk/I=; b=bHiJv2UUkWoucqgz//9X+CdvQbLAYjmK2pHzNASVohOKnsJiXUsptv2I8kKTQcD2CC BEeUKkCMqsTaiE5LOOV2rm/Yw99bigsj8nXR1Ja6zt2hfPLkAi3CCj2kSUIgG0nZ+914 HMrxSXg4O32ck4dUamiCES76ORH7RVWvUnwmxf+keRhfesT0kw3DvFd4mi4TkzR6Tqq4 GHCdPgcPTZzgfswXTO8xSA9F5B/M8T2UUYQ39qFTKAs0dCOf+5dGryRqDwaUcWOfMQKF tUv+gie1pczba6JAArat7TZZlOFA/tLlgUBkcPKazB1Xf11IBZoQkO7qXBqa2ChUYMMq QVsA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXt8Il5kF+fnXzbsha2FStKImYmjd4ZXLXMe2Afx+5Vb2angftmWt2QwdUyIzQ+eVGAMrYwE9poMEkf@gnusha.org X-Gm-Message-State: AOJu0YwLxTfoHrHDQZMlXizbZbh/nc3fgz5oLTlYFu9jLahvWmAy69Ff JKOHdC02pwzNEUKJ3mh1xYaVJpMW9CL7l/tnD7jvea7tYwIhOsNgZnFS X-Google-Smtp-Source: AGHT+IFERHWWv5OnPadKUlIUqIiBTyFs6d8jF2luqp+L1EpC6QJRA5RheNwADFaSx5dUMXYss1gqLA== X-Received: by 2002:a05:6871:2312:b0:3ec:5a83:38fd with SMTP id 586e51a60fabf-3f5f8c0301bmr5132445fac.31.1765770672716; Sun, 14 Dec 2025 19:51:12 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZERAyNw11kZn8jWdcRrlbA5UEkZ2CLku8IKO1GKluqIA==" Received: by 2002:a05:6870:8185:b0:3f5:f1fc:f50a with SMTP id 586e51a60fabf-3f5f8860252ls934501fac.0.-pod-prod-00-us; Sun, 14 Dec 2025 19:51:07 -0800 (PST) X-Received: by 2002:a05:6808:1906:b0:450:da6a:269b with SMTP id 5614622812f47-455ab77f1b6mr4890875b6e.26.1765770667331; Sun, 14 Dec 2025 19:51:07 -0800 (PST) Received: by 2002:a05:690c:a7cc:b0:780:f7eb:fdf with SMTP id 00721157ae682-78e645626cams7b3; Sun, 14 Dec 2025 17:44:47 -0800 (PST) X-Received: by 2002:a05:690e:12ca:b0:645:5849:8b8c with SMTP id 956f58d0204a3-64558498bf3mr6720992d50.47.1765763086752; Sun, 14 Dec 2025 17:44:46 -0800 (PST) Date: Sun, 14 Dec 2025 17:44:46 -0800 (PST) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <90e7936d-6383-41aa-a9c6-a825ef39f6d2n@googlegroups.com> References: <2ac708f3-8e73-4cd5-ba62-be64a2acea04n@googlegroups.com> <90e7936d-6383-41aa-a9c6-a825ef39f6d2n@googlegroups.com> Subject: Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_545510_820666483.1765763086234" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_545510_820666483.1765763086234 Content-Type: multipart/alternative; boundary="----=_Part_545511_109790527.1765763086234" ------=_Part_545511_109790527.1765763086234 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Josh, > using a u64 timestamp in the coinbase transaction to enforce the real=20 difficulty target. IIUC, your idea is to have the header nTime used for difficulty adjustment= =20 enforced in the coinbase tx. However, the endpoint for absolute timelock would stay the same u32, afaict= =20 (?). Even, if it's long down the road, may I say you would like the tx's nLocktime and the=20 CBlockheader's nTime to be encoded on the same length (how timelocks validity is supposed to work= =20 in 2106 ?). Old idea in the community was potentially to move the timelock in the annex, but=20 that one still has not be given consensus meaning. Best, Antoine OTS hash: 8a7a02fddb8dae70c4f8fb43e4c11047b2909ec1732461484a6fda701b40c90e Le dimanche 14 d=C3=A9cembre 2025 =C3=A0 21:56:53 UTC, Josh Doman a =C3=A9c= rit : > > I don't think that's a softfork in the same sense as any that have=20 > historically been deployed, as it leaves the older participants entirely= =20 > insecure and even easily DOS attacked. > > I hadn't considered the DOS vector for older participants. That's a good= =20 > point, but I think there's an easy fix. Just set the legacy timestamp in= =20 > the last block of a difficulty adjustment period equal to the nTime of th= e=20 > 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 =3D 2015, miners set the legacy timestamp to T + (N - H -= =20 > 2015) + coinbase timestamp at height N - coinbase timestamp at height (N = -=20 > 2015).. > > As a result, the difficulty adjustment for legacy nodes is the same as th= e=20 > difficulty adjustment for upgraded nodes, making the difficulty target th= e=20 > same. I think this resolves your DOS concern. > > > You're also left with the locktime functionality totally destroyed=20 > leaving bitcoin hobbled > > Yes, as I mentioned, that's an unavoidable consequence. Locktime=20 > functionality will still work for block heights, but you'd need a new=20 > mechanism to continue to lock to timestamps. I recall a developer saying= =20 > that timestamp locking was perhaps a mistake, so perhaps removing it isn'= t=20 > the worst idea. > > Accidental confiscation would probably be the biggest concern, but with= =20 > sufficient notice, it's likely a non-issue. I doubt there are many coins= =20 > permanently locked until 2050, for instance. > > Josh > > On Sunday, December 14, 2025 at 3:45:37=E2=80=AFPM UTC-5 Greg Maxwell wro= te: > > > nodes require that the block hash meets the difficulty target determine= d=20 > in the coinbase (in addition to the artificially low legacy difficulty=20 > target). > > I don't think that's a softfork in the same sense as any that have=20 > historically been deployed, as it leaves the older participants entirely= =20 > insecure and even easily DOS attacked. You're also left with the locktim= e=20 > functionality totally destroyed leaving bitcoin hobbled-- so it's not=20 > really fixing the timestamp issue. > > The long time assumption I know in the community is that normative=20 > unwrapping behavior could be adopted decades ahead of 2106--=20 > compatibility would be fine until 2106 and after that point unupdated=20 > software would be safely stuck. That seems better to me. > > > > > > > On Sun, Dec 14, 2025 at 8:33=E2=80=AFPM Josh Doman w= rote: > > *TLDR:* The "timewarp attack" could enable a future soft fork that fixes= =20 > the timestamp overflow bug. > > I saw there is a discussion about a hard fork to handle the timestamp=20 > overflow bug, by migrating from u32 to u64 timestamps.[1] I considered=20 > making this post in that thread, but as it has more to do with the Great= =20 > Consensus Cleanup [2], I thought it better to make this its own post. > > My question is: *does BIP54 inadvertently preclude the possibility of a= =20 > soft fork to handle timestamp overflow?* > > Conceptually, I think you could implement a soft fork that resolves the= =20 > timestamp overflow bug, by using the "timewarp attack" [3] to intentional= ly=20 > minimize the timestamp and reduce the legacy difficulty, while=20 > simultaneously using a u64 timestamp in the coinbase transaction to enfor= ce=20 > the real difficulty target. > > In short, the "timewarp attack" makes it possible to increment the u32=20 > timestamp by 1 second each block, ensuring the chain will practically nev= er=20 > halt (provided the soft fork is adopted sufficiently in advance). > > Formally, given a block of height N and a timestamp T at activation heigh= t=20 > H: > - if N % 2016 < 2015: miners set the legacy timestamp to T + (N - H). > - if N % 2016 =3D 2015, miners set the legacy timestamp to min(2^32 - 1,= =20 > timestamp in the coinbase transaction). > - nodes require that the block hash meets the difficulty target determine= d=20 > in the coinbase (in addition to the artificially low legacy difficulty=20 > target). > > This solution, of course, doesn't work if the Great Consensus Cleanup is= =20 > adopted and the "timewarp attack" gets fixed. Also, it will make header a= nd=20 > SPV validation more complex, as nodes will need the coinbase transaction= =20 > and a merkle proof in order to validate the header chain. Perhaps worst o= f=20 > all, it could confiscate coins that are locked to a timestamp, rather tha= n=20 > a block height. > > The upside is that this is a soft fork, rather than a hard fork, which ha= s=20 > its own advantages. Meanwhile, confiscation concerns could potentially be= =20 > mitigated by signaling activation several decades in advance. > > Is the possibility of a soft fork worth forgoing the timewarp fix? I'm no= t=20 > sure. A compromise could be to expire the timewarp fix after a certain=20 > 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]=20 > https://bitcoin.stackexchange.com/questions/75831/what-is-time-warp-attac= k-and-how-does-it-work-in-general/75834#75834 > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/2ac708f3-8e73-4cd5-ba62-be64= a2acea04n%40googlegroups.com=20 > > . > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= b9875c52-0374-4e5c-a369-a9c4be33db9cn%40googlegroups.com. ------=_Part_545511_109790527.1765763086234 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Josh,

> =C2=A0using a u64 timestamp in the coinbase transa= ction to enforce the real difficulty target.

IIUC, your idea is = to have the header nTime used for difficulty adjustment enforced in the coi= nbase 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 2= 106 ?). Old idea
in the community was potentially to move the timelock= in the annex, but that one still has not
be given consensus meaning.<= br />
Best,
Antoine
OTS hash: 8a7a02fddb8dae70c4f8fb43e4c110= 47b2909ec1732461484a6fda701b40c90e
Le dimanche 14 d=C3=A9cembre 2025 =C3=A0 21:56:53 = UTC, Josh Doman a =C3=A9crit=C2=A0:
> I don't think that's a softfork in= the same sense as any that have historically been deployed,=C2=A0 as it le= aves the older participants entirely insecure and even easily DOS attacked.=

I hadn't considered the DOS vector for older parti= cipants. 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 peri= od equal to the nTime of the first block plus the actual duration of the pe= riod. Ex:

Given a block of height N and a timestamp= T at activation height H:
- if N % 2016 < 2015: mi= ners set the legacy timestamp to T + (N - H).
- if N %= 2016 =3D 2015, miners set the legacy timestamp to T + (N - H - 2015) + coi= nbase timestamp at height N - coinbase timestamp at height (N - 2015)..

As a result, the difficulty adjustment for legacy nod= es 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
<= /div>

Yes, as I mentioned, that's an = unavoidable consequence. Locktime functionality will still work for block h= eights, but you'd need a new mechanism to continue to lock to timestamp= s. 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 su= fficient notice, it's likely a non-issue. I doubt there are many coins = permanently locked until 2050, for instance.
Josh

On Sunday, Dec= ember 14, 2025 at 3:45:37=E2=80=AFPM UTC-5 Greg Maxwell wrote:
> nodes require that the block hash meets the difficulty t= arget=20 determined in the coinbase (in addition to the artificially low legacy=20 difficulty target).

I don&#= 39;t think that's a softfork in the same sense as any that have histori= cally been deployed,=C2=A0 as it leaves the older participants entirely ins= ecure and even easily DOS attacked.=C2=A0 You're also left with the loc= ktime functionality totally destroyed leaving bitcoin hobbled-- so it's= not really fixing the timestamp issue.

The long t= ime assumption I know in the community is that normative unwrapping behavio= r could be adopted decades ahead of 2106-- compatibility=C2=A0would be fine= until 2106 and after that point unupdated software would be safely stuck.= =C2=A0 That seems better to me.





On Sun, Dec 14, 2025 at 8:33=E2=80=AFPM 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 ab= out 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 bette= r to make this its own post.

My question is: does BIP= 54 inadvertently preclude the possibility of a soft fork to handle timestam= p overflow?

Conceptually, I think you could impl= ement a soft fork that resolves the timestamp overflow bug, by using the &q= uot;timewarp attack" [3] to intentionally minimize the timestamp and r= educe the legacy difficulty, while simultaneously using a u64 timestamp in = the coinbase transaction to enforce the real difficulty target.
<= br>
In short, the "timewarp attack" makes it possible t= o increment the u32 timestamp by 1 second each block, ensuring the chain wi= ll practically never halt (provided the soft fork is adopted sufficiently i= n advance).

Formally, given a block of height N an= d a timestamp T at activation height H:
- if N % 2016 < 2015: = miners set the legacy timestamp to T + (N - H).
- if N % 2016 =3D= 2015, miners set the legacy timestamp to min(2^32 - 1, timestamp in the co= inbase transaction).
- nodes require that the block hash meets th= e difficulty target determined in the coinbase (in addition to the artifici= ally 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 S= PV 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 b= lock height.

The upside is that this is a soft for= k, rather than a hard fork, which has its own advantages. Meanwhile, confis= cation concerns could potentially be mitigated by signaling activation seve= ral decades in advance.

Is the possibility of a so= ft fork worth forgoing the timewarp fix? I'm not sure. A compromise cou= ld be to expire the timewarp fix after a certain block height, but that int= roduces a new set of tradeoffs.

Josh

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/2ac708f3-8e73-4cd5-ba62-be64a2acea0= 4n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/b9875c52-0374-4e5c-a369-a9c4be33db9cn%40googlegroups.com.
------=_Part_545511_109790527.1765763086234-- ------=_Part_545510_820666483.1765763086234--