From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 15 Dec 2025 11:30:51 -0800 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vVEHS-000321-IN for bitcoindev@gnusha.org; Mon, 15 Dec 2025 11:30:51 -0800 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-3f9ac407848sf2387950fac.2 for ; Mon, 15 Dec 2025 11:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765827044; x=1766431844; 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=XLwAZFtmIslMrjARCejPghE3xVU4lzm4dHwtSj1vxBA=; b=jZLtdOptjn5k2VNyL5rELZKhlq+v86qmj1sDmkugih6wkbcnQJGnmK6uD+wBxx19Lo PYNILRq0wgnhiz4VgcV6y/kG56nYp2c8OETJK05rv4Rx2IOsxDHrTLhnCheSoxmMyuYC 3VkwHlp5/ug7NxYLfHtYuX8x1HNihDYllDPXIYCrA2oSJ5ZhE9ewK6hEYuv/e6USEm1v S/gyPs8RHWBwk/TqFda/JDf+rM+8ZKF2EBLa3BO1L5Zg21k16tIN0XyHtCjt13lGOEEH 41/gqiVaxaxJAzD+4BdYjcnINIxED3FiLl5XMf2VPmMdFeM0vH1ZEFjmiXsV5k32z5zN IYpw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765827044; x=1766431844; 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=XLwAZFtmIslMrjARCejPghE3xVU4lzm4dHwtSj1vxBA=; b=nmzoA3mpCG0cB3FIjnCHRTb9zpdfnPzQ1mJef2krq7/PQf/lHIP1ui6mOyAMzdzD8X 5f7y3bYvVU8qujqw5O+8C7eRMmy0wtO6poV0NNkvMX2WlRVeXTHEB7x86iruDg0lUxOu ucUClFiZiHRLwptM7T/ptiLbZRnjkNHTHd1eYA72bemImrOm7rMiN58QdHR1vpAO5942 wnPC07PfdwoWlQEXVQUDrfmnkzVOrNbvQ9qjNRzhrz0g6xrTmJ4tKTj9pM3LN3PGBDUD pMLCj1wqUcrJWTzHLTHDA24w1g1wEF50Qo+gccAvIvm7/PHj08+ZNCz4QoVEU4xsVc8b A2hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765827044; x=1766431844; 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=XLwAZFtmIslMrjARCejPghE3xVU4lzm4dHwtSj1vxBA=; b=SRaPkEVITCIqEUdIn0XG8P11lNlGDPvZbtpx3UjQLwpXVNy/0YiDLnBWoGp5XbhVC6 Fqtk72bYWyIJD8wSXyHVgfhKhmShIATUy3+8rafY34RRAEMXTwRG7hcLuInJRvPpMuJx EWU5X8q3OJ+2oL+dFjyF6liY5Ew9BB9tsTEhlxDZdOePFsrUzCSHD/2rjYt1TABahUbu 693pZbQ3QRIT4GUS2eHQwEFNuX38kbigciH5UNbDbcw0jeVNHVBKi7BPeAQohXGC5rJf UjzvhdvXmd4n/FsObAVyRYBNqRvXfE+kvXGjzpCk5mhaSiZox6o9q7t0lEu+1K40j8pt 4Nlg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWLA6ZzTgIh93N6kOsOiNaAYmo/6lxBo0FB9YtqIyGujQxDgchCOSKv7k7fGJTK4o4IJP/ZZt4ayr7+@gnusha.org X-Gm-Message-State: AOJu0Yw64Ws+SP+G3frFkDk4MUMSuzgs/aCw4LDU92jUGV7NdCB97GLv y7BWqrugatG1sDUNVVk59VWPXlBAS+Y6NItsK6C3OBO4UiVpExLZR9ys X-Google-Smtp-Source: AGHT+IEgeW+kGBOuqpG6BrASTrR6IEoZtusu4NUN1od3XLq3zUyhSE7dNMZPOmr3pKHrEJjCyz+CUA== X-Received: by 2002:a05:6870:d608:b0:3f1:49d6:ab16 with SMTP id 586e51a60fabf-3f5f8dc75bamr5821012fac.45.1765827044377; Mon, 15 Dec 2025 11:30:44 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZwoADoRsYKea0bMKXClBmbes6qllfoUT2ZqwK6OprKcg==" Received: by 2002:a05:687c:41:10b0:331:5ba5:afd3 with SMTP id 586e51a60fabf-3f5f8780279ls1730072fac.1.-pod-prod-07-us; Mon, 15 Dec 2025 11:30:40 -0800 (PST) X-Received: by 2002:a05:6808:219a:b0:44f:e471:b52e with SMTP id 5614622812f47-455ac829b24mr5613411b6e.11.1765827040258; Mon, 15 Dec 2025 11:30:40 -0800 (PST) Received: by 2002:a05:690c:48c1:b0:786:6c46:840 with SMTP id 00721157ae682-78e642e9732ms7b3; Mon, 15 Dec 2025 09:28:00 -0800 (PST) X-Received: by 2002:a05:690c:4b0e:b0:786:5be2:d467 with SMTP id 00721157ae682-78e66d45ca3mr88427627b3.3.1765819679561; Mon, 15 Dec 2025 09:27:59 -0800 (PST) Date: Mon, 15 Dec 2025 09:27:58 -0800 (PST) From: Josh Doman To: Bitcoin Development Mailing List Message-Id: 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_5052_1902687339.1765819678911" 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_5052_1902687339.1765819678911 Content-Type: multipart/alternative; boundary="----=_Part_5053_996458011.1765819678911" ------=_Part_5053_996458011.1765819678911 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > your idea is to have the header nTime used for difficulty adjustment=20 enforced in the coinbase tx. Correct. As written, BIP54 makes that soft fork impossible, leaving a hard= =20 fork as the only option to resolve nTime overflow. > I was about to write this email myself, but then I realized that since=20 BIP 113, timelocks are based on MTP time, and any soft-fork mechanism that= =20 messes with MTP time will destroy existing transaction's timelock semantics= . Yes, it's unfortunate. There is certainly a tradeoff. On the one hand,=20 there is a risk of coin confiscation, if the soft fork isn't signaled early= =20 enough (a few decades in advance is probably sufficient). On the other=20 hand, there are material benefits to avoiding a hard fork (i.e. you get a= =20 smooth and secure upgrade path, developers can write immutable programs=20 that verify the chain, etc). I think it's presumptive to assume which option a future generation would= =20 prefer, in the year 2070, 2080, 2090, 2100, etc, given the tradeoffs=20 involved. I'm not suggesting we decide today, but I am suggesting that=20 BIP54 may be unnecessarily restrictive. The following modification to BIP54 would resolve the timewarp attack while= =20 leaving open the possibility of an nTime soft fork: 1) Add a u64 timestamp to the coinbase and enforce BIP54 there (in addition= =20 to other timestamp rules) 2) Given a block of height N, where N % 2016 =3D 2015, the difference betwe= en=20 the nTime and the nTime at height (N - 2015) must be the same as in the=20 coinbase. On Monday, December 15, 2025 at 11:36:31=E2=80=AFAM UTC-5 Russell O'Connor = wrote: I was about to write this email myself, but then I realized that since BIP= =20 113, timelocks are based on MTP time, and any soft-fork mechanism that=20 messes with MTP time will destroy existing transaction's timelock=20 semantics. Now I think the best is to have a hardfork. On Sun, Dec 14, 2025 at 3: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/= e7a70843-a304-4d04-9365-08b8b4259caen%40googlegroups.com. ------=_Part_5053_996458011.1765819678911 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > your idea is to have the header nTime used for difficulty adjustment e= nforced 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 wri= te 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 w= ill destroy existing transaction's timelock semantics.

Yes, it's unfortunate. There is certainly a tradeoff. On the one han= d, there is a risk of coin confiscation, if the soft fork isn't signaled ea= rly 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 s= mooth and secure upgrade path, developers can write immutable programs that= verify the chain, etc).

I think it's presumptiv= e 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 w= e decide today, but I am suggesting that BIP54 may be unnecessarily restric= tive.

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 BIP= 54 there (in addition to other timestamp rules)
2) Given a block = of height N, where N % 2016 =3D 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=E2=80=AFAM UTC-5 Russell O'Connor wrote:
I was about to write this email myself, but then I realized that s= ince BIP 113, timelocks are based on MTP time, and any soft-fork mechanism = that messes with MTP time will destroy existing transaction's timelock sema= ntics.=C2=A0 Now I think the best is to have a hardfork.

On Sun, Dec 14, 2025 at 3:33=E2=80=AFPM Josh Doma= n <joshs...@gmail.com> wrote:
=
TLDR: The "timewarp attack" could enabl= e a future soft fork that fixes the timestamp overflow bug.

I saw there is a discussion about a hard fork to handle the timestam= p overflow bug, by migrating from u32 to u64 timestamps.[1] I considered ma= king this post in that thread, but as it has more to do with the Great Cons= ensus Cleanup [2], I thought it better to make this its own post.

My question is: does BIP54 inadvertently preclude the possib= ility 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 intention= ally minimize the timestamp and reduce the legacy difficulty, while simulta= neously using a u64 timestamp in the coinbase transaction to enforce the re= al difficulty target.

In short, the "timewarp at= tack" makes it possible to increment the u32 timestamp by 1 second each blo= ck, ensuring the chain will practically never halt (provided the soft fork = is adopted sufficiently in advance).

Formally, g= iven 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).<= /div>
- if N % 2016 =3D 2015, miners set the legacy timestamp to min(2^= 32 - 1, timestamp in the coinbase transaction).
- nodes require t= hat 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 Consensu= s Cleanup is adopted and the "timewarp attack" gets fixed. Also, it will ma= ke header and SPV validation more complex, as nodes will need the coinbase = transaction and a merkle proof in order to validate the header chain. Perha= ps worst of all, it could confiscate coins that are locked to a timestamp, = rather than a block height.

The upside is that t= his is a soft fork, rather than a hard fork, which has its own advantages. = Meanwhile, confiscation concerns could potentially be mitigated by signalin= g 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 heigh= t, 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/e7a70843-a304-4d04-9365-08b8b4259caen%40googlegroups.com.
------=_Part_5053_996458011.1765819678911-- ------=_Part_5052_1902687339.1765819678911--