From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 14 Dec 2025 13:57:00 -0800 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUu5L-0001wx-Ty for bitcoindev@gnusha.org; Sun, 14 Dec 2025 13:57:00 -0800 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-3e82af7316bsf4198906fac.0 for ; Sun, 14 Dec 2025 13:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765749413; x=1766354213; 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=uc6L/gSX3uPxpkud6mJ+8veaJqs+VopKQbsWQ0f/waw=; b=WWB8RyBsy12ANt8hNl+neF8OXcVXEZMtwDHp/veihakwEkydhZgNQ4h4X8pAAk3vxl JvCZHMKyIAngcpwU53whRE8yPIHOfbEzda6Rlt7YF5uofOCA2+R+7EMKgVmPNEhi7Ozz o/zUAM1bgrXzhV0KUCt9gHOr90+vfnyWffE9InwCPaGcbGmtJOn4xsTMIgUms1U2V3/u qcMjEzW1oZOoiHY05/HRIA/cRrsZCaZgppur0DtOQ1VgTLGvTCjgs3I+akb/yrsQbk/X JdpcrjdfQH4QhMSiE1QcrEvN+qD4gRFoQUO0Xt21aDH60izHtmkhLugyquUwznhkpNWP /XpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765749413; x=1766354213; 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=uc6L/gSX3uPxpkud6mJ+8veaJqs+VopKQbsWQ0f/waw=; b=WhZ+TDNVTkWIOSc5Qq8yBFEkUh7/qHbpAG5W83S9QG5vXkIJJYjwXErnxztwEKW97n 3sMJPquyW4AfAeMwugFhguq0rt/qlAkKc/Ykzc7NB1BQCKskBdQhrZ3xI6T2wPnUtWQu AaMjQZ7pLkRuwTpDJBpBpeMdK+SCnpxjrcP8rbKTVxhb1epzKj6JfamZFcxoXPKQEfjg NSqr3WtnCtQy8+/hobP8a0dNs5IJ5qMOcPpnFQAZZ9M3zBJ+Y2OLEMRYYK593tb+ToFL lVSENH+A931u9JWbfYqNVLUrNsRhDpwwRGF+gEc5MNfkszfEMU6Dr6ZDFAa28nn3jPT8 cBNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765749413; x=1766354213; 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=uc6L/gSX3uPxpkud6mJ+8veaJqs+VopKQbsWQ0f/waw=; b=si3rjGauiDHwd9b8X6WDV42Oll3jicQjUy4b2pTJN7woWQV7LWbTjkH968JZrI9y9R 6jg44hH8/Bl2hkKoohxaFmMvdsGufq8anAxJStJijtJUGDq6WNEVb4wNIesJY3n+jF9s QhU8rO911FxDHYwrfYXawAHmhZm1aoW/2xC5I0Tx+9/01t+WOSy/lPz2yU3sYDdiV5at +CrTR0yz8u/mv8on2VjG4hyVv9yy1ZZTXrJfp44hYzEQWyII4HgPL7Tk+WM5JQPmqO80 jUpYEUdgw/HA09GU7UKMD97/mlefzDIp11SCPQpzq7ZJOnvHniRPRIpDsCGLhPUEhv9a yMtA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWsLXqOKcfcZ1KLBc5ZGdrB305wzfv7iRwyQGiDQKptGRrwor2qpfSHng0WNhN8lAdoAAkC4ic1rzK9@gnusha.org X-Gm-Message-State: AOJu0YyGztkAT+KXrkDbRQgSnq49HOOGHnTGphDl2N18bZLFDedu6DJi kfytRT4+huJ22rkCSbbFqCnQ4GlBzJnECZyxvYRorndlfu4D3hck8jXd X-Google-Smtp-Source: AGHT+IFvyiaNdQxnmx76/l/jcw4PWhysYWG5YHZvbyIZ++860nCRT+eS7FlRpNDP7X91/s+WgM8W+Q== X-Received: by 2002:a05:6871:a18c:b0:3e8:8b6f:9d85 with SMTP id 586e51a60fabf-3f5f8c0fcefmr3507644fac.29.1765749413327; Sun, 14 Dec 2025 13:56:53 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZENn/GjL8u44LFCFJxfgHWaZ69VsNoe/aRaxa+Y8eQcA==" Received: by 2002:a05:6870:f10e:b0:3ea:9b4e:cb29 with SMTP id 586e51a60fabf-3f5f87f3f09ls1389591fac.2.-pod-prod-08-us; Sun, 14 Dec 2025 13:56:48 -0800 (PST) X-Received: by 2002:a05:6808:a5d7:20b0:455:d5d1:8abe with SMTP id 5614622812f47-455d5d1a911mr65144b6e.34.1765749407988; Sun, 14 Dec 2025 13:56:47 -0800 (PST) Received: by 2002:a05:690c:a7cc:b0:780:f7eb:fdf with SMTP id 00721157ae682-78e645626cams7b3; Sun, 14 Dec 2025 13:53:49 -0800 (PST) X-Received: by 2002:a05:690c:f8d:b0:788:20a1:48c0 with SMTP id 00721157ae682-78e66cab94amr159952617b3.12.1765749228518; Sun, 14 Dec 2025 13:53:48 -0800 (PST) Date: Sun, 14 Dec 2025 13:53:48 -0800 (PST) From: Josh Doman To: Bitcoin Development Mailing List Message-Id: <90e7936d-6383-41aa-a9c6-a825ef39f6d2n@googlegroups.com> In-Reply-To: References: <2ac708f3-8e73-4cd5-ba62-be64a2acea04n@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_4208_1648872992.1765749228203" X-Original-Sender: joshsdoman@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_4208_1648872992.1765749228203 Content-Type: multipart/alternative; boundary="----=_Part_4209_1462566577.1765749228203" ------=_Part_4209_1462566577.1765749228203 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 the= =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 - 201= 5)=20 + 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= =20 difficulty adjustment for upgraded nodes, making the difficulty target the= =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 wrote= : > nodes require that the block hash meets the difficulty target determined= =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 locktime= =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 wro= te: *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 intentionally= =20 minimize the timestamp and reduce the legacy difficulty, while=20 simultaneously using a u64 timestamp in the coinbase transaction to enforce= =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 never= =20 halt (provided the soft fork is adopted sufficiently in advance). Formally, given a block of height N and a timestamp T at activation height= =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 determined= =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 and= =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 of= =20 all, it could confiscate coins that are locked to a timestamp, rather than= =20 a block height. The upside is that this is a soft fork, rather than a hard fork, which has= =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 not= =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-attack-= 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-be64a2= acea04n%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/= 90e7936d-6383-41aa-a9c6-a825ef39f6d2n%40googlegroups.com. ------=_Part_4209_1462566577.1765749228203 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I don't think that's a softfork in the same sense as any that hav= e historically been deployed,=C2=A0 as it leaves the older participants ent= irely 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 blo= ck 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 =3D 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 adjustmen= t for legacy nodes is the same as the difficulty adjustment for upgraded no= des, 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. Lockt= ime functionality will still work for block heights, but you'd need a new m= echanism to continue to lock to timestamps. I recall a developer saying tha= t timestamp locking was perhaps a mistake, so perhaps removing it isn't the= worst idea.

Accidental confiscation would proba= bly be the biggest concern, but with sufficient notice, it's likely a non-i= ssue. I doubt there are many coins permanently locked until 2050, for insta= nce.

Josh

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

I don= 't think that's a softfork in the same sense as any that have historically = been deployed,=C2=A0 as it leaves the older participants entirely insecure = and even easily DOS attacked.=C2=A0 You're also left with the locktime func= tionality totally destroyed leaving bitcoin hobbled-- so it's not really fi= xing the timestamp issue.

The long time assumpti= on I know in the community is that normative unwrapping behavior could be a= dopted decades ahead of 2106-- compatibility=C2=A0would be fine until 2106 = and after that point unupdated software would be safely stuck.=C2=A0 That s= eems better to me.



=



On Sun, Dec 14, 2025 at 8:33=E2=80=AFPM Josh Doman <joshs...@gmail.com> wrote:

I saw there is = a discussion about a hard fork to handle the timestamp overflow bug, by mig= rating 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 t= hought it better to make this its own post.

My questio= n is: does BIP54 inadvertently preclude the possibility of a soft fork t= o 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 time= stamp and reduce the legacy difficulty, while simultaneously using a u64 ti= mestamp in the coinbase transaction to enforce the real difficulty target.<= /div>

In short, the "timewarp attack" makes it possibl= e to increment the u32 timestamp by 1 second each block, ensuring the chain= will practically never halt (provided the soft fork is adopted sufficientl= y in advance).

Formally, given a block of height= N and a timestamp T at activation height H:
- if N % 2016 < 2= 015: miners set the legacy timestamp to T + (N - H).
- if N % 201= 6 =3D 2015, miners set the legacy timestamp to min(2^32 - 1, timestamp in t= he coinbase transaction).
- nodes require that the block hash mee= ts the difficulty target determined in the coinbase (in addition to the art= ificially low legacy difficulty target).

This so= lution, of course, doesn't work if the Great Consensus Cleanup is adopted a= nd the "timewarp attack" gets fixed. Also, it will make header and SPV vali= dation more complex, as nodes will need the coinbase transaction and a merk= le proof in order to validate the header chain. Perhaps worst of all, it co= uld confiscate coins that are locked to a timestamp, rather than a block he= ight.

The upside is that this is a soft fork, ra= ther than a hard fork, which has its own advantages. Meanwhile, confiscatio= n concerns could potentially be mitigated by signaling activation several d= ecades in advance.

Is the possibility of a soft = fork worth forgoing the timewarp fix? I'm not sure. A compromise could be t= o expire the timewarp fix after a certain block height, but that introduces= a new set of tradeoffs.

Josh

--
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+...@googlegroups.com.<= br /> To view this discussion visit htt= ps://groups.google.com/d/msgid/bitcoindev/2ac708f3-8e73-4cd5-ba62-be64a2ace= a04n%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/90e7936d-6383-41aa-a9c6-a825ef39f6d2n%40googlegroups.com.
------=_Part_4209_1462566577.1765749228203-- ------=_Part_4208_1648872992.1765749228203--