From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 15 Dec 2025 08:36:41 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vVBYu-0007xY-F7 for bitcoindev@gnusha.org; Mon, 15 Dec 2025 08:36:41 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-3f578b8136fsf5490214fac.0 for ; Mon, 15 Dec 2025 08:36:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765816593; cv=pass; d=google.com; s=arc-20240605; b=kifZMWGViVTF93cNms8rB/oyJ1RqWtBLMtQAGVQ7EwiPUb53HMc1kr1su5xEHJa3ZT Iy5WTxcWm3kbuSgHhHsNDcvfVoUPTlFHxMLUcHqcXj5o+NHcsR7UhtiSRsBlu1mCb1oj aoWRVg1CQIyfDrTEXPTNUpRYSAG39yKrStmD6e9WiijQfC4UvAztyzUrR5u1FNfwLv+P F40UF6dUAV+a6vRpGWmvVUQK4ViDgg81XiMoxiK9d8XoRWOrVu4rQKVl01DaMSkGLRU+ xaSFVx+D7vhLHLk4GTS3QP6SySQxQ2f/vXEcTCH97zwyeE4plhSaUTEeCiBPeAJX/5// F3Ng== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:dkim-signature; bh=g3mDjWdncIai1OQ0NfDPAXzPbjlf/Pk6qCmm47cu3a4=; fh=Mms5eMBUd8vW98kMxtZFjOWsWJfVUfG4Dqdbyu0Z1QM=; b=bI061PCoxHLn0kZlRHjswroyYaqk80SBEkY9f93HUSOc+7M9HqcucwBMVaxV7Hm5+2 1ccRec7bz8ZfP5YsVjrNOtfAclJIZpUoh79yzIxzZJbJ/1qiBv6pR7oayiN+xJciPGwv y5YXeO/O2maMYn5azs9yX66CIQFVy+BV7C+xPbYRXjHBbadxk3WevZypBprsoFDIfKM0 80AdcmTq/MnxN+a7If17id/POqv3cS4EmnRsdkCXpUzRsRr0PbT6/BsncQHLvRwjeXKb phtR8LL8r4yRE+sM/JcKOU2MuU40njrtBZOVJehJAoL0KfVya4e8J+T1YFzoJ7BZ78xn 9ASw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=AZfWxC2D; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::52a as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765816593; x=1766421393; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=g3mDjWdncIai1OQ0NfDPAXzPbjlf/Pk6qCmm47cu3a4=; b=XFSuC3ebhOecDdVFBzynoXeNOYS3xtmHewLQz829LRoGDjmn902Fwqju8aj6+Nt5Ml piwePbpbVEJAIgSyb0V99ZPwaN26RMijtqtTVsPmz8/sULGKU9jM9WWCPATk6uec7zAM r2NwSWw1Q6JpTd66GufTSgYymEqaTAvnjxlJ1dGokhr6RrP3uHRVtm/Z6Zl4/CW5VOj7 auAGP8ISbfge3CapvHFjjQZo+xpYszDeUem2bdSVpJSnEXW3TWlimTsqJY+2aLI/+pEl fqr1NVX1znMZm/GZDfFAX5xy4pOaO2Fn0tpn4c0/xu60dQCKAEffhJs7MNuEpFxRhiKI K5kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765816593; x=1766421393; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:x-gm-gg :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=g3mDjWdncIai1OQ0NfDPAXzPbjlf/Pk6qCmm47cu3a4=; b=CAFKlHczVW2LJ60kgKM6AMMxQqOp8n4W2gf4ufxJGurHysC+PgNhAfn3xhIU0LHup6 WGvRX+/CzXGhSpzq57o7WYhFSKR/qDFRvFQgvZ7+fiUnBb+Aakk/zj6SJyG9HCJzlPz1 uo87ZWf2B52D1EOW+G5Hfh1iOGQgcvUpp9E+pWYk/hGaRO4lTWVS32ThCm8DRHXXxFC8 rWFlSmefb7N4wO7qUspfZJpGONkiswhr5kx5MMwtlBByVl4hJpfHkotOn+sFz9IxA+0M gBbDv7YpiMK3gaxe8qbLiUixdNUogU+BcfPRda2LH6806CTwr0mWOJEvr0uiC9lak9oo d7Fg== X-Forwarded-Encrypted: i=2; AJvYcCXwrs0BOQ9XgXbnAkB9sRsUKTx5b1oGjthrcUGY1PNQ4JAfG5DcKpsphNwHhfUi2X183oqc4mjk7yeH@gnusha.org X-Gm-Message-State: AOJu0Ywpx4CaYI16z8HqE4vxjz1L6CJlZ0f67TPUaEdqsljQo81A7Tnd KsFXX3CEZThSSIFkMYtKLW+ViHYv4Jh+cH9//eixKMru305KrFbQmIbl X-Google-Smtp-Source: AGHT+IE/apmsxfScuPxiHc8TYqeXXShTaRFbrYG5Dl/rYLx4wdyKviT0xSV9sGNw6Y4BeueNV29l/A== X-Received: by 2002:a05:6870:a188:b0:3e8:92a5:3287 with SMTP id 586e51a60fabf-3f5f8b352edmr5439874fac.1.1765816591716; Mon, 15 Dec 2025 08:36:31 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZnxk3SqhMBhp6+XJIg7xGtXOnSUO6FGG7yr0EPBCyyDw==" Received: by 2002:a05:6870:164a:b0:3ec:4eb6:abba with SMTP id 586e51a60fabf-3f5f877fc23ls1927378fac.1.-pod-prod-05-us; Mon, 15 Dec 2025 08:36:27 -0800 (PST) X-Received: by 2002:a05:6808:148e:b0:450:b7a0:41d3 with SMTP id 5614622812f47-455aca35e3amr5474073b6e.67.1765816587876; Mon, 15 Dec 2025 08:36:27 -0800 (PST) Received: by 2002:a05:6808:a597:20b0:450:d4ca:2ed2 with SMTP id 5614622812f47-455a77a595fmsb6e; Mon, 15 Dec 2025 08:32:05 -0800 (PST) X-Received: by 2002:a17:903:943:b0:29e:9c82:a91e with SMTP id d9443c01a7336-29f23b1406dmr104113165ad.7.1765816322984; Mon, 15 Dec 2025 08:32:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765816322; cv=none; d=google.com; s=arc-20240605; b=IKRPUkJa80oeUy8TC85ZlzkWf75NZX4OPLYVT4TzDj25NYsIpf+qjtowpe77LqULD3 2G4J1rS96nKA6J37R9Jss0106gmJPiwzQfp/rl91nqD8YD3AoCoOwZ4LuYudYYBpCpXy KJkNUwzDkTaCuICyRyuQo5eJ/INp+bz1bX5bKevgcTmF+9WlgflmiEiOs/y0Zhoj+j6Q +cSbzniUvID8QNI7iuQ99DGRpX86TE3dMLmsleMkb0Ck2toVFpchalhy47/fgoN6EydN x69waFK0wEvpZniHcbzlAgR3/qt9sCvOeQ+BfJACXJgArZL9lf7rdTkUHX6XKgIXXwX0 PZqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=6i2z8+smWBL5My4Pvr26/FCJ+96raIWcBkcs6H5iFkc=; fh=1mTg7NYN97h8TestK4/qKwQ6pNXaNGzo1B2J5Psz/e0=; b=A9L0GeZ+k2u4drcZvopQKTar458NnFpiGmQYi1NcyvcmRmF207vt8Hjo1u6Z50Pw6r KgrXmvtvFz3pOy734Sq+4kJWMMPFYOp1rByNW0zFE7n8vI2TwqmHtxVhA0I1R/P4ieoJ SumyuNnQ9CXs4DB0WJ5/qvFHrVen5Mhehd9uVyc/RdTyxXb9GFDYkCkDBp6ukLZYIW7S NZXgnoZcs/nsKJtKyHULTQC4JXC17fV60ewSmu6EGvgb//p98ZeMDMZ5r4MfxPqRKuOz DwKU6ZGi4/8mFHe6R8pZtXMAjkGEG8FiDYdmPpe6xD7GxSQTP3sa0utKr4S4nAKOsmLO rBLQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=AZfWxC2D; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::52a as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com. [2607:f8b0:4864:20::52a]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-29ee9dc9716si5120045ad.6.2025.12.15.08.32.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Dec 2025 08:32:02 -0800 (PST) Received-SPF: pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::52a as permitted sender) client-ip=2607:f8b0:4864:20::52a; Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-bc4b952cc9dso3092482a12.3 for ; Mon, 15 Dec 2025 08:32:02 -0800 (PST) X-Gm-Gg: AY/fxX5Zwb5/eF5whle4uDmk3fYcsVeFrEijy/sPK+U1vJgpQ8vUkTgo+V/Cw20WQSq MN17K50taS/rlzMFxrujFetCUWBZ8LnjhZ0jgY/uKgAaHYrZanQw6KtkbMoP+UNM1rTU7do5TaB 0fS3B66bj5ZxFJbVlalaHFRlanXijMBDxYcdktckStmTGt2wvjrIRnL9z82MhgDHoeyJFpyFHQ/ KqY3if/b1oOjxPRbummPKf96hYHaN5mDUDvSbcEaGvJ0KwRhM1Ly9PcsE4jhRha212yT6R1 X-Received: by 2002:a05:7301:4290:b0:2a4:61a1:c0d5 with SMTP id 5a478bee46e88-2ac3012e79emr7140731eec.36.1765816321850; Mon, 15 Dec 2025 08:32:01 -0800 (PST) MIME-Version: 1.0 References: <2ac708f3-8e73-4cd5-ba62-be64a2acea04n@googlegroups.com> In-Reply-To: <2ac708f3-8e73-4cd5-ba62-be64a2acea04n@googlegroups.com> From: "'Russell O'Connor' via Bitcoin Development Mailing List" Date: Mon, 15 Dec 2025 11:31:49 -0500 X-Gm-Features: AQt7F2q0WYOrAia6fnTUMfBm_QerdvziayRMQ7Pl3YIKnwKXbFAkNZoaX4gCjJg Message-ID: Subject: Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? To: Bitcoin Development Mailing List Cc: Josh Doman Content-Type: multipart/alternative; boundary="0000000000009a4ed10646002647" X-Original-Sender: roconnor@blockstream.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=AZfWxC2D; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::52a as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com X-Original-From: "Russell O'Connor" Reply-To: "Russell O'Connor" 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: -1.0 (-) --0000000000009a4ed10646002647 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was about to write 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 will destroy existing transaction's timelock semantics. Now I think the best is to have a hardfork. On Sun, Dec 14, 2025 at 3:33=E2=80=AFPM Josh Doman w= rote: > *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 intentional= ly > minimize the timestamp and reduce the legacy difficulty, while > simultaneously using a u64 timestamp in the coinbase transaction to enfor= ce > 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 nev= er > 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 > 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 coinbase transaction). > - nodes require that the block hash meets the difficulty target determine= d > 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 a= nd > SPV validation more complex, as nodes will need the coinbase transaction > and a merkle proof in order to validate the header chain. Perhaps worst o= f > all, it could confiscate coins that are locked to a timestamp, rather tha= n > a block height. > > The upside is that this is a soft fork, rather than a hard fork, which ha= s > 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 no= t > 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-attac= k-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-be64= a2acea04n%40googlegroups.com > > . > --=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/= CAMZUoK%3DKqPTXCuBhy9O5YDXrLhRQMZJ25qAvTtRrE78s8SZniQ%40mail.gmail.com. --0000000000009a4ed10646002647 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was about to write this email myself, but then I realize= d that since BIP 113, timelocks are based on MTP time, and any soft-fork me= chanism that messes with MTP time will destroy existing transaction's t= imelock semantics.=C2=A0 Now I think the best is to have a hardfork.
<= br>
On Sun, Dec 14, 2025 at 3:33=E2=80=AFPM Josh Doman <joshsdoman@gmail.com> wrote:
=
TLDR: T= he "timewarp attack" could enable a future soft fork that fixes t= he timestamp overflow bug.

I saw there is a discussion = about a hard fork to handle the timestamp overflow bug, by migrating from u= 32 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 bet= ter to make this its own post.

My question is: does B= IP54 inadvertently preclude the possibility of a soft fork to handle timest= amp overflow?

Conceptually, I think you could im= plement 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 i= n 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 = =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 soluti= on, of course, doesn't work if the Great Consensus Cleanup is adopted a= nd the "timewarp attack" gets fixed. Also, it will make header an= d 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, con= fiscation concerns could potentially be mitigated by signaling activation s= everal 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
<= div>

--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/2ac708f3-8e73-4cd5-ba62-be64a2acea04n%40googlegrou= ps.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/bitcoindev/CAMZUoK%3DKqPTXCuBhy9O5YDXrLhRQMZJ25qAvTtRrE78s8SZniQ%40ma= il.gmail.com.
--0000000000009a4ed10646002647--