diff options
| author | coinableS <coinables@gmail.com> | 2024-04-08 21:29:55 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-04-09 14:53:02 -0700 |
| commit | 33f47ad7b91e7863eeb7198b0941c414c96d631c (patch) | |
| tree | ab491bf2551fd6b50e7dbc55d2dc2f04caf7bbaf | |
| parent | c563593a0898464b4ffef999b74bbf9df6103f83 (diff) | |
| download | pi-bitcoindev-33f47ad7b91e7863eeb7198b0941c414c96d631c.tar.gz pi-bitcoindev-33f47ad7b91e7863eeb7198b0941c414c96d631c.zip | |
[bitcoindev] Re: The Future of Bitcoin Testnet
| -rw-r--r-- | f8/07e5b9f756716a6fc9fcf23425ddf820b51703 | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/f8/07e5b9f756716a6fc9fcf23425ddf820b51703 b/f8/07e5b9f756716a6fc9fcf23425ddf820b51703 new file mode 100644 index 000000000..adae388f1 --- /dev/null +++ b/f8/07e5b9f756716a6fc9fcf23425ddf820b51703 @@ -0,0 +1,507 @@ +Delivery-date: Tue, 09 Apr 2024 14:53:02 -0700 +Received: from mail-yb1-f184.google.com ([209.85.219.184]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBCQJVXW62QKRBNHR22YAMGQER6E3TGQ@googlegroups.com>) + id 1ruJOm-0005QK-HV + for bitcoindev@gnusha.org; Tue, 09 Apr 2024 14:53:02 -0700 +Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-dc693399655sf10803137276.1 + for <bitcoindev@gnusha.org>; Tue, 09 Apr 2024 14:52:59 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=googlegroups.com; s=20230601; t=1712699574; x=1713304374; 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=15EVcRBeGQrgW+mNwqPGKb8Lp5xfVjABBl5LG+M+MHU=; + b=tmlDPeDjxWZpHjPaqyHtxJlflx9inX8bh1y03ycHXLnrsJXl0iO+cGMGFicf+ZqG4G + V/S7r1OZTOFmpvW/GNAqa7e5omoDJRGxkkG0Z0XNbSAOy+R6lgOqxFzol9e0/e36Shha + 3l/q+cX9nnG8oWOG2fvDjACkegiBMrv/wsAYBYv+Z7oIOYfR6QYZXxGOZO0TfZ9Xld8J + HEM+F92GsWfMk9fybW2EZ6+JRgVkSCC24XGvLXAWASsSSjvhybggmiOV+7tDxTIkgdhg + pPS9oPvWPF2EsquvScwGt+glPyIJcS6IGiuo4XrP9H8/X5RkQ0sWTC9iLlF72vXbmFFa + Tv6A== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1712699574; x=1713304374; 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=15EVcRBeGQrgW+mNwqPGKb8Lp5xfVjABBl5LG+M+MHU=; + b=aRvWarqCe15qWUOs+EBKJE017Ainftf8+6EBclPQu0AryyGFEx0J9vO83u5ZvYwHbC + 4CK2f69NGOtNDlofPXDQmkz+QQFAJsDHpsEAhWZ8m8ZqYDBApUnEHvFJsqGQs67wfSf5 + ZuSCNbnSfLt0tn+kHmbgfCtewp0FWEzD4X+YbGDnbQJNdNhaevgAXP/h9FK61V1vPqXD + UYs8LigAX2kpmAPy1AyawuMmzNX2lKEfOdWSR+6kWRVeMlSG0ltHPox1EN6tMD8kDP5a + z//BPVhvy2evR5iN8nR7t2zWyIEooRzAFciKaoP9ejN9koLz8BOxXbkixdr5YRZoLReh + x1Eg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1712699574; x=1713304374; + 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=15EVcRBeGQrgW+mNwqPGKb8Lp5xfVjABBl5LG+M+MHU=; + b=xICX9raiNXxSTPq2AMyh9GA92xeC4nGlpCo4xgqBaQ6I534w92y/d0GKTHhnx+Aj+P + Z9sNUrDroz5NJwqY9DtNCt1IronEN33qDyPNjsDXo+SyyxZm4b/+9dH58W7TZ1Tp58+w + 1UyNENB1mO7QhQXTE9CDuB5rvpJ616Ne/D8MPKIygAV95aNf46Lr73wUF9YDnU8emcOj + 60FRmU/84RgWzFZ17Aumm9kat48kmewzIQemmfjRCT+/yU8MXxOP3t9oG0g7bL+JY/5h + 8QAN3pllR8tOeZI2kgbpCEumLJBGmJEp1mZ4E5jD0Y/Pttcndr99XDlfaMbW/CGBmJTG + vE5g== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=1; AJvYcCU85jmombjz6w7+vfraK+blxCYBDVvZkYtoRUUGUatSWLL7hlWFT+88/Tlf9BBZ/4uNTmFJJlbU+sTyt04LWYw7NzFX9ic= +X-Gm-Message-State: AOJu0YysOFRPV8YlFt+P6pa1VCUX4A3HIGvU38TITzEbk7yiLTErmVs+ + cmnUw36Fc5rhtkYiCetbdriZgIC+p/NqRa6MDNk2UOaWVr9I79wI +X-Google-Smtp-Source: AGHT+IFtYGHKeg5i5SoTWZXVuzMz1106PyjRbI9GATgHrOjHdMaUsHhkJH0Y4vr6Qza2da9cBeJ2zg== +X-Received: by 2002:a05:6902:383:b0:dc6:ff12:1a21 with SMTP id f3-20020a056902038300b00dc6ff121a21mr1090089ybs.31.1712699573459; + Tue, 09 Apr 2024 14:52:53 -0700 (PDT) +X-BeenThere: bitcoindev@googlegroups.com +Received: by 2002:a25:7507:0:b0:dcb:bfe0:81b8 with SMTP id q7-20020a257507000000b00dcbbfe081b8ls2875137ybc.0.-pod-prod-09-us; + Tue, 09 Apr 2024 14:52:52 -0700 (PDT) +X-Received: by 2002:a25:ef09:0:b0:dcb:b9d7:2760 with SMTP id g9-20020a25ef09000000b00dcbb9d72760mr281072ybd.13.1712699572197; + Tue, 09 Apr 2024 14:52:52 -0700 (PDT) +Received: by 2002:a05:690c:d89:b0:615:6ba5:7389 with SMTP id 00721157ae682-617c8099b2fms7b3; + Mon, 8 Apr 2024 21:29:57 -0700 (PDT) +X-Received: by 2002:a0d:e251:0:b0:615:134c:7ef3 with SMTP id l78-20020a0de251000000b00615134c7ef3mr2814329ywe.9.1712636996134; + Mon, 08 Apr 2024 21:29:56 -0700 (PDT) +Date: Mon, 8 Apr 2024 21:29:55 -0700 (PDT) +From: coinableS <coinables@gmail.com> +To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +Message-Id: <83ec2b84-2255-4ac1-a40c-3f3a04a1c86fn@googlegroups.com> +In-Reply-To: <6733b634-e6da-4bb3-a3b6-bffa41395e9cn@googlegroups.com> +References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com> + <6733b634-e6da-4bb3-a3b6-bffa41395e9cn@googlegroups.com> +Subject: [bitcoindev] Re: The Future of Bitcoin Testnet +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="----=_Part_70130_94169278.1712636995753" +X-Original-Sender: coinableS@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_70130_94169278.1712636995753 +Content-Type: multipart/alternative; + boundary="----=_Part_70131_335253175.1712636995753" + +------=_Part_70131_335253175.1712636995753 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +A reset will also need hashpower behind it which may pose a problem if=20 +there are entities currently benefiting from the existing chain. The last= +=20 +reset was so long ago the community was much tighter-knit and shared a=20 +similar ethos making a reset deploy rather trivial to a point of near=20 +centralization, today there are a lot more parties involved that would need= +=20 +to cooperate on a reset.=20 + +Whoever is currently mining is spending a non-negligible amount to mine=20 +testnet based on the current difficulty and mempool.space indicates most=20 +are mined by unknown miners.=20 + +Will there be enough miners willing to spend money, electricity and=20 +dedicate HW to mine the reset chain? I'd be willing to run my CPU and/or=20 +USB miners, but not prepared to run a modern asic that uses a ton of energy= +=20 +and sounds like a chainsaw in my home for no gain aside from destroying the= +=20 +perceived "value" of testnet 3. + +What's the incentive for supporters of a reset to deploy resources and=20 +capital in order to initiate a reset? It's rather ironic that value would= +=20 +need to be invested and voluntarily destroyed in order to make testnet=20 +valueless again (which to emsit's point the chain may be "doomed to have=20 +value").=20 + +I think a reset may prove to be trickier than some anticipate because=20 +testnet 3 has been going for so long now and this time there are market=20 +dynamics, and proof of work game theory at play which didn't exist with the= +=20 +two prior resets. +On Monday, April 8, 2024 at 12:35:38=E2=80=AFPM UTC-7 Garlo Nicon wrote: + +> > so mining is not doing a great job at distributing testnet coins any mo= +re +> +> It is a feature, not a bug. Would people want to reset Bitcoin main=20 +> network in the future, for exactly the same reasons? Or would they want t= +o=20 +> introduce "tail supply", or other similar inventions, to provide sufficie= +nt=20 +> incentive for miners? This testnet3 is unique, because it has quite low= +=20 +> block reward. And that particular feature should be preserved, even if th= +e=20 +> network would be resetted (for example, it could be "after 12 halvings, b= +ut=20 +> where all previous coins were burned"). And not, it is not the same as=20 +> starting from 50 tBTC, as long as fee rates are left unchanged (and 0.014= +=20 +> TBTC means "the ability to push around 1.4 MB of data, with feerate of 1= +=20 +> sat/vB", instead of 50 tBTC, which means "pushing 5 GB with the same=20 +> feerate"). +> +> > a rather amusing edge case bug that causes the difficulty to regularly= +=20 +> get reset to 1 +> +> It can be fixed in a soft-fork way, no network reset is needed to achieve= +=20 +> that. Because if there is a block number X, and it could have minimal=20 +> difficulty, under the current rules, then it is possible to reject it, an= +d=20 +> enforce the higher difficulty. In general, increasing difficulty is a=20 +> soft-fork. For example, if someone would enforce testnet difficulty on=20 +> regtest, it would be perfectly valid. All that is needed, is just rejecti= +ng=20 +> more block hashes, so even if all fields are left unchanged, the old clie= +nt=20 +> could see, that the 32-bit difficulty field says "minimal", but produced= +=20 +> blocks are not accepted, and "the true difficulty" is put anywhere else,= +=20 +> for example just after the block number in the coinbase transaction. +> +> > Testnet3 is being actively used for scammy airdrops +> +> This is because mining is costly, and because coins are never "resetted",= +=20 +> so they are never "worthless". Pointing at some chain, and saying "this= +=20 +> should be worthless" is not enough to make it. There are no consensus rul= +es=20 +> to ensure that test coins are truly worthless. There is no "automatic=20 +> reset", or any "demurrage". If large amounts of coins are misused, then= +=20 +> that misuse can be stopped, by burning coins, or invalidating them in any= +=20 +> other way, for example "the coin is unspendable, if it was created during= +=20 +> the previous halving". As long as there are no such rules, resetting the= +=20 +> network won't help in the long term, so something new is needed, to=20 +> discourage assigning any value into test coins. +> +> > Should we plan for a reset of testnet? +> +> I guess the answer is "yes", but maybe not by "throwing away the whole=20 +> existing chain", but just by "fixing errors one-by-one". For example,=20 +> fixing blockstorms as a soft-fork would be a good starting point. And in= +=20 +> practice, it may turn out, that all fixes could be applied in a soft-fork= +=20 +> way, which would be the best, because then it would be enforced also on= +=20 +> non-upgraded clients. +> +> > If so, given how long it has been since the last reset and how many=20 +> production systems will need to be updated, would a reset need to be done= +=20 +> with a great deal of notice? +> +> No additional "notice" would be needed, if every "fix" would be a=20 +> soft-fork, and if all old clients would follow all new changes. +> +> > Is there interest in fixing the difficulty reset bug? +> +> Yes. But because it could be a soft-fork, miners could signal readiness i= +n=20 +> block versions. Also, as with every other soft-fork, it would have=20 +> additional advantage, that if someone would want to locally test=20 +> "blockstorms", then that person would be able to locally create a chain,= +=20 +> where that particular soft-fork would be inactive. Which means, that it= +=20 +> would be still possible, to download the new chain, and disable that=20 +> soft-fork locally, if someone would need it. +> +> > Would such a change, which would technically be a hard fork +> +> It would be a soft-fork. Each difficulty increase is a soft-fork, because= +=20 +> "old blocks are invalid in a new version" (they don't meet increased=20 +> difficulty), but also "new blocks are valid in an old version" (they meet= +=20 +> the old difficulty, exactly as the mainnet Genesis Block with 40 leading= +=20 +> zero bits meets the required difficulty with 32 leading zeroes). +> +> > necessitate a BIP or could we just YOLO it? +> +> Well, it is possible to just add some flag, like "-blockstorm=3D0". Then,= +=20 +> some miners could activate it, just like they activated full-RBF. And if= +=20 +> the majority would want to get rid of blockstorms, then it would just=20 +> happen naturally, if the majority would simply reject blockstorms in a=20 +> soft-fork way. I think it is not that important to make a BIP, unless you= +=20 +> really want to get through the whole process. +> +> > Is all of the above a waste of time and we should instead deprecate=20 +> testnet in favor of signet? +> +> This scenario is also possible, but probably not in the way you think.=20 +> Transition from testnet into signet is a perfect soft-fork. If you decide= +,=20 +> that since block number N, all blocks should be signed with "signet=20 +> challenge", then it would lead to a natural conversion from permissionles= +s=20 +> mining into permissioned mining. You can implement it, and start with=20 +> OP_TRUE, to test, if everything is working correctly. And then, you can= +=20 +> apply for example "OP_1 <taproot_address>" as the signet challenge, and= +=20 +> then use all TapScript features to sign new testnet3 blocks. +> +> sunday, 31 march 2024 at 15:24:34 UTC+2 Jameson Lopp wrote: +> +> Hi all, +> +> I'd like to open a discussion about testnet3 to put out some feelers on= +=20 +> potential changes to it. First, a few facts: +> +> 1. Testnet3 has been running for 13 years. It's on block 2.5 million=20 +> something and the block reward is down to ~0.014 TBTC, so mining is not= +=20 +> doing a great job at distributing testnet coins any more. +> +> 2. The reason the block height is insanely high is due to a rather amusin= +g=20 +> edge case bug that causes the difficulty to regularly get reset to 1, whi= +ch=20 +> causes a bit of havoc. If you want a deep dive into the quirk:=20 +> https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/ +> +> 3. Testnet3 is being actively used for scammy airdrops; those of us who= +=20 +> tend to be generous with our testnet coins are getting hounded by=20 +> non-developers chasing cheap gains. +> +> 4. As a result, TBTC is being actively bought and sold; one could argue= +=20 +> that the fundamental principle of testnet coins having no value has been= +=20 +> broken. +> +> This leads me to ponder the following questions, for which I'm soliciting= +=20 +> feedback. +> +> 1. Should we plan for a reset of testnet? If so, given how long it has=20 +> been since the last reset and how many production systems will need to be= +=20 +> updated, would a reset need to be done with a great deal of notice? +> +> 2. Is there interest in fixing the difficulty reset bug? It should be a= +=20 +> one liner fix, and I'd argue it could be done sooner rather than later, a= +nd=20 +> orthogonal to the network reset question. Would such a change, which woul= +d=20 +> technically be a hard fork (but also arguably a self resolving fork due t= +o=20 +> the difficulty dynamics) necessitate a BIP or could we just YOLO it? +> +> 3. Is all of the above a waste of time and we should instead deprecate=20 +> testnet in favor of signet? +> +> - Jameson +> +> + +--=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/83ec2b84-2255-4ac1-a40c-3f3a04a1c86fn%40googlegroups.com. + +------=_Part_70131_335253175.1712636995753 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div>A reset will also need hashpower behind it which may pose a problem if= + there are entities currently benefiting from the existing chain. The last = +reset was so long ago the community was much tighter-knit and shared a simi= +lar ethos making a reset deploy rather trivial to a point of near centraliz= +ation, today there are a lot more parties involved that would need to coope= +rate on a reset.=C2=A0</div><div><br /></div><div>Whoever is currently mini= +ng is spending a non-negligible amount to mine testnet based on the current= + difficulty and mempool.space indicates most are mined by unknown miners.= +=C2=A0</div><div><br /></div><div>Will there be enough miners willing to sp= +end money, electricity and dedicate HW to mine the reset chain? I'd be will= +ing to run my CPU and/or USB miners, but not prepared to run a modern asic = +that uses a ton of energy and sounds like a chainsaw in my home for no gain= + aside from destroying the perceived "value" of testnet 3.<br /></div><div>= +<br /></div><div>What's the incentive for supporters of a reset to deploy r= +esources and capital in order to initiate a reset? It's rather ironic that = +value would need to be invested and voluntarily destroyed in order to make = +testnet valueless again (which to emsit's point the chain may be "doomed to= + have value").=C2=A0</div><div><br /></div><div>I think a reset may prove t= +o be trickier than some anticipate because testnet 3 has been going for so = +long now and this time there are market dynamics, and proof of work game th= +eory at play which didn't exist with the two prior resets.</div><div class= +=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Monday, April 8,= + 2024 at 12:35:38=E2=80=AFPM UTC-7 Garlo Nicon wrote:<br/></div><blockquote= + class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid= + rgb(204, 204, 204); padding-left: 1ex;">> so mining is not doing a grea= +t job at distributing testnet coins any more<br><br>It is a feature, not a = +bug. Would people want to reset Bitcoin main network in the future, for exa= +ctly the same reasons? Or would they want to introduce "tail supply&qu= +ot;, or other similar inventions, to provide sufficient incentive for miner= +s? This testnet3 is unique, because it has quite low block reward. And that= + particular feature should be preserved, even if the network would be reset= +ted (for example, it could be "after 12 halvings, but where all previo= +us coins were burned"). And not, it is not the same as starting from 5= +0 tBTC, as long as fee rates are left unchanged (and 0.014 TBTC means "= +;the ability to push around 1.4 MB of data, with feerate of 1 sat/vB",= + instead of 50 tBTC, which means "pushing 5 GB with the same feerate&q= +uot;).<br><br>> a rather amusing edge case bug that causes the difficult= +y to regularly get reset to 1<br><br>It can be fixed in a soft-fork way, no= + network reset is needed to achieve that. Because if there is a block numbe= +r X, and it could have minimal difficulty, under the current rules, then it= + is possible to reject it, and enforce the higher difficulty. In general, i= +ncreasing difficulty is a soft-fork. For example, if someone would enforce = +testnet difficulty on regtest, it would be perfectly valid. All that is nee= +ded, is just rejecting more block hashes, so even if all fields are left un= +changed, the old client could see, that the 32-bit difficulty field says &q= +uot;minimal", but produced blocks are not accepted, and "the true= + difficulty" is put anywhere else, for example just after the block nu= +mber in the coinbase transaction.<br><br>> Testnet3 is being actively us= +ed for scammy airdrops<br><br>This is because mining is costly, and because= + coins are never "resetted", so they are never "worthless&qu= +ot;. Pointing at some chain, and saying "this should be worthless"= +; is not enough to make it. There are no consensus rules to ensure that tes= +t coins are truly worthless. There is no "automatic reset", or an= +y "demurrage". If large amounts of coins are misused, then that m= +isuse can be stopped, by burning coins, or invalidating them in any other w= +ay, for example "the coin is unspendable, if it was created during the= + previous halving". As long as there are no such rules, resetting the = +network won't help in the long term, so something new is needed, to dis= +courage assigning any value into test coins.<br><br>> Should we plan for= + a reset of testnet?<br><br>I guess the answer is "yes", but mayb= +e not by "throwing away the whole existing chain", but just by &q= +uot;fixing errors one-by-one". For example, fixing blockstorms as a so= +ft-fork would be a good starting point. And in practice, it may turn out, t= +hat all fixes could be applied in a soft-fork way, which would be the best,= + because then it would be enforced also on non-upgraded clients.<br><br>>= +; If so, given how long it has been since the last reset and how many produ= +ction systems will need to be updated, would a reset need to be done with a= + great deal of notice?<br><br>No additional "notice" would be nee= +ded, if every "fix" would be a soft-fork, and if all old clients = +would follow all new changes.<br><br>> Is there interest in fixing the d= +ifficulty reset bug?<br><br>Yes. But because it could be a soft-fork, miner= +s could signal readiness in block versions. Also, as with every other soft-= +fork, it would have additional advantage, that if someone would want to loc= +ally test "blockstorms", then that person would be able to locall= +y create a chain, where that particular soft-fork would be inactive. Which = +means, that it would be still possible, to download the new chain, and disa= +ble that soft-fork locally, if someone would need it.<br><br>> Would suc= +h a change, which would technically be a hard fork<br><br>It would be a sof= +t-fork. Each difficulty increase is a soft-fork, because "old blocks a= +re invalid in a new version" (they don't meet increased difficulty= +), but also "new blocks are valid in an old version" (they meet t= +he old difficulty, exactly as the mainnet Genesis Block with 40 leading zer= +o bits meets the required difficulty with 32 leading zeroes).<br><br>> n= +ecessitate a BIP or could we just YOLO it?<br><br>Well, it is possible to j= +ust add some flag, like "-blockstorm=3D0". Then, some miners coul= +d activate it, just like they activated full-RBF. And if the majority would= + want to get rid of blockstorms, then it would just happen naturally, if th= +e majority would simply reject blockstorms in a soft-fork way. I think it i= +s not that important to make a BIP, unless you really want to get through t= +he whole process.<br><br>> Is all of the above a waste of time and we sh= +ould instead deprecate testnet in favor of signet?<br><br>This scenario is = +also possible, but probably not in the way you think. Transition from testn= +et into signet is a perfect soft-fork. If you decide, that since block numb= +er N, all blocks should be signed with "signet challenge", then i= +t would lead to a natural conversion from permissionless mining into permis= +sioned mining. You can implement it, and start with OP_TRUE, to test, if ev= +erything is working correctly. And then, you can apply for example "OP= +_1 <taproot_address>" as the signet challenge, and then use all = +TapScript features to sign new testnet3 blocks.<br><br><div></div><div><div= + dir=3D"auto">sunday, 31 march 2024 at 15:24:34 UTC+2 Jameson Lopp wrote:<b= +r></div></div><div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-lef= +t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi all,<div= +><br></div><div>I'd like to open a discussion about testnet3 to put out= + some feelers on potential changes to it. First, a few facts:</div><div><br= +></div></div></blockquote></div><div><blockquote style=3D"margin:0px 0px 0p= +x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= +=3D"ltr"><div>1. Testnet3 has been running for 13 years. It's on block = +2.5 million something and the block reward is down to ~0.014 TBTC, so minin= +g is not doing a great job at distributing testnet coins any more.</div><di= +v><br></div></div></blockquote></div><div><blockquote style=3D"margin:0px 0= +px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div = +dir=3D"ltr"><div>2. The reason the block height is insanely high is due to = +a rather 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 q= +uirk:=C2=A0<a href=3D"https://blog.lopp.net/the-block-storms-of-bitcoins-te= +stnet/" rel=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"https://= +www.google.com/url?hl=3Den&q=3Dhttps://blog.lopp.net/the-block-storms-o= +f-bitcoins-testnet/&source=3Dgmail&ust=3D1712720933408000&usg= +=3DAOvVaw2uCW__gSAHd0PFcU4KUoJS">https://blog.lopp.net/the-block-storms-of-= +bitcoins-testnet/</a></div><div><br></div></div></blockquote></div><div><bl= +ockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20= +4,204);padding-left:1ex"><div dir=3D"ltr"><div>3. Testnet3 is being activel= +y used for scammy airdrops; those of us who tend to be generous with our te= +stnet coins are getting hounded by non-developers chasing cheap gains.</div= +><div><br></div></div></blockquote></div><div><blockquote style=3D"margin:0= +px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><= +div dir=3D"ltr"><div>4. As a result, TBTC is being actively bought and sold= +; one could argue that the fundamental principle of testnet=C2=A0coins havi= +ng no value has been broken.</div><div><br></div></div></blockquote></div><= +div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb= +(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>This leads me to pond= +er the following questions, for which I'm soliciting feedback.</div><di= +v><br></div></div></blockquote></div><div><blockquote style=3D"margin:0px 0= +px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div = +dir=3D"ltr"><div>1. Should we plan for a reset of testnet? If so, given how= + long it has been since the last reset and how many production systems will= + need to be updated, would a reset need to be done with a great deal of not= +ice?</div><div><br></div></div></blockquote></div><div><blockquote style=3D= +"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le= +ft:1ex"><div dir=3D"ltr"><div>2. Is there interest in fixing the difficulty= + reset bug? It should be a one liner fix, and I'd argue it could be don= +e sooner rather than later, and orthogonal to the network reset question. W= +ould such a change, which would technically be a hard fork (but also arguab= +ly a self resolving fork due to the difficulty dynamics) necessitate a BIP = +or could we just YOLO it?</div><div><br></div></div></blockquote></div><div= +><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20= +4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>3. Is all of the above a= + waste of time and we should instead deprecate testnet in favor of signet?<= +/div><div><br></div></div></blockquote></div><div><blockquote style=3D"marg= +in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= +x"><div dir=3D"ltr"><div>- Jameson</div></div> +</blockquote></div></blockquote></div> + +<p></p> + +-- <br /> +You received this message because you are subscribed to the Google Groups &= +quot;Bitcoin Development Mailing List" 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/83ec2b84-2255-4ac1-a40c-3f3a04a1c86fn%40googlegroups.= +com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg= +id/bitcoindev/83ec2b84-2255-4ac1-a40c-3f3a04a1c86fn%40googlegroups.com</a>.= +<br /> + +------=_Part_70131_335253175.1712636995753-- + +------=_Part_70130_94169278.1712636995753-- + |