From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 23 Feb 2025 15:53:18 -0800 Received: from mail-ot1-f63.google.com ([209.85.210.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tmLmf-0008JA-7W for bitcoindev@gnusha.org; Sun, 23 Feb 2025 15:53:18 -0800 Received: by mail-ot1-f63.google.com with SMTP id 46e09a7af769-72723b7151csf1140357a34.2 for ; Sun, 23 Feb 2025 15:53:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1740354790; cv=pass; d=google.com; s=arc-20240605; b=MbS/vJLkRgDkgEtNNqheB1BbFZpbWa1WWJlf7HGIVDtfEyW3fpi7xQxd8Tp1Me8dR6 AJsmOLUzLpOygtolVfkwkVG8s/XSVxEtUftb+Yzl8vOwTUFoEU+dm7EIcjrxa3reVibq TWrE7NA+2a2Hbp92enWHGEaz6SSJeSMLqKF4LyenQ+SzjVjeke4Vz+yaiVnZ3IFVol5n gJtmYK98tZ6hHOtqSC3Po/nba/7Ktn0zdO8MLbDDHYVT8UyXGVrXcklmrA9+JmmcLUl8 NSTRq4iHlHfJfRYdTBkgyKglxKm4b9z4Ez5wdOoOO2663WjemLz86mxZ0e4t5+ZxzqJ/ Sq2w== 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:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=uvPSEJc2mQLHQ3aicQOmQgvpF0IEH+AZN3fEj+wCF+s=; fh=W47VPq2a172a+gHBZaTZm8NppdTY3jBXcgO739ED4uk=; b=dZVqtXUWySTeG2x7jUTlATM9gJ5wSHfTNEBYD0Yc0RdLysKv/4cHZWnJhy5tWUxa+m sxn2dae3alZEVAOuZuJ7TXNJasPaALncNRnOrZ3unDxM/+Kz+rttyZWkDwJKo8p7ojK1 PbP25ZZYm/31X0mvDfwi8Hicsx/qso6XCb9Ydqy4yrdLNkEk18DJxSzZKExar19QJfuF 4XC//ao9uEOgrFZdwCrIT8wU6BHYeNPbokJrak945lbE+cnkC0itaTkgZGIH6Qi44OEw wAtLg+xpRt2WveSBf5VN0RbeauNLKmEhtYHEXhva87Xws6/U0n9rJFb/oczZYg21sml2 KL1w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UI4Sz9HB; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.131 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=1740354790; x=1740959590; 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: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=uvPSEJc2mQLHQ3aicQOmQgvpF0IEH+AZN3fEj+wCF+s=; b=crETjZDer5tv+wCenOQYDs7Pyzqexcw9sEQTbU/0XcNh9netz4fw77Ef/vSi/zrwX9 03eLIznnfYZ4XKvOBQS4Js+tRSJOGSjf9wJimjI1fMexZWn5BG7dMTs0NxWhdQm7wdyl 02pkcOxZ9U0GbftI0TTzojTSKw/sSEh4LbXh5qJuX6wWrE5fzkiKwr87SDeigtc1CCau AfnoOKPEQ90IDE2Q2b8sXo3pZkgF9C9DLWbZXo4rPKY7K9GhVUNlSViXeqTPd/Zy3FPr P++UX3fVIqjgagqf4IyUR4ScmIgXSlRn4hyzjOt0LrpdBi6gDx+l8CVHGpMhfOvYHQAn 5DZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740354790; x=1740959590; 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: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=uvPSEJc2mQLHQ3aicQOmQgvpF0IEH+AZN3fEj+wCF+s=; b=DvaDoAw/DK5HKf4nZUksXefZHQoq1u0ANYiyfTB89y+46PfcwEdo9iD8n39wipDizc 3xaGt25GCntnwoPYnvdDpgZU0zmOVS8oo5YSmQujCWKwvnwuw7sEPHjLCJPjUOrUx0hY 3R0KCLUPICEEWEV+dLQPwZdt6MMUGGwLfOz00nGKSTsZzE7R/9CCEiUzPtKaFbDjfG+g eI+Fj51wPRNPNQgnXGPjnbzfPC9rJjJeqea9KcI0za8ImwsrVbgWaGn/j/sPkW6n/Zol eaIv4Ya8RUCI6h4mgFW/AdzoOsOlIRfSWNK/rZJ8GG39aHBw4khBh/+izO7APjGRjrP1 EyJQ== X-Forwarded-Encrypted: i=2; AJvYcCVUzrLBytM5uFDdWnz8Hw2i3MLt3XS+FdMltCcFrm8LhUCMMlYKSyT4kol7S/wUegmNRmWKAj1/jDl0@gnusha.org X-Gm-Message-State: AOJu0YxIH6EOXf2yIMDcoTsIvDngZRY+tuiDE/ZQ/2yPChm/foX8sBZ3 Bf/NlY0Jm9J8OHPgDIRJvicWgeO3bzRUiY+ANzlHouUTgUqEo6Rl X-Google-Smtp-Source: AGHT+IGfu/6CAsniAPhJSgPhDOnJ69HE1Y1PXzmKHxXWqHZAW7tMDhzjjwUsB/SsX7gf09OGcsRffw== X-Received: by 2002:a05:6870:fbac:b0:29e:5cb1:b148 with SMTP id 586e51a60fabf-2bd51500124mr9374401fac.6.1740354790131; Sun, 23 Feb 2025 15:53:10 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVEbXp01S+xMEtmrYXttWfTyYERlMshGePCgrb5T0nM1jQ== Received: by 2002:a05:6870:a90e:b0:2b8:f3e5:a817 with SMTP id 586e51a60fabf-2bd50bf1d9bls1059548fac.2.-pod-prod-02-us; Sun, 23 Feb 2025 15:53:07 -0800 (PST) X-Received: by 2002:a05:6808:80af:b0:3f4:756:52cf with SMTP id 5614622812f47-3f425a7e5ffmr8918473b6e.10.1740354786913; Sun, 23 Feb 2025 15:53:06 -0800 (PST) Received: by 2002:a05:600c:3c9c:b0:439:a596:e64 with SMTP id 5b1f17b1804b1-439ae26b649ms5e9; Sun, 23 Feb 2025 14:36:05 -0800 (PST) X-Received: by 2002:a05:600c:6b66:b0:439:96a4:d2a8 with SMTP id 5b1f17b1804b1-439a2fb2c41mr110368815e9.5.1740350163563; Sun, 23 Feb 2025 14:36:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1740350163; cv=none; d=google.com; s=arc-20240605; b=M8novVcXa4tX/13fBX8BeuzymGTEHhBdMR7JyjuHFiqnImZlV+cj6qUR8yDzDD2sJS LfgeN30UYEdAoKmyubM0uD5uyzDH3DfJsNxs8NbwpY53S+ToX3d5AS9SpSVg7HHE4Cwz 742N6ZZQZSso7kwxXYfmstPhh2+sSWD6SboCWlL0XMlqnmWfB9sdv0MrtVeaJ/kbX1by w+x+GxTeHxaK0QvHdSTafWxJAygVGJiMDSWsVVrWEz1kFbl/GUCzXDiySsWzM0Ffni1h 5AAqugMY567VbnbSk5UhvPYVUDiOGiAdqjVOV2pLzv8pw6z93IdKDFnwcorqzuWv8QSH e3tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=iQzYaODkGrcUQAj/H6lk9rdwT5JKtir1B40QEzQ7mQU=; fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=; b=bzJZhUlK0cZKcb2zOqv9qnfjybz9dZeD2tWAwe6SEIN8YxGyjiASsfTfB+urvX+IWc SPfI+TJk+RbgpnSOc3E7bRno9CKjnGoZo3i/yOfQLsejYKXODMKkX0UpR0J8kVEZMvO8 mfz34sceML0EaRPmqyOb0jDRFjWmoILpKrYmGhr9Vmfr1CHg5v3qm/vCq4t16X8X6wvM BHntgW77dpeGnG6r6uiKQatMzd02ddzaiPF5zdNAN/MrAR7Z4lhVXN2Undn405tXs+Gp GMqmhyynKdawrAwd3TToYN63r+mhFd4z8a1thhjCwnqePIdBIuJ+93gt3VZQOhZ6/Uyh bJhw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=UI4Sz9HB; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.131 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch. [185.70.40.131]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4399bea9edesi8269645e9.0.2025.02.23.14.36.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Feb 2025 14:36:03 -0800 (PST) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.40.131 as permitted sender) client-ip=185.70.40.131; Date: Sun, 23 Feb 2025 22:35:59 +0000 To: Matt Corallo From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival Message-ID: In-Reply-To: <25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com> References: <25482CCA-1F9D-4971-914F-674DF15C3414@mattcorallo.com> Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 52246b72b46a52236668a264b6b46f5bcb597d96 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_YwUdvv4IHL6z7x5zyDJd4pP51qxIeu07qSbwExzNs" 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=UI4Sz9HB; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.40.131 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 (-) --b1=_YwUdvv4IHL6z7x5zyDJd4pP51qxIeu07qSbwExzNs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > A 40x decrease to a validation time of 30 seconds probably is worth a bit= of risk for a further improvement. Depends on what hardware. I don't think a worst case of 30 seconds for end = users is worth more risks. A worst case of 30 seconds for miners would prob= ably be concerning. In addition, although the worst case is important to limit the damage an at= tacker can do without being economically rational, what we care about for m= iners attacking each other is economically viable attacks. At the moment th= e optimal "validation time / cost to attacker" ratio is not the worst case,= by a large margin [0]. I believe we should take into account the worst case to miners even if not = economically viable for an attacker as a safety margin. But we should keep = in mind this is already overestimating the attack risk since in this scenar= io what we should look at is the worst case validation time of blocks that = may have positive returns to an attacker. > Can you put numbers to this? Sure. Using my functional test which runs the worst case today and the wors= t case under various mitigations [1] on a Dell XPS 15 9520 laptop (the mode= l with an i5-12500H) i get 120 seconds for the worst case today and 10 seco= nds for the worst block with a limited of 2500 (potentially) executed sigop= s per transaction. To (maybe, they could be running more powerful machines = than my laptop) impose such a validation time to other miners an attacker w= ould have to invest 89 (!!) preparation blocks. Sure, with low fees the opp= ortunity cost of mining preparation transactions is not as high as it could= be. But still. [0] [https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/7= 0](https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/70?= u=3Dantoinep) [1] [https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/6= 1](https://delvingbitcoin.org/t/worst-block-validation-time-inquiry/711/61?= u=3Dantoinep) On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo wrote: > In the delving post you said =E2=80=9CThis provides a 40x decrease in the= worst case validation time with a straightforward and flexible rule minimi= zing the confiscatory surface. A further 7x decrease is possible by combini= ng it with another rule, which is in my opinion not worth the additional co= nfiscatory surface.=E2=80=9D > > Can you put numbers to this? How long does it take to validate a full blo= ck with this 40x decrease and how long would it take with the further 7x de= crease? > > A 40x decrease to a validation time of 30 seconds probably is worth a bit= of risk for a further improvement. A 40x decrease to 1 second is obviously= fine :). > >> On Feb 5, 2025, at 19:57, 'Antoine Poinsot' via Bitcoin Development Mail= ing List wrote: > >> =EF=BB=BFHi everyone, >> >> A bit over a year ago i started working on revisiting the 2019 Great Con= sensus Cleanup proposal from >> Matt Corallo [0]. His proposal included: >> - making <=3D64 bytes transactions invalid to fix merkle tree weaknesses= ; >> - making non-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARATO= R and non-standard sighash >> types fail script validation to mitigate the worst case block validation= time; >> - restrict the nTime field of the first block in each difficulty adjustm= ent interval to be no less >> than 600 seconds lower than the previous block's; >> >> I set out to research the impact of each of the vulnerabilities this int= ended to patch, the >> alternative fixes possible for each and finally if there was any other p= rotocol bug fix we'd want to >> include if we went through the considerable effort of soft forking Bitco= in already. >> >> Later in March i shared some first findings on Delving [1] and advertize= d the effort on this mailing >> list [2]. I also created a companion thread on Delving, kept private, to= discuss the details of the >> worst case block validation time [3]. As one would expect due to the lar= ger design space available >> to fix this issue, this private thread is where most of the discussion w= ould happen. Thank you to >> everyone who contributed feedback, insights, ideas and argumented opinio= ns on the different issues >> all along the process. >> >> Now i would like to update the broader Bitcoin development community on = 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 dif= ficulty adjustment >> algorithm. In particular, a fix for the timewarp attack with a 7200 seco= nds grace period as well >> as a fix for the Murch-Zawy attack [4] by making invalid any difficulty = adjustment period with a >> negative duration. >> - A fix for long block validation times with a minimal "confiscation sur= face", 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 serializ= e to exactly 64 bytes >> invalid. >> - A fix for duplicate transactions to supplement BIP34 in order to avoid= resuming unnecessary BIP30 >> validation in the future. This is achieved by mandating the nLockTime fi= eld of coinbase >> transaction to be set to the height of their block minus 1. >> >> I have started drafting a BIP draft with the detailed specs for this. >> >> Antoine Poinsot >> >> [0] https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d= 3eabe661050c2/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/711 >> [4] https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/106= 2#variant-on-zawys-attack-2 >> >> -- >> You received this message because you are subscribed to the Google Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0= B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%40protonmail.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/= VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYb= Wns5nP4TANCWvPJYu1ew_yxQSaudizzk%3D%40protonmail.com. --b1=_YwUdvv4IHL6z7x5zyDJd4pP51qxIeu07qSbwExzNs Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A 40x decrease to a validation time of 30 seconds pr= obably is worth a bit of risk for a further improvement.
<= /div>
=20
=20
=20

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Depends on w= hat hardware. I don't think a worst case of 30 seconds for end users is wor= th more risks. A worst case of 30 seconds for miners would probably be conc= erning.
In addition, although the worst case is important to limit the damage an a= ttacker can do without being economically rational, what we care about for = miners attacking each other is economically viable attacks. At the moment t= he optimal "validation time / cost to attacker" ratio is not the worst case= , by a large margin [0].

I believe we should take into account the worst case to m= iners even if not economically viable for an attacker as a safety margin. B= ut we should keep in mind this is already overestimating the attack risk si= nce in this scenario what we should look at is the worst case validation ti= me of blocks that may have positive returns to an attacker.

Can yo= u put numbers to this?

<= div style=3D"">Sure. Using my functional test which runs the worst case tod= ay and the worst case under various mitigations [1] on a Dell XPS 15 = 9520 laptop (the model with an i5-12500H) i get 120 seconds for the = worst case today and 10 seconds for the worst block with a limited of 2500 = (potentially) executed sigops per transaction. To (maybe, they could be run= ning more powerful machines than my laptop) impose such a validation time t= o other miners an attacker would have to invest 89 (!!) preparation blocks.= Sure, with low fees the opportunity cost of mining preparation transaction= s is not as high as it could be. But still.

On Thursday, February 20th, 2025 at 8:22 PM, Matt Corallo <lf-li= sts@mattcorallo.com> wrote:
In the= delving post you said =E2=80=9CThis= provides a 40x decrease in the worst case validation time with a straightf= orward and flexible rule minimizing the confiscatory surface. A further 7x = decrease is possible by combining it with another rule, which is in my opin= ion not worth the additional confiscatory surface.=E2=80=9D

Can you put numbers to t= his? How long does it take to validate a full block with this 40x decrease = and how long would it take with the further 7x decrease?

A 40x decrease to a validat= ion time of 30 seconds probably is worth a bit of risk for a further improv= ement. A 40x decrease to 1 second is obviously fine :).
<= div dir=3D"ltr">
On Feb= 5, 2025, at 19:57, 'Antoine Poinsot' via Bitcoin Development Mailing List = <bitcoindev@googlegroups.com> wrote:

=EF=BB=BFHi everyone,
=
A bit over a year ago i started working on revisitin= g the 2019 Great Consensus Cleanup proposal from
Matt Coral= lo [0]. His proposal included:
- making <=3D64 bytes tra= nsactions invalid to fix merkle tree weaknesses;
- making n= on-pushonly scriptSigs, FindAndDelete matches, OP_CODESEPARATOR and non-sta= ndard sighash
 types fail script validation to mitiga= te the worst case block validation time;
- restrict the nTi= me field of the first block in each difficulty adjustment interval to be no= less
 than 600 seconds lower than the previous block= 's;

I set out to research the impact of ea= ch of the vulnerabilities this intended to patch, the
alter= native fixes possible for each and finally if there was any other protocol = bug fix we'd want to
include if we went through the conside= rable effort of soft forking Bitcoin already.

Later in March i shared some first findings on Delving [1] and advertiz= ed the effort on this mailing
list [2]. I also created a co= mpanion thread on Delving, kept private, to discuss the details of the
worst case block validation time [3]. As one would expect due t= o the larger design space available
to fix this issue, this= private thread is where most of the discussion would happen. Thank you to<= /span>
everyone who contributed feedback, insights, ideas and argu= mented opinions on the different issues
all along the proce= ss.

Now i would like to update the broader= Bitcoin development community on 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 difficulty adjustment
 algorithm.  In par= ticular, a fix for the timewarp attack with a 7200 seconds grace period as = well
 as a fix for the Murch-Zawy attack [4] by makin= g invalid any difficulty adjustment period with a
 ne= gative duration.
- A fix for long block validation times wi= th a minimal "confiscation surface", by introducing a
&nbs= p;per-transaction limit on the number of legacy sigops in the inputs.
- A fix for merkle tree weaknesses by making transactions which = serialize to exactly 64 bytes
 invalid.
- A fix for duplicate transactions to supplement BIP34 in order to avoid= resuming unnecessary BIP30
 validation in the future= . This is achieved by mandating the nLockTime field of coinbase
<= span>  transaction to be set to the height of their block minus 1.

I have started drafting a BIP draft with the = detailed specs for this.

Antoine Poinsot


[0] https://github.com/The= BlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediaw= iki
[1] https://delvingbitcoin.org/t/great-consensus-cleanu= p-revival/710
[2] https://groups.google.com/g/bitcoindev/c/= CAfm7D5ppjo/m/bYJ3BiOuAAAJ
[3] https://delvingbitcoin.org/t= /worst-block-validation-time-inquiry/711
[4] https://delvin= gbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062#variant-on-zawys-at= tack-2

--
You received th= is message because you are subscribed to the Google Groups "Bitcoin Develop= ment Mailing List" group.
To unsubscribe from this group an= d stop receiving emails from it, send an email to bitcoindev+unsubscribe@go= oglegroups.com.
To view this discussion visit https://group= s.google.com/d/msgid/bitcoindev/jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJ= svK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI%3D%40proto= nmail.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/= VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYb= Wns5nP4TANCWvPJYu1ew_yxQSaudizzk%3D%40protonmail.com.
--b1=_YwUdvv4IHL6z7x5zyDJd4pP51qxIeu07qSbwExzNs--