From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 14 Dec 2025 12:45:45 -0800 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vUsyO-0000ek-EP for bitcoindev@gnusha.org; Sun, 14 Dec 2025 12:45:45 -0800 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-450d5d26c0fsf3119986b6e.3 for ; Sun, 14 Dec 2025 12:45:44 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765745138; cv=pass; d=google.com; s=arc-20240605; b=aw+QhP2+/Pc7rZa2ukIwCtVi8knv5pGg96F057KKpLjO8inqbJYvEFwfh7GtwbySzy Ix66shFSz5h12AR+6xMYwHRas3T0wIRIHxSZMaILAiQekbsIa9uWnli2ExeK2FehSyXu yy7xmgV6u/Qu5hXq1XHN1YMIrSllvdB5TDMfpxMLyFXfvHqtWFBlKimpZhTGmLLaFoWw /ROvBHkVAiQ0xNxmzHgEY1P6kqhHWwXWHtIbcrZTApLDUZkROc1hlVr1F1TthR7mNM96 oUECauKdHxa4F2zjdSFwYqe5Qwh2ryQF3Z+55XLtXchcGt89HSsD8SiDFJEpxQ6opSul H9Mw== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=ATbDryDO9u40eXsmwXMj4ZHcgcKQP5JC1/8le2ZoSyM=; fh=T9fowOry8tNpMf0zld/YiSD1Izhz5ZnDkWoc6AgWjiU=; b=LgoqXc0xx9ZhiyTbW5mUmYdY3MEgNQ9SyaSEUIVLRm/ysEjBk+KFZVPLG9Xc/6oyUs a/sGR22VnOFk5W20i+7fC2JwIbVXytZa8OaKxfT3U4IXPORjK+tQD59KRw00oaBE6+xP BxF9WZccb3rX4zNn7Fgk1GVaZu6za6HjDOBeQOo+2LWEuuSXmdgbk5C68APXh7xPm4Tx oqUV3dH0rYfoyx+7RD61mbi2E2BOQYin+SjnzTBwTET5IKf+33FwpdKNkHnEpBFfxk76 QgA1u3c9yVA72SGcpFPzn9T0/VJRPXkdZDb+cba8eGJfoEtY/SXN8+lHYph4TQCbuIvy f5JA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DnV+O5BJ; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765745138; x=1766349938; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=ATbDryDO9u40eXsmwXMj4ZHcgcKQP5JC1/8le2ZoSyM=; b=M8ISc0xKE1g859KoERvDkiiWxBzY3Pk700T3KD00nHJlfRuOA4bpqwlAP1OK7tJv+p kHuR/OHNWGiZk4yCiCD3mhtKbWodoJ7+CTDBSnrfHFVubJZ+uJrQTrSc3YXbUidrUWr3 AGaRpoaO5S95YUSZyR+L+QIsCyqGvcV0n1aazo0//kjpCIvQNZTfecK3D8EknH3ZsgB8 hZAob4ONJf41SQDOYAuLlsge9T8PziozK3/OtGPKDDP46m/rsiNdicAI0JrmJoqPhMVV OOWYBmPd3hcV4yDmRDYCFcO4EVFwTljKwWUY4MniYfPQyDbIf+aRQRIvbdXBFG4E3WIm iihg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765745138; x=1766349938; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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=ATbDryDO9u40eXsmwXMj4ZHcgcKQP5JC1/8le2ZoSyM=; b=AIHnkQriVMYOTmoYcRAFkNSrN0X4ZXOTteX4Qh55qXAGAoaqnHhzpOp3vdlyXYSah9 gdvWWIyWPkh4ERtvLPwbXWoVxt2K+WmC/IWcNtJACwx8J3C8nX9nObvuEv1Ptf5Q5w6h G+HSONl6z377txqmW2wyPI3O6ys7+g/fTpS05uVXqhWUVW2mWfkWEAWZsx07umEGyhd+ hMWob9u0O0lr9NRpYtuhfIl+7IrdI8kuapW3GZK+XnkEEGE4zxpNK1LRBxFOMqJKANtS jhBDAVJSaV6XyCuXBw4ooHTIlWAnq9SgLDFOOov9U0W8Zh0kPKuL6JSJ3X+FLnDZdc4y wgdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765745138; x=1766349938; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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 :sender:from:to:cc:subject:date:message-id:reply-to; bh=ATbDryDO9u40eXsmwXMj4ZHcgcKQP5JC1/8le2ZoSyM=; b=P5L3lK4n4AlCcLxcvCXS0H5E6wpULTJi6tIfQRjXBzyc5oLAuRi/cMhHkc6MVg2yFT tij3a2d0gQcMyAQRHZ4HBYNPy6dEWm8kJSP7Smja6A928UHEl3rI/y9JK4scC08ScpGn LRhmxVEwMyNTx7ftK6+329Q6SE+HFdMxF6Nf5nw4MX1eNC4vjJXBEZfsv++KSRFFnW57 CIFI9wro4K32fgJBimJ+cyFsJS/i9kRfNJ4ZVu7+lNqTL+++DO/XrQTlPpBsH8AikbXa UdSGqdo4qKqjkjKTHfRToMZ4K2hNoRuhGzf2v2prnvuKC2BM2yQJM8bNKAx+mOb25osB bETQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWwSY66ahssDNb3qjHTM6OfapQV6oxHc8tLwteshDNCVq/lPmd0DIo4dh3guCcxtIqyYglGjTUOgg2l@gnusha.org X-Gm-Message-State: AOJu0YxiDM7PzRQbC6hMQITdY2IaWoDkljSGlXr2ab0zqL8bwtz00J6l m5IqVfXIADBeaXO9m5q5heFLZWHYnv0exRUx1f3TAmymg1CHePsO/Mn3 X-Google-Smtp-Source: AGHT+IHFE99oERn/6qXLqxMCGi3UiXumxTRcWPVdUXz5HH3aXDqk/lJOX3Qnk4lHF7GdL47s7OZ7Cg== X-Received: by 2002:a05:6820:f003:b0:659:9a49:8e09 with SMTP id 006d021491bc7-65b45274393mr4420510eaf.75.1765745137729; Sun, 14 Dec 2025 12:45:37 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWZC+xmF29pIfje9nk6ml+J7BlHtyaQr7hDIEEWzwaldrw==" Received: by 2002:a4a:e781:0:b0:65b:31d3:b4c0 with SMTP id 006d021491bc7-65b4396e5c6ls1060348eaf.2.-pod-prod-06-us; Sun, 14 Dec 2025 12:45:33 -0800 (PST) X-Received: by 2002:a05:6808:1b0b:b0:450:c9c3:a249 with SMTP id 5614622812f47-455ac962848mr4715143b6e.45.1765745133099; Sun, 14 Dec 2025 12:45:33 -0800 (PST) Received: by 2002:a05:620a:226:b0:8b2:e5d4:9264 with SMTP id af79cd13be357-8babe8b35cems85a; Sun, 14 Dec 2025 12:43:37 -0800 (PST) X-Received: by 2002:a05:6102:54aa:b0:5dd:b5a2:b590 with SMTP id ada2fe7eead31-5e8276d8052mr2878934137.16.1765745016513; Sun, 14 Dec 2025 12:43:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765745016; cv=none; d=google.com; s=arc-20240605; b=gXFsaDkWympQfLyLC1WUHIn3ygHJkQMj5v5JeYNZmZlZwpll9OMiYEMmhjoqv92zFG ZbqV5rymes5dSNXIpN6rEYL/44/128bdrC05AL6whK6uHObgYjF7Xi0ho9PbIlZG5Dgk h7/pFr7MNlM6wJH4OZNL+JMGp5PKbiXTkOhLA7K+RqAFSWRAj2PYydovkjS83f3VFwl5 n6miDe6r8YhHO3vPqK3EaLtvOP8SkQ5kY6d1+M1RILM202RQXpNn6bgz9SnXzEy8n2FU mKuN8FZnsaJ9Lz3CZDxLwFyR0qWfT1861AoR66rXchgwdK57hiAix2g/3Q5X6lp5i6p5 7sHg== 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=5UOeYU6k9IoCcpku1K4fjd9QUUwgs5majmO8kBXgMMY=; fh=zw14EGzQje/EQlEB4Z3hSEaC3Thm583Hfs9yKrsDsSY=; b=ZSYNhNNDiN0ga3mwz0waBkx55Tf4hLBwBytYp2jSYTmIFqOICrVmVwRv0+iNK7jNJB tZMIB1FiMvLRyHYcpE8FdZWhk6RcXefkgz5ew8J3fChU51kvdfvzJdhbkxlgLQysbh0N ui2TbU5oDf+GedNIfitKlV0pJbddE4snIKeaieFmTMxxy2JpafG18MHTd//jIEK34qx1 XVmt8Xanf/H2w0n6rDEaagMoaphANEq8MSxN7FDBBH3suChEWmkuL+Zg1DnyU1u/4SCt nv8VB0OqGKUGgmss6Vt3sfXQEDibKXmHxR+68w9EVTKwRwCawX7WfaE4TmzRugfVteAT uE6Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DnV+O5BJ; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com. [2607:f8b0:4864:20::62b]) by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-93f5af1f089si463301241.4.2025.12.14.12.43.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Dec 2025 12:43:36 -0800 (PST) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) client-ip=2607:f8b0:4864:20::62b; Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-29f2676bb21so26939525ad.0 for ; Sun, 14 Dec 2025 12:43:36 -0800 (PST) X-Gm-Gg: AY/fxX69Goyd2WoRkfRturzOyDVH821AQfgM0TJuJ++SJa1bO5TMoC2cKHNbflp+Nr5 bYKO+sAzACwV6AxVTxAmHxsOCrlMkkZXlnAkUH5sXaUuRtoJSSRJ7rnLybnX+Sp2OIQviduPV8B 3BigK0WbYdDGy0A3SjYINhLMH2gh6qDP1GwV1UoTWMuqD1zlqAhnA75oy8Ia13+7OLKeiGxkeV7 K9wApYV7ilRCBTQlPU0N+9ihX0bH142H3qHafFkzjtjdjplOtLR283vyT5FW2naE4ONy4f2d93K VYBog41dovRb/4b8FzrK6RHQSERKZt/trHoajPp+Kxfl6iPlQpA= X-Received: by 2002:a05:701b:2212:b0:11a:4ffb:9849 with SMTP id a92af1059eb24-11f34bbe382mr5837865c88.21.1765745015274; Sun, 14 Dec 2025 12:43:35 -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: Greg Maxwell Date: Sun, 14 Dec 2025 20:43:24 +0000 X-Gm-Features: AQt7F2oqgG927zqD2mzeNinzafeYiSah1xlW5pq9EvVOe7AJKK8NLpqQJ4VEwDE Message-ID: Subject: Re: [bitcoindev] Does GCC preclude a soft fork to handle timestamp overflow? To: Josh Doman Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006641450645ef8c3a" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DnV+O5BJ; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --0000000000006641450645ef8c3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > nodes require that the block hash meets the difficulty target determined in the coinbase (in addition to the artificially low legacy difficulty target). I don't think that's a softfork in the same sense as any that have historically been deployed, as it leaves the older participants entirely insecure and even easily DOS attacked. You're also left with the locktime functionality totally destroyed leaving bitcoin hobbled-- so it's not really fixing the timestamp issue. The long time assumption I know in the community is that normative unwrapping behavior could be adopted decades ahead of 2106-- compatibility would be fine until 2106 and after that point unupdated software would be safely stuck. That seems better to me. On Sun, Dec 14, 2025 at 8: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/= CAAS2fgSTqeE-vxPsn3hfH0d096ycM-rmTVqGSVH3nELeiG885g%40mail.gmail.com. --0000000000006641450645ef8c3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> nodes require that the block hash meets the diff= iculty 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 D= OS attacked.=C2=A0 You're also left with the locktime functionality tot= ally destroyed leaving bitcoin hobbled-- so it's not really fixing the = timestamp issue.

The long time assumption I know i= n the community is that normative unwrapping behavior could be adopted deca= des ahead of 2106-- compatibility=C2=A0would be fine until 2106 and after t= hat point unupdated software would be safely stuck.=C2=A0 That seems better= to me.






On Sun, Dec 14, 2025 at 8:33=E2=80=AFPM = Josh Doman <joshsdoman@gmail.com= > wrote:
=
TLDR: The "timewarp attack" could enable a future sof= t fork that fixes the timestamp overflow bug.

I saw the= re 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 i= n 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 que= stion is: does BIP54 inadvertently preclude the possibility of a soft fo= rk 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 minimiz= e the timestamp and reduce the legacy difficulty, while simultaneously usin= g a u64 timestamp in the coinbase transaction to enforce the real difficult= y 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 a= dopted 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).
<= div>- if N % 2016 =3D 2015, miners set the legacy timestamp to min(2^32 - 1= , timestamp in the coinbase transaction).
- nodes require that th= e block hash meets the difficulty target determined in the coinbase (in add= ition to the artificially low legacy difficulty target).

This solution, of course, doesn't work if the Great Consensus Cl= eanup is adopted and the "timewarp attack" gets fixed. Also, it w= ill make header and SPV validation more complex, as nodes will need the coi= nbase 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 times= tamp, rather than a block height.

The upside is th= at this is a soft fork, rather than a hard fork, which has its own advantag= es. Meanwhile, confiscation concerns could potentially be mitigated by sign= aling activation several decades in advance.

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

--
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/ms= gid/bitcoindev/CAAS2fgSTqeE-vxPsn3hfH0d096ycM-rmTVqGSVH3nELeiG885g%40mail.g= mail.com.
--0000000000006641450645ef8c3a--