From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 18 Dec 2025 17:49:52 -0800 Received: from mail-qv1-f57.google.com ([209.85.219.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vWPcu-0008Ci-Cj for bitcoindev@gnusha.org; Thu, 18 Dec 2025 17:49:52 -0800 Received: by mail-qv1-f57.google.com with SMTP id 6a1803df08f44-88a32bd53cdsf42842056d6.0 for ; Thu, 18 Dec 2025 17:49:52 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1766108986; cv=pass; d=google.com; s=arc-20240605; b=lvYcXSroRMnOIzyV4Dc0lJKUX+n7Tcgu1yml2t331putVx0Ke/fQO2ibNhqGb1U351 f2MQ/gFZ5KulF3MzKXZ/YLPOTScPqCx9gGeNwSxXAcCUTBZEZuNWS5F6q1rjnHOf2lkB 6FWPFSoOnpa9R5lN+vYrfNa2BDUGlEpd5J5duggKcNdxFjJJbRKfR7Qkg6dV8D9vO0xf rM6uWq6jGGzBM0REPAT32hon5UfYGNjkdvBHIvwrV4kYCqKJfyp3311F9JABXAkxEhwP nKt5GhEubuUkj0qXDRH+Q6coIVzCCMT7iK9CUleKefx2kGXyiaVU5EeYvDGpsOcgoN1O ukIQ== 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:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=+7xRmlFwbtq68agvET4zEPRG/dSkm+eWjID7tDleAwU=; fh=DpRyQpg8DXkEYeA4xyI/J1M/Oug3Dtkp8fNPq5PtgDQ=; b=ZOAa+gIfQFovOa9ZrPZpHyplfXWu+cWQhMIDG62R8bQdhpnAo5GzVIrfhDuxH1VD5n rFww5IajuEZ3I9OhjNuttKxxUgt1HST7J2FaUQSkpvafQxrVOywxKkZozxa2xEJiQuzB HJzzMXZlqsiFpLnKt2skX+qiRN2jcx6iBM6wh9qWM6eQfZkIWfSZOzsbZTkgur/I8Q71 WzS4z5qzTwAwZjZD9JrBBlDPzHoHLZxlI1OvV0eCMX2sGw/eXfDf6jf2Oa0YrQDoc7Qb ZI3xiygCKVDHX9IOO5MxpTIvi5n3ixVyNbxRjnJ4/2qL+N8M5QW9FdS3J5vshLXRSFCY dSRA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=VHyHOeXW; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1766108986; x=1766713786; 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 :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=+7xRmlFwbtq68agvET4zEPRG/dSkm+eWjID7tDleAwU=; b=rbJpp/p5kWYDD/2B/1UOegvrvrMObpoanoecnZ7EqeNVT5iC9UGlnLSb1/RfDmRlGM ZxyQQLGPMs85QYs3KSvZBiv2sIw8hkATPTJmHD/jFJanGolc6iM5sAXM+2g10EPwn7EC EWV4dsGeJ6Rcp9eOtMP6XMBDwlNfkU5WhO1MfIIzH7x/Zc/hepQcNXnJqEp4lhIiNJlY u3Hodds7Us3hWY4yIcslKJkdqNwHLrjPsFYhIk3v5+piV0P4xKs50p/xNvyegXlLFuBg hjFSAgUqs+eaYROrCopwUrNgl4J5VLBiWaXSqlQplpq2yZ3RERVa9dRpRbH/7PCvFSOq Gc8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766108986; x=1766713786; 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 :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+7xRmlFwbtq68agvET4zEPRG/dSkm+eWjID7tDleAwU=; b=JJq1wnPmiTUGBHz1iRJS7bsAUyYz9H45t11zAwNIQQbnlSHOEaUpW4IhqYcVAEDuFC gJl3TeHkwDWyQbViW45ddaIWI6Y4EMZOZmWrrCUsBbmsLQJ8tmRWE0Tq718gFpk2scka Qa9aF08j4EWFPNN4ZgM1/3adcJ4aOnsfeJ15BG8PCcByTJM1X6i+sqDVWDe5lXNWNblh efJtageRbI1HHFL/rccDm/t82LKi7z9Rv1a5Yly9L3+sicHGCuVtpImSbi9m/JG9MTJv OiorfGSLAkQLTJE+Xcc4WcWzG1TEW5lqKmwBCTxFW3onDJwgKapBDHECoN5471/BKv83 r1qw== X-Forwarded-Encrypted: i=2; AJvYcCXa8n+9ivt74GRsfIqdtZKX++XpW0iHdZcXZ9Pk4YyYKOEVZ78a8lq9HvfEa9pAvuW3foQ3LqfiMBtl@gnusha.org X-Gm-Message-State: AOJu0YyaJw85qBecQrZx3n5ZpsUvS0AH6RVsNOcN2enKRrepYv9Uu2w6 KfA5R/KV4P+aMUufqIHiVCW/9406wPk7nXEG2cfDOJEOoc62YSTE7SiC X-Google-Smtp-Source: AGHT+IF+jBE2Dp1CjPWNcJ7CllCvQNX7g0VPqI7/1vHeakoMaD8bhSYOdQB4DdShT+X1hM/BU4guuQ== X-Received: by 2002:a05:6214:5787:b0:880:572e:4565 with SMTP id 6a1803df08f44-88d847281admr25257116d6.60.1766108985956; Thu, 18 Dec 2025 17:49:45 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZhXkwwADdlLU7/FkdPAZsPjgsaCjUP1e9hoyXDguPe0Q==" Received: by 2002:a05:6214:4105:b0:882:7510:5ec3 with SMTP id 6a1803df08f44-8887cdb8cc1ls107764856d6.2.-pod-prod-04-us; Thu, 18 Dec 2025 17:49:36 -0800 (PST) X-Received: by 2002:a05:620a:199f:b0:8b2:7331:28e6 with SMTP id af79cd13be357-8c08fd1a8ddmr275545785a.86.1766108976833; Thu, 18 Dec 2025 17:49:36 -0800 (PST) Received: by 2002:a05:6402:5348:20b0:643:1f87:ab0e with SMTP id 4fb4d7f45d1cf-64b402dfa21msa12; Wed, 17 Dec 2025 06:55:46 -0800 (PST) X-Received: by 2002:a05:6402:146d:b0:640:abd5:864d with SMTP id 4fb4d7f45d1cf-6499b1f1bacmr14888465a12.21.1765983344295; Wed, 17 Dec 2025 06:55:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765983344; cv=none; d=google.com; s=arc-20240605; b=czgtEpoJf8RBiSF12USGJzzR2YehQr5NTK+G5rS4YCbVZrqcXMEzNfqFtCzInMDklB 7cjkqosBiad/zZQBrkdbpU0YDSj8GJLBQmd9X4KJle9F0LIyTjoGqeyd82tJIEYwMrZ4 kn3F2hIXoC871zQfnYeT4X9sPP/MWZHycCcE5HvRqraSonx3fUvyWFD827P7tt50TG/2 jaubcD9Z19AAp5bCLVABi1ZxmYRCO/RUOFCSB6d90p6/A0Ga6vmCUTKo5zmXbW+zizPP rc6THlSaGwK0NJ2gNb4SzJ7EyqVYQKvBvBXtCCmtHauhN+/S1JrhrQYmKQIB5/1tXE57 NSXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=tU5ZuPmK219kKDy6LctYP6uDpNUTxV7tmIQhV/53Fvs=; fh=zw14EGzQje/EQlEB4Z3hSEaC3Thm583Hfs9yKrsDsSY=; b=MLEb1w+cHjgz5nhAE/mUZLCRlFR/T42kNdKbeCB52pxiVbm7wJP0ocphKi40158j92 QPLs6KCqQJwc9tAnpKPZnxMh1YyawCFRsBj2HYhocJTH0GQSoilNSZ6GHt0GD0Hx5ex+ 6YdHGLgkqfwDaD2MZ6DnIybQ7DzyI3K2IkdBTwryj3cd5y6MO5CbuQzvRX/5wgSDpJLq BvUO93E5hnogThtVINRxloizy7e5fom8VcqoB5LlH/c9okkt5NTPysL96b2xiO0Rf7hZ gm/hpdWMn+t08VqDAJngz7oeCpWU14Ljehl4aMk7RSO/P4wpf/y028Q6+moMG80+fxN4 cSWw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=VHyHOeXW; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-106118.protonmail.ch (mail-106118.protonmail.ch. [79.135.106.118]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-64b3f53eaafsi53987a12.3.2025.12.17.06.55.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Dec 2025 06:55:44 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) client-ip=79.135.106.118; Date: Wed, 17 Dec 2025 14:55:40 +0000 To: Josh Doman From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? Message-ID: In-Reply-To: References: <2ac708f3-8e73-4cd5-ba62-be64a2acea04n@googlegroups.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 4fe2d092d024a35c1ee21d796ffe086d5070d869 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=VHyHOeXW; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.118 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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 (-) Hi Josh, Interesting observation! I am of the opinion that the header timestamp overflow is one of those thin= gs that are better addressed through a backward-incompatible consensus change.= As pointed out earlier in response to your post, the MTP rule would prevent a = chain split by making sure the legacy chain halts. Furthermore, even if it was a goal to fix the timestamp overflow through a = soft fork, the issue will arise so far in the future that it does not justify ma= king inferior protocol decisions to fix bugs that exist today (and that could be= come more problematic within the next decade). You came up with a clever hack to address the DoS concern, which somewhat reminds me of forward blocks. It makes it possible to still validate cumula= tive work from a chain of headers, but it relies on actively exploiting Timewarp there. This is unfortunate in itself but also means breaking timestamp-base= d timelocks which, as people pointed out here and on your Delving thread, ent= ails freezing coins that rely on them. Therefore my preference is to fix properly Timewarp with BIP 54, and proper= ly deal with the timestamp overflow when (if?) necessary. Best, Antoine Poinsot On Monday, December 15th, 2025 at 2:30 PM, Josh Doman wrote: > > your idea is to have the header nTime used for difficulty adjustment en= forced in the coinbase tx. > Correct. As written, BIP54 makes that soft fork impossible, leaving a har= d fork as the only option to resolve nTime overflow. >=20 > > 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= . >=20 > Yes, it's unfortunate. There is certainly a tradeoff. On the one hand, th= ere is a risk of coin confiscation, if the soft fork isn't signaled early e= nough (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 smooth= and secure upgrade path, developers can write immutable programs that veri= fy the chain, etc). >=20 > I think it's presumptive to assume which option a future generation would= prefer, in the year 2070, 2080, 2090, 2100, etc, given the tradeoffs invol= ved. I'm not suggesting we decide today, but I am suggesting that BIP54 may= be unnecessarily restrictive. >=20 > The following modification to BIP54 would resolve the timewarp attack whi= le leaving open the possibility of an nTime soft fork: > 1) Add a u64 timestamp to the coinbase and enforce BIP54 there (in additi= on to other timestamp rules) > 2) Given a block of height N, where N % 2016 =3D 2015, the difference bet= ween the nTime and the nTime at height (N - 2015) must be the same as in th= e coinbase. >=20 > On Monday, December 15, 2025 at 11:36:31=E2=80=AFAM UTC-5 Russell O'Conno= r wrote: >=20 > > 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. > >=20 > >=20 > > On Sun, Dec 14, 2025 at 3:33=E2=80=AFPM Josh Doman = wrote: > >=20 > > > TLDR: The "timewarp attack" could enable a future soft fork that fixe= s the timestamp overflow bug. > > >=20 > > > 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 mak= ing this post in that thread, but as it has more to do with the Great Conse= nsus 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? > > >=20 > > > Conceptually, I think you could implement a soft fork that resolves t= he timestamp overflow bug, by using the "timewarp attack" [3] to intentiona= lly minimize the timestamp and reduce the legacy difficulty, while simultan= eously using a u64 timestamp in the coinbase transaction to enforce the rea= l difficulty target. > > >=20 > > > In short, the "timewarp attack" makes it possible to increment the u3= 2 timestamp by 1 second each block, ensuring the chain will practically nev= er halt (provided the soft fork is adopted sufficiently in advance). > > >=20 > > > Formally, given a block of height N and a timestamp T at activation h= eight 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 deter= mined in the coinbase (in addition to the artificially low legacy difficult= y target). > > >=20 > > > 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 transacti= on 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 th= an a block height. > > >=20 > > > The upside is that this is a soft fork, rather than a hard fork, whic= h has its own advantages. Meanwhile, confiscation concerns could potentiall= y be mitigated by signaling activation several decades in advance. > > >=20 > > > 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 certai= n block height, but that introduces a new set of tradeoffs. > > >=20 > > > Josh > > >=20 > > > [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-wa= rp-attack-and-how-does-it-work-in-general/75834#75834 > >=20 > > > -- > >=20 > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+...@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/2ac708f3-8e73-4cd5-ba62-be64a2acea04n%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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/e7a70843-a304-4d04-9365-08b8b4259caen%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/= a7m01C4Xm3-WF9Slrg1b2G8OaZiCXKQncrHW4kD5iVrNq8E-yde2W4pF1ZIU6PeiU-jUeyDCsFn= tfrTw28wW38iIkBeo6OENzlWUsL-hetc%3D%40protonmail.com.