From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 14 Dec 2025 12:33:36 -0800 Received: from mail-oi1-f189.google.com ([209.85.167.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUsmd-0000Z5-IV for bitcoindev@gnusha.org; Sun, 14 Dec 2025 12:33:36 -0800 Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-4501fcc3affsf2344234b6e.2 for ; Sun, 14 Dec 2025 12:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765744409; x=1766349209; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=figgkf8QD6rhzkD/eK4ol3v+PalFWBJZVhz/7sSSVyc=; b=Uphb4jZObTg53KbpOHQ6UVY3rgzGodMpf/7moN0rz2WIsYFhKyJksQMsQjnRp305Ui 6nLF2NfCyNiy8MDgzBjEBdEy99NzDvK/5h4FFHv8nKpJyENJdKarvjY+8Il1MiTQ+Ar2 8VZNK/UoJhe9ZT6K08IYyXzV0ypGB6r/wmqH7hTxYkasWo2Hps68AoNCFOmRiqj4M/f6 1HdTFAyerQuqGmzG3ja79300yQfjnZMn+wqn9z1ROAm2kriLTcsyTaUG7zxh+t1S05J9 375fzmGmPXKRYtqFox94JjSQp3+goRqffuiYociSiOschgRNACSWZBZZhHTzFQxNkMD/ HdwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765744409; x=1766349209; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=figgkf8QD6rhzkD/eK4ol3v+PalFWBJZVhz/7sSSVyc=; b=m3YPv1SXma+ceRj8NmZOXY2SH0Z4PRcRKpORL1Tmp/QXllkFSNJBaqB8hEtFMCkJCS 7mD4r5lv4gJFZOyV9LKPxKDrlVUpaLGmmJYhHjmD5Jlvzxc3p9UD0yX6UetwcSyFAoJ5 vZO87HSjgcbhmP4g1zTgyAclKQNNtpl6SkD9DKIvpFiHyjUU5iz/zClDQOuM6lm/+FMG ipmRSalkiydHc1A+ONzHQ6NW7wh/r8ICZuG3Ja0oymhExA70qV5F9i7IlRS4a7yZ7snl rKISgjzLur4p5dT781MG/KPs/tiGfEL/WRMdmYv5oQp9fLicYkDftgE/Y6387Kl/WjBi Rmjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765744409; x=1766349209; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=figgkf8QD6rhzkD/eK4ol3v+PalFWBJZVhz/7sSSVyc=; b=oceHVn1UCRdnQ7NvbmWlYQzI6BQPWNPrb+dYt4VQYdCl7nuP/khLigsH4AoPzBskWh 2CPtr84sX3YJM5Cq23nqzCsbHJGEbtSayCYPMw1NSJUd9WEE3pNRTK/vzxP8DeHlj8il aEAsm2gnDyTy0eVXU1DpLll+Cweae4djGOXoQyT5hBtn5r8Bdt1oew3MEAlOxJViEuiA PkHXWpIChbuop5P2vHDn4cP6Z6MVF2j/ph2F4Awcc+RYH7h/eQUIB4Mia3P5qvgQTImF Xcb4K5FcR/sjQizhiYnXnxRYxz0EYuhz6W6oEFqiKXEqHbJ5bLe7e7qscwdBL407//6J E2FQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUmcoB8iGf7ZWKn8Phwt7cysuwl7Xf/jGX5Ppw3QzcUWyeB2IG5K3pPyCds0A8ClFKwA0mDl4ifPpCq@gnusha.org X-Gm-Message-State: AOJu0YyJBws/1n8HrsKkrUo/7KkmE+ZGGpTmwzMAs9+sbl8DtW9vd/l3 wWU2xjBkJ2XJF3oZXMZqJuAk/SeUnu+uu4Zrhu56POgXUkvLj5+H9zbe X-Google-Smtp-Source: AGHT+IFGt7E3x3D87OXATK9+U5ZGkWA5hwkmURqjjcD1Wj5bMtZl6WnGgm6wmIS4bvyHt5q4OLwiAg== X-Received: by 2002:a05:6870:8884:b0:3ec:a08c:9707 with SMTP id 586e51a60fabf-3f5f890ed35mr4488673fac.42.1765744409281; Sun, 14 Dec 2025 12:33:29 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZ6n91kO3rfMhXd2RFTaev40r9KudH1cPROG9KZMviczw==" Received: by 2002:a05:6871:3390:b0:3e7:e63d:723c with SMTP id 586e51a60fabf-3f5f8b7566dls1022343fac.2.-pod-prod-00-us; Sun, 14 Dec 2025 12:33:24 -0800 (PST) X-Received: by 2002:a05:6808:c2a9:b0:450:4164:141e with SMTP id 5614622812f47-455ab7bcdb0mr4744942b6e.33.1765744404253; Sun, 14 Dec 2025 12:33:24 -0800 (PST) Received: by 2002:a05:690c:a7cc:b0:780:f7eb:fdf with SMTP id 00721157ae682-78e645626cams7b3; Sun, 14 Dec 2025 11:45:11 -0800 (PST) X-Received: by 2002:a05:690e:1483:b0:645:5284:2388 with SMTP id 956f58d0204a3-6455513f19amr6062356d50.6.1765741510992; Sun, 14 Dec 2025 11:45:10 -0800 (PST) Date: Sun, 14 Dec 2025 11:45:10 -0800 (PST) From: Josh Doman To: Bitcoin Development Mailing List Message-Id: <2ac708f3-8e73-4cd5-ba62-be64a2acea04n@googlegroups.com> Subject: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3476_366935801.1765741510694" 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_3476_366935801.1765741510694 Content-Type: multipart/alternative; boundary="----=_Part_3477_107441497.1765741510695" ------=_Part_3477_107441497.1765741510695 Content-Type: text/plain; charset="UTF-8" *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. ------=_Part_3477_107441497.1765741510695 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TLDR: The "timewarp attack" could enable a future soft fork tha= t fixes the timestamp overflow bug.

I saw there is a = discussion about a hard fork to handle the timestamp overflow bug, by migra= ting from u32 to u64 timestamps.[1] I considered making this post in that t= hread, but as it has more to do with the Great Consensus Cleanup [2], I tho= ught 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 t= hink you could implement a soft fork that resolves the timestamp overflow b= ug, by using the "timewarp attack" [3] to intentionally minimize the timest= amp and reduce the legacy difficulty, while simultaneously using a u64 time= stamp 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 w= ill 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 < 201= 5: 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= coinbase transaction).
- nodes require that the block hash meets= the difficulty target determined in the coinbase (in addition to the artif= icially low legacy difficulty target).

This solu= tion, 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 valida= tion 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 coul= d confiscate coins that are locked to a timestamp, rather than a block heig= ht.

The upside is that this is a soft fork, rath= er than a hard fork, which has its own advantages. Meanwhile, confiscation = concerns could potentially be mitigated by signaling activation several dec= ades in advance.

Is the possibility of a soft fo= rk 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]=C2=A0https://groups.google.com/g/bitcoindev/c/PHZEIRb04RY<= /div>
[2] https://github.com/bitcoin/bips/blob/master/bip-0054.md
=
[3] https://bitcoin.stackexchange.com/questions/75831/what-is-ti= me-warp-attack-and-how-does-it-work-in-general/75834#75834

--
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/2ac708f3-8e73-4cd5-ba62-be64a2acea04n%40googlegroups.com.
------=_Part_3477_107441497.1765741510695-- ------=_Part_3476_366935801.1765741510694--