From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 30 May 2024 15:00:33 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sCnp1-0000qB-SN for bitcoindev@gnusha.org; Thu, 30 May 2024 15:00:33 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-25079f9c013sf917703fac.2 for ; Thu, 30 May 2024 15:00:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717106426; cv=pass; d=google.com; s=arc-20160816; b=vAvtC6bmJQKkNr61VzX4g4zhPBaIaeMKimFdulmePaastzSHjgpqN2aHuLTiEvBEkr oEGXm6ZS3Sx09/tlNFCjn0W1pqpHH8DjRBPKSV0h7mc8gWGMbMWlhUX48d8GMiDqjc1I 8Iz+LAMfVkx4hlVXzeCRv86cQVkMxnFW+O8vblvi1MB3EfXh0FfFTrkkASeK3kNoKdzG np+bJmhrNUmyYAU9WbraYSE2ifmE+1BCRVyjhnFCiumNs/zh5npWHb9baDwHN0wrVumK 6WrlLHcHWBq395EVfibdv/W9oEjy1euig/sXLaQwhxW3djgtB+hog8h29BMk+FK5bVet mL8Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; 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=jzNKgWS0zhorjNSHkbviOIVWWyovJLmg5gIXXh0mowA=; fh=i/0hKvR+SXykFks/tmYgC7L81iK60DOiZ7FmNxShXAc=; b=KE5fn6n9+lNwpp5K05gKHpg9FOuB3zvNVxqtE3zDFH5jDkl9qMwK4SuvLzikYlu+rR 9Aa9pfb9NSTiGm6GItk320EJKXI4Lw9Wt4SQOTKj24XQKK+NPyERv+Gl0A6jwq4nh5WG xFsFuxb1KZ1HsLnHCWrVJu/Y8J58Ljjg3lAsQh5qPcr8hVYblqT/Pvub7RgzhQZhmXYk ggsy1GrjExfwH8IfuyGqm/kAZV8pCRF5GrDAK+IP4ZXX6+gEW541OkCfbK1JsgKFFy4M tHsPuFB+w8c19/XGFkt/nhaCMPiabJ5a+qnQB4UWrkzlvx5R9B7VdcibrFCQbn9+8ZcT Ul7A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=zb1Puk7k; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.134 as permitted sender) smtp.mailfrom=fjahr@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=1717106426; x=1717711226; 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=jzNKgWS0zhorjNSHkbviOIVWWyovJLmg5gIXXh0mowA=; b=Bz2bUqzDmw8/dTgBCe2aK7xNXPg+K3iq52JYmCaLK7pRix5tViJBUncxeJcULCyKOh EEGnfNfDe9apBLJDMMAoRyodqo2GIiJHhHOEBt+3JVVEDHrL6WqjU72UMpP4gF8TAL9B 3uGfh5gtdlw2bL6J+DBSUFTcLKVCnY33hugd3/WPtyHICX6H6Ctj0NpjcZHShE4qh+3U dwPxaPEX6CvQZE9G+7cPxriE3FicCWqezpVvTKbrlRnQkg2EbZaRTII3/12SWWAIeE0X vig3mz7US29PfV2oVLm+HA7dNF0+cQ1gbjUd2YlIrxF/u4i7Q5NTIRf2tLkVly8r7DyF cH2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717106426; x=1717711226; 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=jzNKgWS0zhorjNSHkbviOIVWWyovJLmg5gIXXh0mowA=; b=uwDfrsO7scJvvsaVHDiNxu1Zh1uxsCAItw3WzcMAszgOyzoCbEgms6GffjDUXJ6RPw tTSHUweTSxNpMZU/YCBih7EAFt3TdGmQ6v4nMtMf9yDhtIr/dG+YxwstQL1B0cVHJPLf 2xPcN29tomfgVs39G4tBMxOJAmQYGTaiOwb18+aGxycQ1uo9KO6Uf9vn+AqujIWTJzTJ h30v+gN+fnQkG0IwyomWWtPgPMHJA0R3CDNa99n0VidileY2a8cVVKOKy+plqFcyLsUT iOBPHw7I99e6ad8ClWEbLBk0qqvzi1NC9/YcHwlPNPKZzudtSiKMFlZ0kx6wtc09uHGc 93tw== X-Forwarded-Encrypted: i=2; AJvYcCWoFfze3DuyIY/xzY9c2AtdB3keNEjBRM/dyrDBhWPrErOT1PbtwcmpqnYcBFoGdK1jXOmjThhkuDk1Xeb4Dn6dydM/A/Y= X-Gm-Message-State: AOJu0YygStxAtKOyWY15/R7n6v8Bf+vmParfRi5bDGKZZ76KQkdz0um2 FBwvHlk1OFWYL3KVkaKlHa1swF6zeaGsxeaPv2CzP0qJuPRUluYN X-Google-Smtp-Source: AGHT+IFypknTMawGNTISn5qkq2Fk46MBUfEtNLt5VOf69teXFbllMCymv0hEmWpNZsJ9jGEfUkpidA== X-Received: by 2002:a05:6870:470f:b0:250:6023:76c4 with SMTP id 586e51a60fabf-2508b982beamr220927fac.15.1717106425731; Thu, 30 May 2024 15:00:25 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:ac8:5911:0:b0:43a:b15a:f8c9 with SMTP id d75a77b69052e-43fe8e508a9ls16719891cf.0.-pod-prod-07-us; Thu, 30 May 2024 15:00:24 -0700 (PDT) X-Received: by 2002:a05:620a:8da:b0:794:ed5b:2db6 with SMTP id af79cd13be357-794ed5b3114mr1159485a.6.1717106424099; Thu, 30 May 2024 15:00:24 -0700 (PDT) Received: by 2002:a05:620a:1aa8:b0:793:220:79c1 with SMTP id af79cd13be357-794e132bc8cms85a; Tue, 28 May 2024 16:41:35 -0700 (PDT) X-Received: by 2002:a05:600c:3514:b0:415:ff48:59fc with SMTP id 5b1f17b1804b1-42122ae4462mr3071395e9.8.1716939693024; Tue, 28 May 2024 16:41:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1716939693; cv=none; d=google.com; s=arc-20160816; b=RZQ3HAKqh1Z16a5uDB/uSwfVE0lf8ApiQtFpwO1VMP8KgjtypT707EOzeK5lmtHaga XmfNVPhxI6TLcA3hcMC8CoqNNbDMHYfLUInIknZV3OmBzlrzBel1dFH/G/4M/LaRmi84 d4cowei2mFZDYoMBvyTO2gRKXLkes5coFc9nJ8PW2ZkyrtciRGwyVNIbTnbYzFmE4E+e OpLJtc/Oly+Gnt29kR29/EkrLqgQYA45jibvcXToK9ri4jGZVWZb8GJkYa8PAcoKLdO4 7BRQn1qya3ankN/RariwlKiFAEgNj9dHA+BtvMb7UyrqarvG5jntlg4gctlB0i/MPqFN zo4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=qaY8nCr6q8o8BKcA4aLHz16y6yCYuEzvRvMfGjRouCM=; fh=ZoFN/wAJsc7YujXIAOohNqslPO0XeXRGfI/gbLftL6I=; b=Gudnl60KoX0pfFiOQnXmcPycaFEifVe8OinuaW3z2SJHryEzvaHqCkg9AkuLdMZ4Yl WuFqb0LbbN/fOyqoGYA9MjOuY5FMk9cIo7XnS0/3rB5kRAosIvx2za1LEikkr8qypfiD uCv7EadbFeR1HLjEmRamPtTc26rl0reFEdcKzcsLny6uRjfcL0no3CTIM9ieP6m3haYa rqnPwTyCd7GEc8qDabXmzjpu3CFBaARci+N6+oidcFJ1q6hrX2njQ7CKeWvI28nT6rFF ryQmV6guq0/W2MDKPNMrwKme+XlcV0kfLmfobs5+GRreyaHEYmZH6Ee6rw8QP326xURR lezA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=zb1Puk7k; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.134 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch. [185.70.40.134]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-42122786751si403895e9.0.2024.05.28.16.41.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 May 2024 16:41:33 -0700 (PDT) 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 From: "'Fabian' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] BIP for Testnet 4 Message-ID: In-Reply-To: References: Feedback-ID: 5067558:user:proton X-Pm-Message-ID: 3242898416be67e0b515a1db9ad12226226df1b7 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_AFA1mBiJg99tjq1ZllN2SCv1urIHb7P7MdQ95E60pM" X-Original-Sender: fjahr@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=zb1Puk7k; spf=pass (google.com: domain of fjahr@protonmail.com designates 185.70.40.134 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Fabian Reply-To: Fabian 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 (-) 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 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 acceptnonstdtxn 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: 03/May/2024 000000000000000000001ebd58c244970b3aa9d783bb= 001011fbe8ea8e98e00e > * Pubkey: 000000000000000000000000000000000000000000000000000000000= 000000000 > * Time stamp: 1714777860 > * Nonce: 393743547 > * Difficulty: 0x1d00ffff > * Version: 1 > > The resulting genesis block hash is 00000000da84f2bafbbc53dee25a72a= e507ff4914b867c565be350b0da8bf043, and the block hex is 010000= 00010000000000000000000000000000000000000000000000000000000000000000fffffff= f5504ffff001d01044c4c30332f4d61792f3230323420303030303030303030303030303030= 303030303031656264353863323434393730623361613964373833626230303130313166626= 53865613865393865303065ffffffff0100f2052a0100000023210000000000000000000000= 00000000000000000000000000000000000000000000ac00000000. > > =3D=3D=3D Message Start =3D=3D=3D > > The message start is defined as 0x1c163f28. 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
Please note= that the Block Storm Fix section was already amended with a (much needed) = clarification:

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

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.

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.
On Wednesday, May 29th, 2024 at 12:01 AM, 'Fabian' via Bitcoin Deve= lopment Mailing List <bitcoindev@googlegroups.com> wrote:
Hello list,

a potential reset or replacement of Testnet 3 has been discussed on t= his list previously here: https://groups.google.com/g/bitcoindev/c/9bL00vRj7OU/= m/9yCPo3uUBwAJ

The discussion continued in the accompanying bitcoin core pull request (https://githu= b.com/bitcoin/bitcoin/pull/29775) which has been tested in the p= ast couple of weeks and adopted by several projects on an experimental basi= s, such as https://mempool.space/testnet4=  for example.

I have now formalize= d the current rules and genesis block implemented in the PR as BIP d= raft: https://github.co= m/bitcoin/bips/pull/1601

-----------
=3D=3D Abstract = =3D=3D

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.

=3D= =3D Motivation =3D=3D

Quoting the ori= ginal mailing list post from Jameson Lopp:

= "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.

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:= https://blog.lopp.net/= the-block-storms-of-bitcoins-testnet/

<= 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.

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."

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.

=3D=3D Specification =3D= =3D

Consensus of Testnet 4 follows th= e same rules as Testnet 3 with the exception of the two new rules detailed = below.

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.

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

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.

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= .

=3D=3D=3D Time Warp Fix =3D=3D=3D

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."

=3D=3D Rationale =3D=3D

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:

* 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.
* 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.
* Increase of minimum difficulty was di= scussed but dismissed as it would categorically prevent participation in th= e network using a CPU miner.
* Increase of the delay= in the 20 min difficulty exception was suggested but did not receive signi= ficant support.
* Re-enabling <code>acceptnons= tdtxn</code> 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.
* 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 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.

=
=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 ar= e enforced from block 1, the newest of these rules being the Taproot softfo= rk.

=3D=3D=3D Genesis Block =3D=3D=3D=

* Message: <code>03/May/2024 0= 00000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e</code>= ;
* Pubkey: <code>0000000000000000000000000000= 00000000000000000000000000000000000000</code>
= * Time stamp: 1714777860
* Nonce: 393743547
* Difficulty: <code>0x1d00ffff</code>
* Version: 1

The resulti= ng genesis block hash is <code>00000000da84f2bafbbc53dee25a72ae507ff4= 914b867c565be350b0da8bf043</code>, and the block hex is <code>0= 1000000010000000000000000000000000000000000000000000000000000000000000000ff= ffffff5504ffff001d01044c4c30332f4d61792f32303234203030303030303030303030303= 030303030303030316562643538633234343937306233616139643738336262303031303131= 6662653865613865393865303065ffffffff0100f2052a01000000232100000000000000000= 0000000000000000000000000000000000000000000000000ac00000000</code>.

=3D=3D=3D Message Start =3D=3D=3D

The message start is defined as <code&= gt;0x1c163f28</code>. These four bytes were randomly generated and ha= ve no special meaning.

=3D=3D Compati= bility =3D=3D

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.

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.
<= br>
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.

=3D=3D Reference implementation =3D=3D

=

=3D=3D References =3D=3D


--
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@googl= egroups.com.
To view this discussion on the web visit https://groups.goog= le.com/d/msgid/bitcoindev/a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSp= VflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg%3D%40protonmail.= 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 on the web visit https://groups.google.com/d/msgid/b= itcoindev/cUk3mhYDInTKWp31VeaGZa68jCM6rhCiNFoQwD5JDeoi4MlxebiVUo06Oiuoj-xbK= AkxyO7LpoFeZrj3Ak5cOeJRGDG83ITDdSXrZ3PQta0%3D%40protonmail.com.
--b1_AFA1mBiJg99tjq1ZllN2SCv1urIHb7P7MdQ95E60pM--