From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 18 Dec 2025 17:49:52 -0800 Received: from mail-qt1-f186.google.com ([209.85.160.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vWPct-0008Cf-04 for bitcoindev@gnusha.org; Thu, 18 Dec 2025 17:49:52 -0800 Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-4f1dea13d34sf24600431cf.1 for ; Thu, 18 Dec 2025 17:49:50 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1766108985; cv=pass; d=google.com; s=arc-20240605; b=kfKG/vhZLciQdbneoU8Ox1NppX3xmHZ1ETty5redfjnBU3dlOVBIGODGikfKk/C/ha juuUprtggbXDay1wF9RZVkBa8IjOwSIK9lPhhgjxZL1FA+Q9+kqJS7cB0mCJM0CFuyjo anVb7vN66+MqU5C6Z9GD2V3aSGzz19I9284CftsXX5/U3GX0JFa/TGtKgdYCBU8Op/M8 g4qrj68k0F1O1INK2IJ0g0yeagtBx3Fw5ycCFUfBdLYI/5j8Ofmp/MA5mapJXXyIuMgz Jh0b1lsNbQFn53WXy6YUbUHe1Fi0xRfgPR4YiG79stOjkNjyW30AyoHNcS/Gc3FrBq63 gC3Q== 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=0QQLNTk28ihaaM2F4YRPbKs/2vp0OQe96RYpyjgtFds=; fh=oVxnG9FZ6YYRKL5Wa0EVZMBYMS+X/I1mNUnYYwupVnU=; b=NcrquBzDaPzSq6XBgQn+OSRvXSdloDZwYZ/dSiaSWsFvDH1K+EHlm5JzntSQGMVtjd rxb9BnzBDjKjnTUAuCDom8ta98B8uzhnSmFMc5DblSAq+cwJqfTd8n/IZUmrJpvK45i0 V24a58y5OTbijRTUGCh8eqXI1Kh+aXhQoJM3htg8mbHf4jRKToJ7q7TkJIdyB5YF0DXy c+ClOqpNc6WpjV2uLgerWo8t8hYX1hJrWAnnnGm5LLDQH1GHq0VE1xRNZUil25yirAuP BTs0svuabMSTQgde6kOO4/JIFCKeTFA+ybs3Yzz/EyeLJC8Z81fGUvrgDFeUOGRCEVaM RAzw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Oec6o6Kw; spf=pass (google.com: domain of 151henry151@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=151henry151@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=1766108985; x=1766713785; 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=0QQLNTk28ihaaM2F4YRPbKs/2vp0OQe96RYpyjgtFds=; b=v1neeWYCw3vFQbmsYmf4BxmPzqcroJOcPJY2vsBgQRlubdoDnNIWMa1XOaY73KqT9T q9uHoky1//LDCXjlL6L7edAf+hKUxPPkhk6mVRRtUm/AeHbW85c2rL1UEsdHPfySazdX csivg32xQTyQbrtKX6bRax8Rm9UcBQlJu5uX/FTFsTCHSQdp9vs+M57jh5zsOnuyFm8m wPIFmDUtyd4UpL+C+VfCPPSdQx5ku2bMkE1YGlzkDV2gxr9j433lPXkNUK8P2/BAkRYu 1omkSUv0yGryw5xoQ/dF3EPT7832tQ/mIKuE5he4D0YtDxAhFVoj/zv5+LpTTPFdueQt da0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766108985; x=1766713785; 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=0QQLNTk28ihaaM2F4YRPbKs/2vp0OQe96RYpyjgtFds=; b=M/NA9KMoHs5laNHLR1LxtXZac4fbXW7EjEJLY2hmEvsMe9wO6I9v1kwpGW+1l0eqtE 2z3ReBpp3JSIoqdlY8XE9qfoeztxMkj9vhm25SBBvZ4Qui3oaZf+xgTeqoBoVyu6gIEs AsRZEWHhx/QLzAwbJmm5X6c9avhwrg9/0x6WuHMxmaZn94TVy41ON5TU2m0LOLcMP6mB Gmnw+Knm4mYKJdreiGqJBxHSjgJujzp1+VGz3J5z98lweQugDzxU1lRt8Xaw0AarKraZ 3UwyAY5VIpQqpWZ1QTQXpY4E20sRiazkYaK8UGi57gGoAbOZkaHXCP2zZZZGtVm/O1jB VA9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766108985; x=1766713785; 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=0QQLNTk28ihaaM2F4YRPbKs/2vp0OQe96RYpyjgtFds=; b=d3PgszE0J9kZCyyNeIzd9z/Ci5fgGDY06T9BRvbN6Pi8gAbgXfNYVh2XSGWHOD6FCL U0UTiZw98EJFIvVtR4D9m8tPn60j+V98vU8aYjB6KCy7xwZ0Ake6sWaT0qSv1nRQZyHA 4M1tOhJCUOsskW8MR+k8Zk6sn2sqvx6gmqqg929zQAiBa6TGm9tHAFDAHgTVk74nL6Ce Wnk2o50kYFzS3G3n066tpbIJzyaNDErVsZKaW8OWhQwGyXKpV2QaaCYYFff/DHJP2TbM opP6TOxl89ejyk7InHdWK//J021gpJ5/2TXlqeDezRNBo5NWsA3nvd9bxAaBFGvv7MSz q+bg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWfxcyMII4TcFYCYetPAqBuuVTuMGaMzKC4s3f9Xmk9HkVDRmP7PW4Cpv4Jy5qXhth2XiKpqi+Ur3HM@gnusha.org X-Gm-Message-State: AOJu0YxOhpW59T6PGd8ng1NYTjA8/vQNU15L6iLtzkB4L5xNPaf1RruF xooWArblInjQCADHMnJi0IO5KSdkJBiTpGa+Q00UKEOhXfur5oWl0tN1 X-Google-Smtp-Source: AGHT+IGZXWR6Z6b35aooyWPy9iuukXFNQKhrJsJUxDkxLZOTnUSFso2JwfAEAKw5dLbbUzShpT/QcQ== X-Received: by 2002:ac8:5882:0:b0:4ee:4126:661c with SMTP id d75a77b69052e-4f4abdcb96emr20044981cf.81.1766108984472; Thu, 18 Dec 2025 17:49:44 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWa3UMvkz2+HG6OqLCumw7TcaFA09jenCkEp/iY/ushgmw==" Received: by 2002:ac8:57d3:0:b0:4ee:217f:a9d9 with SMTP id d75a77b69052e-4f1ce95f679ls120729311cf.0.-pod-prod-03-us; Thu, 18 Dec 2025 17:49:36 -0800 (PST) X-Received: by 2002:a05:620a:45a2:b0:8b2:efb6:5d08 with SMTP id af79cd13be357-8c09040c4e7mr279625885a.60.1766108976835; Thu, 18 Dec 2025 17:49:36 -0800 (PST) Received: by 2002:a05:620a:3a47:b0:8b2:e00e:5a07 with SMTP id af79cd13be357-8be3cac5b0ems85a; Mon, 15 Dec 2025 22:04:41 -0800 (PST) X-Received: by 2002:a05:620a:45a6:b0:89e:f83c:ee0c with SMTP id af79cd13be357-8bb3a3935d8mr1952507385a.74.1765865080371; Mon, 15 Dec 2025 22:04:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765865080; cv=none; d=google.com; s=arc-20240605; b=KE3wk0e5SuvIu1kGd0ChENp/g9rRNTuNneJW/F5cm6IY3InDJQu6vyxY7vOsHzKiNB CC8GbZHxfE9osqxTsgPefiABxhpuFC8A8kLvjWKD0rSu7+99AQNiWj57TXlYqLwZPkFR fdEkqLbEs8+NvtMgBDTlv5Wi/zYa4b3nPu/u6h7gB7oCU4yBITZUGw82f6L04rnM1M2w eTVtla54VYP5jqUBkSmCbevp4eZEThmOt3S02NAQOf+lejk7czKCXZH8YN7QpJNca70F yM+yByTkxFZCwf873rekqsFGWjUMc467LyaUz87M6VKftRk3detEMGPmO95FV02PexyI VpMg== 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=hJ2Vl5pNVYv8VHWSxEpDmXQ6yCQ58cK/FYC4Mme+yls=; fh=zw14EGzQje/EQlEB4Z3hSEaC3Thm583Hfs9yKrsDsSY=; b=J5oMaXTcKFM2rs8npqR4usirHMtvbbxYLKNDY1kN/8P0Q6RTeVmDaM5IflP7z6U2kl mdJsXO3u1ATI8H7a4/sCZaYCqTVvXGI9fCo5WsnuCB8JKCiZYiVx6TAoSFwYgjGcNHFu 1thZEATw3W3p4phzCO7tzH/Fq93RsGJNNXgq57rAoIb4UG3r9iFgG1wwH47FADrXRviZ m5IEHZPussJRX+HBMP9TWu0fvXTmOf6meVaBFFXHxEgwJadHFa1+tpV6qERffB8tTrwW dsTY45O1Css+l2maKluWzfyzP970UrWtFQY/oo+dmj2gKayx3yII76agI5A1JrYzOt1e Epzg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Oec6o6Kw; spf=pass (google.com: domain of 151henry151@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=151henry151@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com. [2607:f8b0:4864:20::1030]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-88987f2cd69si4167786d6.0.2025.12.15.22.04.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Dec 2025 22:04:40 -0800 (PST) Received-SPF: pass (google.com: domain of 151henry151@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) client-ip=2607:f8b0:4864:20::1030; Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-34c277ea011so3148691a91.1 for ; Mon, 15 Dec 2025 22:04:40 -0800 (PST) X-Gm-Gg: AY/fxX7rgcF51dutfiPiUoYMGGG2bWtzYtKaeL+8wHnq88ooQZWIisTDqE4gPz9FdCd dkCxwT7HR3eSsuN+Xt7wqN1UGAtIrU/HR6ZzA/wPSVZctkr4LG441AUnFQWPiSRD1wURA7qzcKl Uzew8ekVe4unDzxwePifI8cVQ6SwKYd0OeRZ9IPIsI1zPBFb286mpxub1KQu+E5iVAB6XEVAd2X qCpQCUjbmX0UIhKEvAMZQreaTLTaBeyeGbDe803lEwCDcd1f6Osnlz2FjPL3A8FYx5xcSYJsXul AdNU X-Received: by 2002:a17:90b:35d2:b0:341:8ac7:24d3 with SMTP id 98e67ed59e1d1-34abd7991d4mr11919193a91.34.1765865079067; Mon, 15 Dec 2025 22:04:39 -0800 (PST) MIME-Version: 1.0 References: <2ac708f3-8e73-4cd5-ba62-be64a2acea04n@googlegroups.com> In-Reply-To: From: Henry Romp <151henry151@gmail.com> Date: Tue, 16 Dec 2025 01:04:24 -0500 X-Gm-Features: AQt7F2oN9y_5tlkmpPQF1OGtIp6ipL-6zcX88ddkuyMRt2DkDRb7BUOvdfc8BEo 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="000000000000c2589806460b806a" X-Original-Sender: 151Henry151@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Oec6o6Kw; spf=pass (google.com: domain of 151henry151@gmail.com designates 2607:f8b0:4864:20::1030 as permitted sender) smtp.mailfrom=151henry151@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: 2.3 (++) --000000000000c2589806460b806a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It looked at first to me like the normative unwrapping approach Greg mentioned would be the best solution, but would that still be breaking timelocked transactions? A change to how timestamp values map to real time across the 2106 boundary, for transactions spanning the transition? Henry On Mon, Dec 15, 2025, 14:30 Josh Doman wrote: > > your idea is to have the header nTime used for difficulty adjustment > enforced 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. > > > 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 tha= t > messes with MTP time will destroy existing transaction's timelock semanti= cs. > > Yes, it's unfortunate. There is certainly a tradeoff. On the one hand, > there is a risk of coin confiscation, if the soft fork isn't signaled ear= ly > 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 > smooth and secure upgrade path, developers can write immutable programs > that verify the chain, etc). > > 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 > involved. I'm not suggesting we decide today, but I am suggesting that > BIP54 may be unnecessarily restrictive. > > 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 BIP54 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'Conno= r wrote: > > I was about to write this email myself, but then I realized that since BI= P > 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+...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/2ac708f3-8e73-4cd5-ba62-be64= a2acea04n%40googlegroups.com > > . > > -- > 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/e7a70843-a304-4d04-9365-08b8= b4259caen%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/= CAPnXYtOd9egA1RZ2LypBQjO7YWpgsYWThz7Tn-hKYd44o0-xsQ%40mail.gmail.com. --000000000000c2589806460b806a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It looked at first to me like the normative unw= rapping approach Greg mentioned would be the best solution, but would that = still be breaking timelocked transactions? A change to how timestamp values= map to real time across the 2106 boundary, for transactions spanning the t= ransition?


Henry
=

On Mon, Dec 15, 2025, 14:30= Josh Doman <joshsdoman@gmail.com> wrote:
> your idea is to have the header = nTime used for difficulty adjustment enforced in the coinbase tx.

<= /div>
Correct. As written, BIP54 makes that soft fork impossible, leavi= ng a hard fork as the only option to resolve nTime overflow.

=
> 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 mec= hanism that messes with MTP time will destroy existing transaction's ti= melock semantics.

Yes, it's unfortunate. There= is certainly a tradeoff. On the one hand, there is a risk of coin confisca= tion, if the soft fork isn't signaled early enough (a few decades in ad= vance is probably sufficient). On the other hand, there are material benefi= ts to avoiding a hard fork (i.e. you get a smooth and secure upgrade path, = developers can write immutable programs that verify the chain, etc).
<= div>
I think it's presumptive to assume which option a fu= ture generation would prefer, in the year 2070, 2080, 2090, 2100, etc, give= n the tradeoffs involved. I'm not suggesting we decide today, but I am = suggesting that BIP54 may be unnecessarily restrictive.

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 BIP54 there (in addition to ot= her 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 - 20= 15) 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 since BIP = 113, timelocks are based on MTP time, and any soft-fork mechanism that mess= es with MTP time will destroy existing transaction's timelock semantics= .=C2=A0 Now I think the best is to have a hardfork.

On Sun, Dec 14, 2025 at 3:33=E2=80=AFPM Josh Doman <<= a rel=3D"nofollow noreferrer noreferrer">joshs...@gmail.com> wrote:<= br>
TLDR: The "= ;timewarp attack" could enable a future soft fork that fixes the times= tamp overflow bug.

I saw there is a discussion about a = hard fork to handle the timestamp overflow bug, by migrating from u32 to u6= 4 timestamps.[1] I considered making this post in that thread, but as it ha= s more to do with the Great Consensus Cleanup [2], I thought it better to m= ake this its own post.

My question is: does BIP54 ina= dvertently preclude the possibility of a soft fork to handle timestamp over= flow?

Conceptually, I think you could implement = a soft fork that resolves the timestamp overflow bug, by using the "ti= mewarp attack" [3] to intentionally minimize the timestamp and reduce = the legacy difficulty, while simultaneously using a u64 timestamp in the co= inbase transaction to enforce the real difficulty target.

In short, the "timewarp attack" makes it possible to incr= ement the u32 timestamp by 1 second each block, ensuring the chain will pra= ctically never halt (provided the soft fork is adopted sufficiently in adva= nce).

Formally, given a block of height N and a ti= mestamp 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 diff= iculty target determined in the coinbase (in addition to the artificially l= ow legacy difficulty target).

This solution, of co= urse, doesn't work if the Great Consensus Cleanup is adopted and the &q= uot;timewarp attack" gets fixed. Also, it will make header and SPV val= idation more complex, as nodes will need the coinbase transaction and a mer= kle proof in order to validate the header chain. Perhaps worst of all, it c= ould confiscate coins that are locked to a timestamp, rather than a block h= eight.

The upside is that this is a soft fork, rat= her than a hard fork, which has its own advantages. Meanwhile, confiscation= concerns could potentially be mitigated by signaling activation several de= cades in advance.

Is the possibility of a soft for= k 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 introduce= s a new set of tradeoffs.

Josh

--
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+...@googlegrou= ps.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2ac708f3-8e= 73-4cd5-ba62-be64a2acea04n%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 bitcoindev+unsubscribe@googlegroups= .com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e7a70843-a304-4d04= -9365-08b8b4259caen%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/ms= gid/bitcoindev/CAPnXYtOd9egA1RZ2LypBQjO7YWpgsYWThz7Tn-hKYd44o0-xsQ%40mail.g= mail.com.
--000000000000c2589806460b806a--