Delivery-date: Thu, 30 May 2024 15:00:33 -0700
Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.134 as permitted sender) client-ip=185.70.40.134;
Date: Tue, 28 May 2024 23:41:28 +0000
To: Fabian <fjahr@protonmail.com>
From: "'Fabian' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] BIP for Testnet 4
Message-ID: <cUk3mhYDInTKWp31VeaGZa68jCM6rhCiNFoQwD5JDeoi4MlxebiVUo06Oiuoj-xbKAkxyO7LpoFeZrj3Ak5cOeJRGDG83ITDdSXrZ3PQta0=@protonmail.com>
In-Reply-To: <a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg=@protonmail.com>
References: <a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg=@protonmail.com>
Feedback-ID: 5067558:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_AFA1mBiJg99tjq1ZllN2SCv1urIHb7P7MdQ95E60pM"
Reply-To: Fabian <fjahr@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

This is a multi-part message in MIME format.

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

Please note that the Block Storm Fix section was already amended with a (mu=
ch needed) clarification:

=3D=3D=3D Block Storm Fix =3D=3D=3D

When the next work required is calculated for the first block in a new diff=
iculty period, the difficulty of the last block of the previous difficulty =
period is only used as the base for this calculation if its difficulty is n=
ot 1. If its difficulty is 1, all blocks in the previous difficulty period =
are checked in reverse order if any of them have a different difficulty tha=
n 1. When a different difficulty is encountered, it is assumed to be the ac=
tual difficulty of the network and used as the base for the calculation of =
the new difficulty level. Note that the first block in new difficulty perio=
d does not allow usage of the 20-min rule (this is prior behavior). This me=
ans that in each difficulty period the first block should always have the a=
ctual difficulty even if all other blocks were mined with the 20-min rule.
For the avoidance of doubt, no matter which block in the previous difficult=
y period provides the actual difficulty used as the basis for the calculati=
on, the timestamp of the last block is always the one that is used as the e=
nd time of the difficulty period.
On Wednesday, May 29th, 2024 at 12:01 AM, 'Fabian' via Bitcoin Development =
Mailing List <bitcoindev@googlegroups.com> wrote:

> Hello list,
>
> a potential reset or replacement of Testnet 3 has been discussed on this =
list previously here: https://groups.google.com/g/bitcoindev/c/9bL00vRj7OU/=
m/9yCPo3uUBwAJ
>
> The discussion continued in the accompanying bitcoin core pull request (h=
ttps://github.com/bitcoin/bitcoin/pull/29775) which has been tested in the =
past couple of weeks and adopted by several projects on an experimental bas=
is, such as https://mempool.space/testnet4 for example.
>
> I have now formalized the current rules and genesis block implemented in =
the PR as BIP draft: https://github.com/bitcoin/bips/pull/1601
>
> -----------
>
> =3D=3D Abstract =3D=3D
>
> A new test network with the goal to replace Testnet 3. This network comes=
 with small but important improvements of the consensus rules, that should =
make it impractical to attack the network using only CPU mining.
>
> =3D=3D Motivation =3D=3D
>
> Quoting the original mailing list post from Jameson Lopp:
>
> "Testnet3 has been running for 13 years. It's on block 2.5 million someth=
ing and the block reward is down to ~0.014 TBTC, so mining is not doing a g=
reat job at distributing testnet coins anymore.
>
> The reason the block height is insanely high is due to a rather amusing e=
dge case bug that causes the difficulty to regularly get reset to 1, which =
causes a bit of havoc. If you want a deep dive into the quirk: https://blog=
.lopp.net/the-block-storms-of-bitcoins-testnet/
>
> Testnet3 is being actively used for scammy airdrops; those of us who tend=
 to be generous with our testnet coins are getting hounded by non-developer=
s chasing cheap gains.
>
> As a result, TBTC is being actively bought and sold; one could argue that=
 the fundamental principle of testnet coins having no value has been broken=
."
>
> Since then the issue with block storms has been further demonstrated on T=
estnet 3 when three years' worth of blocks were mined in a few weeks while =
rendering the network practically unusable at the same time.
>
> =3D=3D Specification =3D=3D
>
> Consensus of Testnet 4 follows the same rules as Testnet 3 with the excep=
tion of the two new rules detailed below.
>
> This means that the existing 20 min difficulty exception in Testnet 3 is =
explicitly kept in place, meaning that a block with a timestamp 20 minutes =
further into the future from the current time is allowed to have a minimum =
difficulty of 1 instead of whatever the actual level currently is.
>
> =3D=3D=3D Block Storm Fix =3D=3D=3D
>
> When the next work required is calculated for the first block in a new di=
fficulty period, the difficulty of the last block of the previous difficult=
y period is only used as the base for this calculation if its difficulty is=
 not 1. If its difficulty is 1, all blocks in the previous difficulty perio=
d are checked in reverse order if any of them have a different difficulty t=
han 1. When a different difficulty is encountered, it is assumed to be the =
actual difficulty of the network and used as the base for the calculation o=
f the new difficulty level. Only if all blocks from the previous difficulty=
 period have had a difficulty of 1 (possibly by the use of the 20-min rule)=
, this is also used as the base for the calculation of the next difficulty =
period.
>
> For the avoidance of doubt, no matter which block in the previous difficu=
lty period provides the actual difficulty used as the basis for the calcula=
tion, the timestamp of the last block is always the one that is used as the=
 end time of the difficulty period.
>
> =3D=3D=3D Time Warp Fix =3D=3D=3D
>
> To protect against the time warp attack, the following rule proposed as p=
art of The Great Consensus Cleanup is enforced: "The nTime field of each bl=
ock whose height, mod 2016, is 0 must be greater than or equal to the nTime=
 field of the immediately prior block minus 600. For the avoidance of doubt=
, such blocks must still comply with existing Median-Time-Past nTime restri=
ctions."
>
> =3D=3D Rationale =3D=3D
>
> The applied changes were the result of discussions on the mailing list an=
d the PR. The selected changes try to strike a balance between minimal chan=
ges to the network (keeping it as close to mainnet as possible) while makin=
g it more robust against attackers that try to disrupt the network. Several=
 alternative designs were considered:
>
> * For the block storm fix an alternative fix could have been to prevent t=
he last block in a difficulty period from applying the existing difficulty =
exception. Both solutions were deemed acceptable and there was no clear pre=
ference among reviewers.
> * Removal of the 20-min difficulty exception was discussed but dismissed =
since several reviewers insisted that it was a useful feature allowing non-=
standard transactions to be mined with just a CPU.
> * Increase of minimum difficulty was discussed but dismissed as it would =
categorically prevent participation in the network using a CPU miner.
> * Increase of the delay in the 20 min difficulty exception was suggested =
but did not receive significant support.
> * Re-enabling <code>acceptnonstdtxn</code> in bitcoin core by default was=
 dismissed as it had led to confusion among layer-2s that had used testnet =
for transaction propagation tests and expected it to behave similar to main=
net.
> * Motivating miners to re-org min difficulty blocks was suggested but thi=
s may still be done after Testnet 4 is deployed, so it can be considered ou=
t of scope for this BIP.
> * Persisting the real difficulty in the version field was suggested to pr=
event exploits of the 20-min rule in an even more robust way, but did not r=
eceive a critical level of support since it would be a more invasive change=
.
>
> =3D=3D Network Parameters =3D=3D
>
> =3D=3D=3D Consensus Rules =3D=3D=3D
>
> All consensus rules active on mainnet at the time of this proposal are en=
forced from block 1, the newest of these rules being the Taproot softfork.
>
> =3D=3D=3D Genesis Block =3D=3D=3D
>
> * Message: <code>03/May/2024 000000000000000000001ebd58c244970b3aa9d783bb=
001011fbe8ea8e98e00e</code>
> * Pubkey: <code>000000000000000000000000000000000000000000000000000000000=
000000000</code>
> * Time stamp: 1714777860
> * Nonce: 393743547
> * Difficulty: <code>0x1d00ffff</code>
> * Version: 1
>
> The resulting genesis block hash is <code>00000000da84f2bafbbc53dee25a72a=
e507ff4914b867c565be350b0da8bf043</code>, and the block hex is <code>010000=
00010000000000000000000000000000000000000000000000000000000000000000fffffff=
f5504ffff001d01044c4c30332f4d61792f3230323420303030303030303030303030303030=
303030303031656264353863323434393730623361613964373833626230303130313166626=
53865613865393865303065ffffffff0100f2052a0100000023210000000000000000000000=
00000000000000000000000000000000000000000000ac00000000</code>.
>
> =3D=3D=3D Message Start =3D=3D=3D
>
> The message start is defined as <code>0x1c163f28</code>. These four bytes=
 were randomly generated and have no special meaning.
>
> =3D=3D Compatibility =3D=3D
>
> This specification is backward compatible in the sense that existing soft=
ware can use Testnet 4 out of the box, assuming support for Testnet 3 alrea=
dy exists.
>
> Simply by adding the network parameters for Testnet 4 (magic number, etc.=
), a client can connect to and use Testnet 4 without further modifications.=
 The block headers have valid proof of work, so clients can trivially check=
 that blocks are "probably" valid.
>
> However, without the implementation of the changes detailed in Specificat=
ions, a client could follow a chain that does not follow the rules. Any ful=
ly validating node should check these rules and reject blocks that fail to =
follow them. Clients should either validate these rules or connect to trust=
ed peers that do full validation.
>
> =3D=3D Reference implementation =3D=3D
>
> Pull request at https://github.com/bitcoin/bitcoin/pull/29775
>
> =3D=3D References =3D=3D
>
> # Original mailing list thread: https://groups.google.com/g/bitcoindev/c/=
9bL00vRj7OU/m/kFPaQCzmBwAJ
> # Blog post on block storm bug: https://blog.lopp.net/the-block-storms-of=
-bitcoins-testnet/
> # Consensus Cleanup BIP draft: https://github.com/TheBlueMatt/bips/blob/c=
leanup-softfork/bip-XXXX.mediawiki
> # Consensus Cleanup PR draft: https://github.com/bitcoin/bitcoin/pull/154=
82
>
> =3D=3D Copyright =3D=3D
>
> This document is licensed under the Creative Commons CC0 1.0 Universal li=
cense.
>
> --
> 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 on the web visit https://groups.google.com/d/msgi=
d/bitcoindev/a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wo=
s4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg%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 on the web visit https://groups.google.com/d/msgid/=
bitcoindev/cUk3mhYDInTKWp31VeaGZa68jCM6rhCiNFoQwD5JDeoi4MlxebiVUo06Oiuoj-xb=
KAkxyO7LpoFeZrj3Ak5cOeJRGDG83ITDdSXrZ3PQta0%3D%40protonmail.com.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Please note=
 that the Block Storm Fix section was already amended with a (much needed) =
clarification:</div><div style=3D"font-family: Arial, sans-serif; font-size=
: 14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size:=
 14px;"><span>=3D=3D=3D Block Storm Fix =3D=3D=3D</span><div><br></div><div=
><span>When the next work required is calculated for the first block in a n=
ew difficulty period, the difficulty of the last block of the previous diff=
iculty period is only used as the base for this calculation if its difficul=
ty is not 1. If its difficulty is 1, all blocks in the previous difficulty =
period are checked in reverse order if any of them have a different difficu=
lty than 1. When a different difficulty is encountered, it is assumed to be=
 the actual difficulty of the network and used as the base for the calculat=
ion of the new difficulty level. Note that the first block in new difficult=
y period does not allow usage of the 20-min rule (this is prior behavior). =
This means that in each difficulty period the first block should always hav=
e the actual difficulty even if all other blocks were mined with the 20-min=
 rule.</span></div><div><br></div><span>For the avoidance of doubt, no matt=
er which block in the previous difficulty period provides the actual diffic=
ulty used as the basis for the calculation, the timestamp of the last block=
 is always the one that is used as the end time of the difficulty period.</=
span><br></div><div class=3D"protonmail_quote">
        On Wednesday, May 29th, 2024 at 12:01 AM, 'Fabian' via Bitcoin Deve=
lopment Mailing List &lt;bitcoindev@googlegroups.com&gt; wrote:<br>
        <blockquote type=3D"cite" class=3D"protonmail_quote">
            <div style=3D"font-family: Arial, sans-serif; font-size: 14px;"=
>Hello list,</div><div style=3D"font-family: Arial, sans-serif; font-size: =
14px;"><br></div><div style=3D"font-family: Arial, sans-serif; font-size: 1=
4px;">a potential reset or replacement of Testnet 3 has been discussed on t=
his list previously here:&nbsp;<span><a target=3D"_blank" rel=3D"noreferrer=
 nofollow noopener" href=3D"https://groups.google.com/g/bitcoindev/c/9bL00v=
Rj7OU/m/9yCPo3uUBwAJ">https://groups.google.com/g/bitcoindev/c/9bL00vRj7OU/=
m/9yCPo3uUBwAJ</a></span><br><span></span></div><div style=3D"font-family: =
Arial, sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px;">The discussion continued in the&nbsp;<s=
pan>accompanying</span> bitcoin core pull request (<span style=3D"scrollbar=
-width: thin; background-color: rgb(255, 255, 255);"><a target=3D"_blank" r=
el=3D"noreferrer nofollow noopener" href=3D"https://github.com/bitcoin/bitc=
oin/pull/29775" style=3D"scrollbar-width: thin; color: blue;">https://githu=
b.com/bitcoin/bitcoin/pull/29775</a>)</span> which has been tested in the p=
ast couple of weeks and adopted by several projects on an experimental basi=
s, such as&nbsp;<span><a target=3D"_blank" rel=3D"noreferrer nofollow noope=
ner" href=3D"https://mempool.space/testnet4">https://mempool.space/testnet4=
</a>&nbsp;for example.</span><br><span></span></div><div style=3D"font-fami=
ly: Arial, sans-serif; font-size: 14px;"><span><br></span></div><div style=
=3D"font-family: Arial, sans-serif; font-size: 14px;"> I have now formalize=
d t<span style=3D"display: inline !important; background-color: rgb(255, 25=
5, 255);">he current rules and genesis block implemented in the PR as BIP d=
raft</span>:&nbsp;<span><a target=3D"_blank" rel=3D"noreferrer nofollow noo=
pener" href=3D"https://github.com/bitcoin/bips/pull/1601">https://github.co=
m/bitcoin/bips/pull/1601</a></span></div><div style=3D"font-family: Arial, =
sans-serif; font-size: 14px;"><br></div><div style=3D"font-family: Arial, s=
ans-serif; font-size: 14px;">-----------</div><div style=3D"font-family: Ar=
ial, sans-serif; font-size: 14px;"><span></span><div><span>=3D=3D Abstract =
=3D=3D</span></div><div><br></div><div><span>A new test network with the go=
al to replace Testnet 3. This network comes with small but important improv=
ements of the consensus rules, that should make it impractical to attack th=
e network using only CPU mining.</span></div><div><br></div><div><span>=3D=
=3D Motivation =3D=3D</span></div><div><br></div><div><span>Quoting the ori=
ginal mailing list post from Jameson Lopp:</span></div><div><br></div><div>=
<span>"Testnet3 has been running for 13 years. It's on block 2.5 million so=
mething and the block reward is down to ~0.014 TBTC, so mining is not doing=
 a great job at distributing testnet coins anymore.</span></div><div><br></=
div><div><span>The reason the block height is insanely high is due to a rat=
her amusing edge case bug that causes the difficulty to regularly get reset=
 to 1, which causes a bit of havoc. If you want a deep dive into the quirk:=
 <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://=
blog.lopp.net/the-block-storms-of-bitcoins-testnet/">https://blog.lopp.net/=
the-block-storms-of-bitcoins-testnet/</a></span></div><div><br></div><div><=
span>Testnet3 is being actively used for scammy airdrops; those of us who t=
end to be generous with our testnet coins are getting hounded by non-develo=
pers chasing cheap gains.</span></div><div><br></div><div><span>As a result=
, TBTC is being actively bought and sold; one could argue that the fundamen=
tal principle of testnet coins having no value has been broken."</span></di=
v><div><br></div><div><span>Since then the issue with block storms has been=
 further demonstrated on Testnet 3 when three years' worth of blocks were m=
ined in a few weeks while rendering the network practically unusable at the=
 same time.</span></div><div><br></div><div><span>=3D=3D Specification =3D=
=3D</span></div><div><br></div><div><span>Consensus of Testnet 4 follows th=
e same rules as Testnet 3 with the exception of the two new rules detailed =
below.</span></div><div><br></div><div><span>This means that the existing 2=
0 min difficulty exception in Testnet 3 is explicitly kept in place, meanin=
g that a block with a timestamp 20 minutes further into the future from the=
 current time is allowed to have a minimum difficulty of 1 instead of whate=
ver the actual level currently is.</span></div><div><br></div><div><span>=
=3D=3D=3D Block Storm Fix =3D=3D=3D</span></div><div><br></div><div><span>W=
hen the next work required is calculated for the first block in a new diffi=
culty period, the difficulty of the last block of the previous difficulty p=
eriod is only used as the base for this calculation if its difficulty is no=
t 1. If its difficulty is 1, all blocks in the previous difficulty period a=
re checked in reverse order if any of them have a different difficulty than=
 1. When a different difficulty is encountered, it is assumed to be the act=
ual difficulty of the network and used as the base for the calculation of t=
he new difficulty level. Only if all blocks from the previous difficulty pe=
riod have had a difficulty of 1 (possibly by the use of the 20-min rule), t=
his is also used as the base for the calculation of the next difficulty per=
iod.</span></div><div><br></div><div><span>For the avoidance of doubt, no m=
atter which block in the previous difficulty period provides the actual dif=
ficulty used as the basis for the calculation, the timestamp of the last bl=
ock is always the one that is used as the end time of the difficulty period=
.</span></div><div><br></div><div><span>=3D=3D=3D Time Warp Fix =3D=3D=3D</=
span></div><div><br></div><div><span>To protect against the time warp attac=
k, the following rule proposed as part of The Great Consensus Cleanup is en=
forced: "The nTime field of each block whose height, mod 2016, is 0 must be=
 greater than or equal to the nTime field of the immediately prior block mi=
nus 600. For the avoidance of doubt, such blocks must still comply with exi=
sting Median-Time-Past nTime restrictions."</span></div><div><br></div><div=
><span>=3D=3D Rationale =3D=3D</span></div><div><br></div><div><span>The ap=
plied changes were the result of discussions on the mailing list and the PR=
. The selected changes try to strike a balance between minimal changes to t=
he network (keeping it as close to mainnet as possible) while making it mor=
e robust against attackers that try to disrupt the network. Several alterna=
tive designs were considered:</span></div><div><br></div><div><span>* For t=
he block storm fix an alternative fix could have been to prevent the last b=
lock in a difficulty period from applying the existing difficulty exception=
. Both solutions were deemed acceptable and there was no clear preference a=
mong reviewers.</span></div><div><span>* Removal of the 20-min difficulty e=
xception was discussed but dismissed since several reviewers insisted that =
it was a useful feature allowing non-standard transactions to be mined with=
 just a CPU.</span></div><div><span>* Increase of minimum difficulty was di=
scussed but dismissed as it would categorically prevent participation in th=
e network using a CPU miner.</span></div><div><span>* Increase of the delay=
 in the 20 min difficulty exception was suggested but did not receive signi=
ficant support.</span></div><div><span>* Re-enabling &lt;code&gt;acceptnons=
tdtxn&lt;/code&gt; in bitcoin core by default was dismissed as it had led t=
o confusion among layer-2s that had used testnet for transaction propagatio=
n tests and expected it to behave similar to mainnet.</span></div><div><spa=
n>* Motivating miners to re-org min difficulty blocks was suggested but thi=
s may still be done after Testnet 4 is deployed, so it can be considered ou=
t of scope for this BIP.</span></div><div><span>* Persisting the real diffi=
culty in the version field was suggested to prevent exploits of the 20-min =
rule in an even more robust way, but did not receive a critical level of su=
pport since it would be a more invasive change.</span></div><div><br></div>=
<div><span>=3D=3D Network Parameters =3D=3D</span></div><div><br></div><div=
><span>=3D=3D=3D Consensus Rules =3D=3D=3D</span></div><div><br></div><div>=
<span>All consensus rules active on mainnet at the time of this proposal ar=
e enforced from block 1, the newest of these rules being the Taproot softfo=
rk.</span></div><div><br></div><div><span>=3D=3D=3D Genesis Block =3D=3D=3D=
</span></div><div><br></div><div><span>* Message: &lt;code&gt;03/May/2024 0=
00000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e&lt;/code&gt=
;</span></div><div><span>* Pubkey: &lt;code&gt;0000000000000000000000000000=
00000000000000000000000000000000000000&lt;/code&gt;</span></div><div><span>=
* Time stamp: 1714777860</span></div><div><span>* Nonce: 393743547</span></=
div><div><span>* Difficulty: &lt;code&gt;0x1d00ffff&lt;/code&gt;</span></di=
v><div><span>* Version: 1</span></div><div><br></div><div><span>The resulti=
ng genesis block hash is &lt;code&gt;00000000da84f2bafbbc53dee25a72ae507ff4=
914b867c565be350b0da8bf043&lt;/code&gt;, and the block hex is &lt;code&gt;0=
1000000010000000000000000000000000000000000000000000000000000000000000000ff=
ffffff5504ffff001d01044c4c30332f4d61792f32303234203030303030303030303030303=
030303030303030316562643538633234343937306233616139643738336262303031303131=
6662653865613865393865303065ffffffff0100f2052a01000000232100000000000000000=
0000000000000000000000000000000000000000000000000ac00000000&lt;/code&gt;.</=
span></div><div><br></div><div><span>=3D=3D=3D Message Start =3D=3D=3D</spa=
n></div><div><br></div><div><span>The message start is defined as &lt;code&=
gt;0x1c163f28&lt;/code&gt;. These four bytes were randomly generated and ha=
ve no special meaning.</span></div><div><br></div><div><span>=3D=3D Compati=
bility =3D=3D</span></div><div><br></div><div><span>This specification is b=
ackward compatible in the sense that existing software can use Testnet 4 ou=
t of the box, assuming support for Testnet 3 already exists.</span></div><d=
iv><br></div><div><span>Simply by adding the network parameters for Testnet=
 4 (magic number, etc.), a client can connect to and use Testnet 4 without =
further modifications. The block headers have valid proof of work, so clien=
ts can trivially check that blocks are "probably" valid.</span></div><div><=
br></div><div><span>However, without the implementation of the changes deta=
iled in Specifications, a client could follow a chain that does not follow =
the rules. Any fully validating node should check these rules and reject bl=
ocks that fail to follow them. Clients should either validate these rules o=
r connect to trusted peers that do full validation.</span></div><div><br></=
div><div><span>=3D=3D Reference implementation =3D=3D</span></div><div><br>=
</div><div><span>Pull request at <a target=3D"_blank" rel=3D"noreferrer nof=
ollow noopener" href=3D"https://github.com/bitcoin/bitcoin/pull/29775">http=
s://github.com/bitcoin/bitcoin/pull/29775</a></span></div><div><br></div><d=
iv><span>=3D=3D References =3D=3D</span></div><div><br></div><div><span># O=
riginal mailing list thread: <a target=3D"_blank" rel=3D"noreferrer nofollo=
w noopener" href=3D"https://groups.google.com/g/bitcoindev/c/9bL00vRj7OU/m/=
kFPaQCzmBwAJ">https://groups.google.com/g/bitcoindev/c/9bL00vRj7OU/m/kFPaQC=
zmBwAJ</a></span></div><div><span># Blog post on block storm bug: <a target=
=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://blog.lopp.=
net/the-block-storms-of-bitcoins-testnet/">https://blog.lopp.net/the-block-=
storms-of-bitcoins-testnet/</a></span></div><div><span># Consensus Cleanup =
BIP draft: <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=
=3D"https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.medi=
awiki">https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.m=
ediawiki</a></span></div><div><span># Consensus Cleanup PR draft: <a target=
=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://github.com=
/bitcoin/bitcoin/pull/15482">https://github.com/bitcoin/bitcoin/pull/15482<=
/a></span></div><div><br></div><div><span>=3D=3D Copyright =3D=3D</span></d=
iv><div><br></div><div><span>This document is licensed under the Creative C=
ommons CC0 1.0 Universal license.</span></div></div><div class=3D"protonmai=
l_signature_block" style=3D"font-family: Arial, sans-serif; font-size: 14px=
;">
</div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"m=
ailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googl=
egroups.com</a>.<br>
To view this discussion on the web visit <a target=3D"_blank" rel=3D"norefe=
rrer nofollow noopener" href=3D"https://groups.google.com/d/msgid/bitcoinde=
v/a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mW=
EMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg%3D%40protonmail.com">https://groups.goog=
le.com/d/msgid/bitcoindev/a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSp=
VflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg%3D%40protonmail.=
com</a>.<br>

        </blockquote><br>
    </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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/cUk3mhYDInTKWp31VeaGZa68jCM6rhCiNFoQwD5JDeoi4MlxebiVU=
o06Oiuoj-xbKAkxyO7LpoFeZrj3Ak5cOeJRGDG83ITDdSXrZ3PQta0%3D%40protonmail.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/cUk3mhYDInTKWp31VeaGZa68jCM6rhCiNFoQwD5JDeoi4MlxebiVUo06Oiuoj-xbK=
AkxyO7LpoFeZrj3Ak5cOeJRGDG83ITDdSXrZ3PQta0%3D%40protonmail.com</a>.<br />

--b1_AFA1mBiJg99tjq1ZllN2SCv1urIHb7P7MdQ95E60pM--