path: root/3e/e15a54b72e5a13ee157fb47e3ca9fbceab87a1

Delivery-date: Sun, 09 Feb 2025 16:15:58 -0800
Received: from mail-yw1-f183.google.com ([209.85.128.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBM4KUW6QMGQEUNVGBSI@googlegroups.com>)
	id 1thHSv-0007aq-27
	for bitcoindev@gnusha.org; Sun, 09 Feb 2025 16:15:58 -0800
Received: by mail-yw1-f183.google.com with SMTP id 00721157ae682-6f6f2db824bsf41724847b3.3
        for <bitcoindev@gnusha.org>; Sun, 09 Feb 2025 16:15:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1739146551; x=1739751351; 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:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=DiFM/SO5RIcoaYLgBk2wtwpmgOVXvXmqB7D6NtT+XWU=;
        b=XqsnXN8jwkepv+2tDrBqglDc2pRy+h5Py/z1mBcR7hHmrfeJoUYYnITafkNMzmmpM4
         1ux30u3m9z5PeFNDXR8AW6dDEoY4aRDLy2PCOQDg2EB+K9P6XGXBXSD6XpELXav1CpZ5
         JzI1xexhYpHosZ6M6cJQwEOEHJxrbwjpz+p1dZ67KL2V3rxI/sNC6/MtYAnNIl7Wv5h+
         XczyDEArtk/8tQFnazn6KrZF3gbqfsdNyyEozWfzS3H1mcrpUXGGkfC7sqhvDVUZ7vm3
         3iI90z3JGw0lBGju/EeL15PyQx7lZAwSPeoB6/OFD+Th+5eZn8ZL1fSMyN+BIYsk69UF
         M3EQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1739146551; x=1739751351; 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:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=DiFM/SO5RIcoaYLgBk2wtwpmgOVXvXmqB7D6NtT+XWU=;
        b=a2XHDieCQ/vcsLzPWsQq9v3kjNFJyErhI/wlU/TOSoscCH/H8V1eD6fB8rkD9DHpLu
         wg1rdelJJurVbo2XkLhSiaRYdP8NlXAj5WZipm+jbzjKFpyYh0xKiJ9Tk1/Kq2fHkFXm
         IjUi47QSsB3kmDpUPXOmu95LbsyKDLR5GzMhrdJFZQ5QRgAX3+0ZaNlcC8bbr2EQQ3rA
         KKS5SAUBnUsts2ZezxxmUiQNCrFnPoZFjxyTwIEOe+Eds/eSjaEN/IyfC8bhysPqBc8o
         oYUg7Dmye3Y/f4ALRGqlexQ0InSKtCfh0Wzf5ZpiyzgwYLx6Bm3QWimC/ip+wPAbO3iQ
         WNJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1739146551; x=1739751351;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=DiFM/SO5RIcoaYLgBk2wtwpmgOVXvXmqB7D6NtT+XWU=;
        b=D0RXBUDPSSgSym1GsJKuix/m6JjmwKygmFAwV9Ta7ya/qU9LO0DtlexP9Z8ixeX24r
         TqY12wKqgG1R3V7052gBPvCkviTZ2EPqHtI7gHHB+3BpZ2nTxxeSe6QEPRfDkN/Q0l7N
         8uU4gVF9MfVH2Lqli/WU+4Av4/jO4IosI6tPe0fhcXX4aUcy3IXUtjsyYzDwFSiYn7Ng
         anLHlQLjpdwtVqu92oqY+H09YWY2ndLwPQI07YG/a6U7th4RpfGHOwII//mRrFwKOOs9
         zyafBmBprkLAmbY8YHjwOwePqbRXm063eEUoJ3E3jZm7xPXwZonbbIhu+i3AsnBZcMR0
         vpwA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUXim8CTltWJBZURF6vZGzCb/6q3PgEz2enKoQ2t5am8V1KxpQJ84aOHYyeLN+7tOMMsfsDVXoDZKNi@gnusha.org
X-Gm-Message-State: AOJu0YxrYvCPHQv2eOqh25+uW434M8p3zjNlSDTcN/mgBZ9aYXA2Vgqr
	LS/WC3g7SsQmMDf8QUYd25lZ6aZ5kvrqHXDZnFG7L9EUPa5BThlg
X-Google-Smtp-Source: AGHT+IFR9jdYZdDtXrxnB1GU+H9swTKivM0iklf6RXBiYwp09jeZQW0T6EdQfOoXBmowyXg7lRMfjA==
X-Received: by 2002:a05:6902:1246:b0:e54:9cb1:21a6 with SMTP id 3f1490d57ef6-e5b4618a4e5mr8354738276.11.1739146551059;
        Sun, 09 Feb 2025 16:15:51 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:abab:0:b0:e5b:3adb:a133 with SMTP id 3f1490d57ef6-e5b46087877ls574041276.1.-pod-prod-03-us;
 Sun, 09 Feb 2025 16:15:47 -0800 (PST)
X-Received: by 2002:a05:690c:9989:b0:6ef:6a71:aa55 with SMTP id 00721157ae682-6f9b2345b63mr104776317b3.0.1739146547245;
        Sun, 09 Feb 2025 16:15:47 -0800 (PST)
Received: by 2002:a05:690c:4448:b0:6f9:a930:a709 with SMTP id 00721157ae682-6f9b1de8b9ams7b3;
        Fri, 7 Feb 2025 05:02:49 -0800 (PST)
X-Received: by 2002:a05:690c:6c02:b0:6f9:938a:57a2 with SMTP id 00721157ae682-6f9b2802027mr27049957b3.1.1738933366508;
        Fri, 07 Feb 2025 05:02:46 -0800 (PST)
Date: Fri, 7 Feb 2025 05:02:46 -0800 (PST)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <53c78eb9-2050-46d5-a688-be82846135a4n@googlegroups.com>
In-Reply-To: <ff82fe21-8e02-42df-8760-c3e358a12766@murch.one>
References: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com>
 <ff82fe21-8e02-42df-8760-c3e358a12766@murch.one>
Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_53614_404128117.1738933366152"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_53614_404128117.1738933366152
Content-Type: multipart/alternative; 
	boundary="----=_Part_53615_1853040815.1738933366152"

------=_Part_53615_1853040815.1738933366152
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Darosior,

Thanks for the work on reviving the Great Consensus Cleanup.

> Now i would like to update the broader Bitcoin development community on=
=20
the outcome of this effort.
> I believe a Consensus Cleanup proposal should include the following.
> - A fix for vulnerabilities surrounding the use of timestamps in the=20
difficulty adjustment
> algorithm. In particular, a fix for the timewarp attack with a 7200=20
seconds grace period as well
> as a fix for the Murch-Zawy attack [4] by making invalid any difficulty=
=20
adjustment period with a
> negative duration.
> - A fix for long block validation times with a minimal "confiscation=20
surface", by introducing a
> per-transaction limit on the number of legacy sigops in the inputs.
> - A fix for merkle tree weaknesses by making transactions which serialize=
=20
to exactly 64 bytes
> invalid.
> - A fix for duplicate transactions to supplement BIP34 in order to avoid=
=20
resuming unnecessary BIP30
> validation in the future. This is achieved by mandating the nLockTime=20
field of coinbase
> transaction to be set to the height of their block minus 1.
>=20
> I have started drafting a BIP draft with the detailed specs for this.

So assuming some hypothetical future BIP-9-based deployment, there can be=
=20
multiple soft-forks
activation at the same time (up to 30), as a soft-fork can be assigned=20
distinct block nVersion=20
bit. While BIP-9 recommends a 95% activation threshold on mainnet, it's one=
=20
line change to
adjust the `nThreshold` variable to another value. For the fix about=20
timewarp vulnerabilities,
as it's an additional constraint on the validity of mined blocks allowed=20
the current reward
schedule, there could be some reluctance in adopting the new consensus=20
rules, and this fix
could deserve a specific threshold of its own - imho.

Additionally, the proposed soft-fork fixes are very different than the 3=20
set of rules than
have been activated under the DEPLOYMENT_TAPROOT flag. While BIP340, BIP341=
=20
and BIP342 are
building on top of each other in a modular fashion, this is not the case=20
here with the 4
proposed fixes=20
("timewarp"/"worst-block-time"/"merkle-tree-weakness"/"enhanced-duplicated-=
txn",
as adoption of one fix is not necessitated to adopt the other fixes. There=
=20
could be some
community consensus on=20
"timewarp"/"merke-tree-weakness"/"enhanced-duplicated-txn", while
the minimal "confiscation surface" (which was very controversial when the=
=20
GCC was proposed
the 1st time in 2019), not suiting a wide majority of folks, or even people=
=20
who have use-cases
potentially affected.

For those reasons, I think it's wiser to spread each fix in its own BIP and=
=20
patchset of
code changes to not only have discussions of each fix in parallel, though=
=20
also eventually
enable separate activation of each consensus fix, in the optic that each=20
fix might gather
different level of consensus, whatever the reasons.

This might be a stylistic note, though I could point in bitcoin core code=
=20
today implemented
check in the script interpreter right in the crux of consensus code paths=
=20
that is just stale
due to a never-activated BIP (-- yes I'm starring at you SIGPUSHONLY).

Best,
Antoine (the "evil" one)

OTS hash: 6c809fde007a53f380af41f0e22f3b9e95c83da24c2718ac2de0004570f94990

Le jeudi 6 f=C3=A9vrier 2025 =C3=A0 21:46:42 UTC, Murch a =C3=A9crit :

> Thank you for the update and your work on the Great Consensus Cleanup. I=
=20
> am looking forward to reading your BIP, and would hope that you could=20
> share here or in the BIP=E2=80=99s Rationale what convinced you to change=
 the=20
> grace period from 600 seconds to 7200 seconds and how the nLockTime of=20
> height-1=E2=80=AFwon out.
>
> Cheers,
> Murch
>
> On 2025-02-05 13:09, 'Antoine Poinsot' via Bitcoin Development Mailing=20
> List wrote:
> > Hi everyone,
> >=20
> > A bit over a year ago i started working on revisiting the 2019 Great=20
> Consensus Cleanup proposal from
> > Matt Corallo [0]. His proposal included:
> > - making <=3D64 bytes transactions invalid to fix merkle tree weaknesse=
s;
> > - making non-pushonly scriptSigs, FindAndDelete matches,=20
> OP_CODESEPARATOR and non-standard sighash
> > types fail script validation to mitigate the worst case block validatio=
n=20
> time;
> > - restrict the nTime field of the first block in each difficulty=20
> adjustment interval to be no less
> > than 600 seconds lower than the previous block's;
> >=20
> > I set out to research the impact of each of the vulnerabilities this=20
> intended to patch, the
> > alternative fixes possible for each and finally if there was any other=
=20
> protocol bug fix we'd want to
> > include if we went through the considerable effort of soft forking=20
> Bitcoin already.
> >=20
> > Later in March i shared some first findings on Delving [1] and=20
> advertized the effort on this mailing
> > list [2]. I also created a companion thread on Delving, kept private, t=
o=20
> discuss the details of the
> > worst case block validation time [3]. As one would expect due to the=20
> larger design space available
> > to fix this issue, this private thread is where most of the discussion=
=20
> would happen. Thank you to
> > everyone who contributed feedback, insights, ideas and argumented=20
> opinions on the different issues
> > all along the process.
> >=20
> > Now i would like to update the broader Bitcoin development community on=
=20
> the outcome of this effort.
> > I believe a Consensus Cleanup proposal should include the following.
> > - A fix for vulnerabilities surrounding the use of timestamps in the=20
> difficulty adjustment
> > algorithm. In particular, a fix for the timewarp attack with a 7200=20
> seconds grace period as well
> > as a fix for the Murch-Zawy attack [4] by making invalid any difficulty=
=20
> adjustment period with a
> > negative duration.
> > - A fix for long block validation times with a minimal "confiscation=20
> surface", by introducing a
> > per-transaction limit on the number of legacy sigops in the inputs.
> > - A fix for merkle tree weaknesses by making transactions which=20
> serialize to exactly 64 bytes
> > invalid.
> > - A fix for duplicate transactions to supplement BIP34 in order to avoi=
d=20
> resuming unnecessary BIP30
> > validation in the future. This is achieved by mandating the nLockTime=
=20
> field of coinbase
> > transaction to be set to the height of their block minus 1.
> >=20
> > I have started drafting a BIP draft with the detailed specs for this.
> >=20
> > Antoine Poinsot
> >=20
> >=20
> > [0]=20
> https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe=
661050c2/bip-XXXX.mediawiki
> > [1] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710
> > [2] https://groups.google.com/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ
> > [3] https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/71=
1
> > [4]=20
> https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062#var=
iant-on-zawys-attack-2
> >=20
>
>

--=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/=
53c78eb9-2050-46d5-a688-be82846135a4n%40googlegroups.com.

------=_Part_53615_1853040815.1738933366152
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Darosior,<br /><br />Thanks for the work on reviving the Great Consensus=
 Cleanup.<br /><br />&gt; Now i would like to update the broader Bitcoin de=
velopment community on the outcome of this effort.<br />&gt; I believe a Co=
nsensus Cleanup proposal should include the following.<br />&gt; - A fix fo=
r vulnerabilities surrounding the use of timestamps in the difficulty adjus=
tment<br />&gt; algorithm. In particular, a fix for the timewarp attack wit=
h a 7200 seconds grace period as well<br />&gt; as a fix for the Murch-Zawy=
 attack [4] by making invalid any difficulty adjustment period with a<br />=
&gt; negative duration.<br />&gt; - A fix for long block validation times w=
ith a minimal "confiscation surface", by introducing a<br />&gt; per-transa=
ction limit on the number of legacy sigops in the inputs.<br />&gt; - A fix=
 for merkle tree weaknesses by making transactions which serialize to exact=
ly 64 bytes<br />&gt; invalid.<br />&gt; - A fix for duplicate transactions=
 to supplement BIP34 in order to avoid resuming unnecessary BIP30<br />&gt;=
 validation in the future. This is achieved by mandating the nLockTime fiel=
d of coinbase<br />&gt; transaction to be set to the height of their block =
minus 1.<br />&gt; <br />&gt; I have started drafting a BIP draft with the =
detailed specs for this.<br /><br />So assuming some hypothetical future BI=
P-9-based deployment, there can be multiple soft-forks<br />activation at t=
he same time (up to 30), as a soft-fork can be assigned distinct block nVer=
sion <br />bit. While BIP-9 recommends a 95% activation threshold on mainne=
t, it's one line change to<br />adjust the `nThreshold` variable to another=
 value. For the fix about timewarp vulnerabilities,<br />as it's an additio=
nal constraint on the validity of mined blocks allowed the current reward<b=
r />schedule, there could be some reluctance in adopting the new consensus =
rules, and this fix<br />could deserve a specific threshold of its own - im=
ho.<br /><br />Additionally, the proposed soft-fork fixes are very differen=
t than the 3 set of rules than<br />have been activated under the DEPLOYMEN=
T_TAPROOT flag. While BIP340, BIP341 and BIP342 are<br />building on top of=
 each other in a modular fashion, this is not the case here with the 4<br /=
>proposed fixes ("timewarp"/"worst-block-time"/"merkle-tree-weakness"/"enha=
nced-duplicated-txn",<br />as adoption of one fix is not necessitated to ad=
opt the other fixes. There could be some<br />community consensus on "timew=
arp"/"merke-tree-weakness"/"enhanced-duplicated-txn", while<br />the minima=
l "confiscation surface" (which was very controversial when the GCC was pro=
posed<br />the 1st time in 2019), not suiting a wide majority of folks, or =
even people who have use-cases<br />potentially affected.<br /><br />For th=
ose reasons, I think it's wiser to spread each fix in its own BIP and patch=
set of<br />code changes to not only have discussions of each fix in parall=
el, though also eventually<br />enable separate activation of each consensu=
s fix, in the optic that each fix might gather<br />different level of cons=
ensus, whatever the reasons.<br /><br />This might be a stylistic note, tho=
ugh I could point in bitcoin core code today implemented<br />check in the =
script interpreter right in the crux of consensus code paths that is just s=
tale<br />due to a never-activated BIP (-- yes I'm starring at you SIGPUSHO=
NLY).<br /><br />Best,<br />Antoine (the "evil" one)<br /><br />OTS hash: 6=
c809fde007a53f380af41f0e22f3b9e95c83da24c2718ac2de0004570f94990<br /><br />=
<div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le jeudi =
6 f=C3=A9vrier 2025 =C3=A0 21:46:42 UTC, Murch a =C3=A9crit=C2=A0:<br/></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Thank you for the upd=
ate and your work on the Great Consensus Cleanup. I=20
<br>am looking forward to reading your BIP, and would hope that you could=
=20
<br>share here or in the BIP=E2=80=99s Rationale what convinced you to chan=
ge the=20
<br>grace period from 600 seconds to 7200 seconds and how the nLockTime of=
=20
<br>height-1=E2=80=AFwon out.
<br>
<br>Cheers,
<br>Murch
<br>
<br>On 2025-02-05 13:09, &#39;Antoine Poinsot&#39; via Bitcoin Development =
Mailing=20
<br>List wrote:
<br>&gt; Hi everyone,
<br>&gt;=20
<br>&gt; A bit over a year ago i started working on revisiting the 2019 Gre=
at Consensus Cleanup proposal from
<br>&gt; Matt Corallo [0]. His proposal included:
<br>&gt; - making &lt;=3D64 bytes transactions invalid to fix merkle tree w=
eaknesses;
<br>&gt; - making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESE=
PARATOR and non-standard sighash
<br>&gt;    types fail script validation to mitigate the worst case block v=
alidation time;
<br>&gt; - restrict the nTime field of the first block in each difficulty a=
djustment interval to be no less
<br>&gt;    than 600 seconds lower than the previous block&#39;s;
<br>&gt;=20
<br>&gt; I set out to research the impact of each of the vulnerabilities th=
is intended to patch, the
<br>&gt; alternative fixes possible for each and finally if there was any o=
ther protocol bug fix we&#39;d want to
<br>&gt; include if we went through the considerable effort of soft forking=
 Bitcoin already.
<br>&gt;=20
<br>&gt; Later in March i shared some first findings on Delving [1] and adv=
ertized the effort on this mailing
<br>&gt; list [2]. I also created a companion thread on Delving, kept priva=
te, to discuss the details of the
<br>&gt; worst case block validation time [3]. As one would expect due to t=
he larger design space available
<br>&gt; to fix this issue, this private thread is where most of the discus=
sion would happen. Thank you to
<br>&gt; everyone who contributed feedback, insights, ideas and argumented =
opinions on the different issues
<br>&gt; all along the process.
<br>&gt;=20
<br>&gt; Now i would like to update the broader Bitcoin development communi=
ty on the outcome of this effort.
<br>&gt; I believe a Consensus Cleanup proposal should include the followin=
g.
<br>&gt; - A fix for vulnerabilities surrounding the use of timestamps in t=
he difficulty adjustment
<br>&gt;    algorithm.  In particular, a fix for the timewarp attack with a=
 7200 seconds grace period as well
<br>&gt;    as a fix for the Murch-Zawy attack [4] by making invalid any di=
fficulty adjustment period with a
<br>&gt;    negative duration.
<br>&gt; - A fix for long block validation times with a minimal &quot;confi=
scation surface&quot;, by introducing a
<br>&gt;    per-transaction limit on the number of legacy sigops in the inp=
uts.
<br>&gt; - A fix for merkle tree weaknesses by making transactions which se=
rialize to exactly 64 bytes
<br>&gt;    invalid.
<br>&gt; - A fix for duplicate transactions to supplement BIP34 in order to=
 avoid resuming unnecessary BIP30
<br>&gt;    validation in the future. This is achieved by mandating the nLo=
ckTime field of coinbase
<br>&gt;    transaction to be set to the height of their block minus 1.
<br>&gt;=20
<br>&gt; I have started drafting a BIP draft with the detailed specs for th=
is.
<br>&gt;=20
<br>&gt; Antoine Poinsot
<br>&gt;=20
<br>&gt;=20
<br>&gt; [0] <a href=3D"https://github.com/TheBlueMatt/bips/blob/7f9670b643=
b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki" target=3D"_blank" rel=3D=
"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=
=3Dhttps://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eab=
e661050c2/bip-XXXX.mediawiki&amp;source=3Dgmail&amp;ust=3D1739019749032000&=
amp;usg=3DAOvVaw1htn5EyxYdVM97ybzZmb61">https://github.com/TheBlueMatt/bips=
/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki</a>
<br>&gt; [1] <a href=3D"https://delvingbitcoin.org/t/great-consensus-cleanu=
p-revival/710" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"h=
ttps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://delvingbitcoin.org/t/grea=
t-consensus-cleanup-revival/710&amp;source=3Dgmail&amp;ust=3D17390197490320=
00&amp;usg=3DAOvVaw1GRs4gEnpLL9cDpZwU4qzP">https://delvingbitcoin.org/t/gre=
at-consensus-cleanup-revival/710</a>
<br>&gt; [2] <a href=3D"https://groups.google.com/g/bitcoindev/c/CAfm7D5ppj=
o/m/bYJ3BiOuAAAJ" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.com/g/=
bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ&amp;source=3Dgmail&amp;ust=3D173901=
9749032000&amp;usg=3DAOvVaw0p6kXWtCxH-hFs8VOjCnao">https://groups.google.co=
m/g/bitcoindev/c/CAfm7D5ppjo/m/bYJ3BiOuAAAJ</a>
<br>&gt; [3] <a href=3D"https://delvingbitcoin.org/t/worst-block-validation=
-time-inquiry/711" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://delvingbitcoin.org/t=
/worst-block-validation-time-inquiry/711&amp;source=3Dgmail&amp;ust=3D17390=
19749032000&amp;usg=3DAOvVaw0JpBb4DEgl1TbouNjzazLy">https://delvingbitcoin.=
org/t/worst-block-validation-time-inquiry/711</a>
<br>&gt; [4] <a href=3D"https://delvingbitcoin.org/t/zawy-s-alternating-tim=
estamp-attack/1062#variant-on-zawys-attack-2" target=3D"_blank" rel=3D"nofo=
llow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dht=
tps://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062%23varia=
nt-on-zawys-attack-2&amp;source=3Dgmail&amp;ust=3D1739019749032000&amp;usg=
=3DAOvVaw36Ds3e7_r7TwqZdqgavKhM">https://delvingbitcoin.org/t/zawy-s-altern=
ating-timestamp-attack/1062#variant-on-zawys-attack-2</a>
<br>&gt;=20
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/53c78eb9-2050-46d5-a688-be82846135a4n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/53c78eb9-2050-46d5-a688-be82846135a4n%40googlegroups.com</a>.<br />

------=_Part_53615_1853040815.1738933366152--

------=_Part_53614_404128117.1738933366152--