diff options
| author | Garlo Nicon <garlonicon@gmail.com> | 2024-04-08 12:11:53 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-04-08 12:35:46 -0700 |
| commit | 6b0d00e53c1280780dd777c378c46b651139e929 (patch) | |
| tree | 623a8c67bc1db7f310e5eda0d8f3ca174c9cc0bb | |
| parent | e22ba6649d47d21adec40238ca3a3e84e5420522 (diff) | |
| download | pi-bitcoindev-6b0d00e53c1280780dd777c378c46b651139e929.tar.gz pi-bitcoindev-6b0d00e53c1280780dd777c378c46b651139e929.zip | |
[bitcoindev] Re: The Future of Bitcoin Testnet
| -rw-r--r-- | 7e/805d103e530190abbd685004072151d90d6102 | 365 |
1 files changed, 365 insertions, 0 deletions
diff --git a/7e/805d103e530190abbd685004072151d90d6102 b/7e/805d103e530190abbd685004072151d90d6102 new file mode 100644 index 000000000..f38241c67 --- /dev/null +++ b/7e/805d103e530190abbd685004072151d90d6102 @@ -0,0 +1,365 @@ +Delivery-date: Mon, 08 Apr 2024 12:35:46 -0700 +Received: from mail-yb1-f185.google.com ([209.85.219.185]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBCY3VBMZVAMRBCMO2GYAMGQEWIAUH6Y@googlegroups.com>) + id 1rtumP-0007Rb-E3 + for bitcoindev@gnusha.org; Mon, 08 Apr 2024 12:35:46 -0700 +Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-dcc4563611csf7132673276.3 + for <bitcoindev@gnusha.org>; Mon, 08 Apr 2024 12:35:44 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=googlegroups.com; s=20230601; t=1712604939; x=1713209739; 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=tPzXybpS1yq84sijidQEUZKsQWqpAGjeGcSLPrZivZs=; + b=O8g9KIaDatJsiEx8l6uVXBViJvV0CHVIS+2nDH8Vti30I+ND6Fb+ulkeXCmZ0MG83S + G1uuaNjhfjhc78RdEnQB9ItdtVRugKeSGFRfgYnq4eiKUOOT5+WNregJ2Pz/hnHqxU2N + km2p1VZDuji8o08ZEGQRR43eJqXbrgSOLuP5IhNz8aF6c2R+7pgVJSzXUOP/YvUUwSAn + muxfmS3D3v/WLlpMRJcC8TBXMZzrkcLPwzqr8aFAuYEA9YzFY1kOv6X7oXosslM868z4 + m0SZzhwVpvydNl2bwHOn8NN4rcyjvAgPZZq5KNPMBQDZrxMgugaqAEv2PsppD/mvgl9s + ILoQ== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1712604939; x=1713209739; 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=tPzXybpS1yq84sijidQEUZKsQWqpAGjeGcSLPrZivZs=; + b=cLXwud3lMVsdP/USkaU1WIhrWQ5iixmfBn93MgfGKzpuPaBYVHFLhJtFox/EbPXA/N + BOycE2W00RMJZYG+W2DqRrfWe+tmaq2evdp7UrVgoWZXSJSpg6/cIKUfplo4iLug1XYu + lIbfCt/1709GqP6JMoNsvpRvp/Sq1HdSbFgO3SA2RLnfy8MglXH5jcdXLX9gXPXvPY/d + IwQOIOltTblMNzE6wNR5DH11z/4hNtFTHcNjxYZvlHqxyqHADWwNaYdsRZ5L1RbLkIqO + eZFhSpE+Y7+pmXGLJYBePu9JDsNigrzgrl6oDbu5Zm1yU4PAnLemhdNbJZopc7TEvZiO + 5hIQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1712604939; x=1713209739; + 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=tPzXybpS1yq84sijidQEUZKsQWqpAGjeGcSLPrZivZs=; + b=rW7nZMRt7FmsdymTRkHhGqzEdy8rof19c9Kt4tc3xx8k8z8l2K3ADNU94G44lDp4yG + EHuZ/pto9N4olObf2wuhitsLMHc7sgNiQ8sdpGPsVBsrl4rauChp0avD+MaCIiGXurRL + IiOMiChWBEQEHECbyU9bBgT6gXgQd4D/M56tB8IbQ2vcoJBGf9ff6v2NUXvxrZHUIoQL + Gg6I/Dn6VGe4xBuKsos8DRlWsBPKECd+zVNSEk88+evX/afRrBl/AWA1tTV+7/nU76HZ + nKQBTDhWyRtnB8IPNJVBqHCOr5GXDkQwGUyV0Yaa0fQ2/dK7K0IKgg/V5zf2b+FyxhKG + g4+Q== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=1; AJvYcCVkWLILrzlqx33Th8th2olWnZSpLKL5RCCG+p1p6L616khCuCDiX+ygi1Dj1R5qseMwHGbwqeOkQUKi1HpuvcXUQvVP7jc= +X-Gm-Message-State: AOJu0YwLkr3ji6oPGtwRnTV4CC9Mb7Zdglq/2USiopqJ1gA4hCqReysI + 0t09W0Yyb4dECr0TYEOheTWE+4snfMcbo1+hZ+EjrwV7z4Fxo6Es +X-Google-Smtp-Source: AGHT+IGbm4Y9rX5T7+poARTq0gtqOsgB4ckhqj2duqy+ZRdN2SuhIASbcstmmM7sVvJ6kHNEWz0s1w== +X-Received: by 2002:a25:bc90:0:b0:dca:e4fd:b6d5 with SMTP id e16-20020a25bc90000000b00dcae4fdb6d5mr7468388ybk.27.1712604938719; + Mon, 08 Apr 2024 12:35:38 -0700 (PDT) +X-BeenThere: bitcoindev@googlegroups.com +Received: by 2002:a25:af04:0:b0:dcc:37ed:efb1 with SMTP id a4-20020a25af04000000b00dcc37edefb1ls604314ybh.2.-pod-prod-00-us; + Mon, 08 Apr 2024 12:35:37 -0700 (PDT) +X-Received: by 2002:a81:a002:0:b0:615:dd:de98 with SMTP id x2-20020a81a002000000b0061500ddde98mr109781ywg.5.1712604937536; + Mon, 08 Apr 2024 12:35:37 -0700 (PDT) +Received: by 2002:a05:690c:f86:b0:611:9f18:9d1 with SMTP id 00721157ae682-617c7f8b151ms7b3; + Mon, 8 Apr 2024 12:11:54 -0700 (PDT) +X-Received: by 2002:a05:6902:1245:b0:dda:c566:dadd with SMTP id t5-20020a056902124500b00ddac566daddmr765323ybu.4.1712603513908; + Mon, 08 Apr 2024 12:11:53 -0700 (PDT) +Date: Mon, 8 Apr 2024 12:11:53 -0700 (PDT) +From: Garlo Nicon <garlonicon@gmail.com> +To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +Message-Id: <6733b634-e6da-4bb3-a3b6-bffa41395e9cn@googlegroups.com> +In-Reply-To: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com> +References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com> +Subject: [bitcoindev] Re: The Future of Bitcoin Testnet +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="----=_Part_314_918224809.1712603513534" +X-Original-Sender: garlonicon@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_314_918224809.1712603513534 +Content-Type: multipart/alternative; + boundary="----=_Part_315_1786026393.1712603513534" + +------=_Part_315_1786026393.1712603513534 +Content-Type: text/plain; charset="UTF-8" + +> so mining is not doing a great job at distributing testnet coins any more + +It is a feature, not a bug. Would people want to reset Bitcoin main network +in the future, for exactly the same reasons? Or would they want to +introduce "tail supply", or other similar inventions, to provide sufficient +incentive for miners? This testnet3 is unique, because it has quite low +block reward. And that particular feature should be preserved, even if the +network would be resetted (for example, it could be "after 12 halvings, but +where all previous coins were burned"). And not, it is not the same as +starting from 50 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"). + +> a rather amusing edge case bug that causes the difficulty to regularly +get reset to 1 + +It can be fixed in a soft-fork way, no network reset is needed to achieve +that. Because if there is a block number 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, increasing difficulty is a +soft-fork. For example, if someone would enforce testnet difficulty on +regtest, it would be perfectly valid. All that is needed, is just rejecting +more block hashes, so even if all fields are left unchanged, the old client +could see, that the 32-bit difficulty field says "minimal", but produced +blocks are not accepted, and "the true difficulty" is put anywhere else, +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", +so they are never "worthless". Pointing at some chain, and saying "this +should be worthless" is not enough to make it. There are no consensus rules +to ensure that test coins are truly worthless. There is no "automatic +reset", or any "demurrage". If large amounts of coins are misused, then +that misuse can be stopped, by burning coins, or invalidating them in any +other way, 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 +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 +existing chain", but just by "fixing errors one-by-one". For example, +fixing blockstorms as a soft-fork would be a good starting point. And in +practice, it may turn out, that 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. + +> 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 notice? + +No additional "notice" would be needed, if every "fix" would be a +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 in +block versions. Also, as with every other soft-fork, it would have +additional advantage, that if someone would want to locally test +"blockstorms", then that person would be able to locally 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 disable that +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 +"old blocks are invalid in a new version" (they don't meet increased +difficulty), but also "new blocks are valid in an old version" (they meet +the old difficulty, exactly as the mainnet Genesis Block with 40 leading +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=0". Then, +some miners could 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 the majority would simply reject blockstorms in a +soft-fork way. I think it is not that important to make a BIP, unless you +really want to get through the whole process. + +> Is all of the above a waste of time and we should instead deprecate +testnet in favor of signet? + +This scenario is also possible, but probably not in the way you think. +Transition from testnet into signet is a perfect soft-fork. If you decide, +that since block number N, all blocks should be signed with "signet +challenge", then it would lead to a natural conversion from permissionless +mining into permissioned mining. You can implement it, and start with +OP_TRUE, to test, if everything 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. + +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 +potential changes to it. First, a few facts: + +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 mining is not +doing a great job at distributing testnet coins any more. + +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 quirk: +https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/ + +3. 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-developers chasing cheap gains. + +4. 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. + +This leads me to ponder the following questions, for which I'm soliciting +feedback. + +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 notice? + +2. Is there interest in fixing the difficulty reset bug? It should be a one +liner fix, and I'd argue it could be done sooner rather than later, and +orthogonal to the network reset question. Would such a change, which would +technically be a hard fork (but also arguably a self resolving fork due to +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 +testnet in favor of signet? + +- Jameson + +-- +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/msgid/bitcoindev/6733b634-e6da-4bb3-a3b6-bffa41395e9cn%40googlegroups.com. + +------=_Part_315_1786026393.1712603513534 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +> so mining is not doing a great job at distributing testnet coins any m= +ore<br /><br />It is a feature, not a bug. Would people want to reset Bitco= +in main network in the future, for exactly the same reasons? Or would they = +want to introduce "tail supply", or other similar inventions, to provide su= +fficient incentive for miners? This testnet3 is unique, because it has quit= +e low block reward. And that particular feature should be preserved, even i= +f the network would be resetted (for example, it could be "after 12 halving= +s, but where all previous coins were burned"). And not, it is not the same = +as starting from 50 tBTC, as long as fee rates are left unchanged (and 0.01= +4 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 feerat= +e").<br /><br />> a rather amusing edge case bug that causes the difficu= +lty to regularly get reset to 1<br /><br />It can be fixed in a soft-fork w= +ay, no network reset is needed to achieve that. Because if there is a block= + number X, and it could have minimal difficulty, under the current rules, t= +hen it is possible to reject it, and enforce the higher difficulty. In gene= +ral, increasing difficulty is a soft-fork. For example, if someone would en= +force testnet difficulty on regtest, it would be perfectly valid. All that = +is needed, is just rejecting more block hashes, so even if all fields are l= +eft unchanged, the old client could see, that the 32-bit difficulty field s= +ays "minimal", but produced blocks are not accepted, and "the true difficul= +ty" is put anywhere else, for example just after the block number in the co= +inbase transaction.<br /><br />> Testnet3 is being actively used for sca= +mmy airdrops<br /><br />This is because mining is costly, and because coins= + are never "resetted", so they are never "worthless". Pointing at some chai= +n, and saying "this should be worthless" is not enough to make it. There ar= +e no consensus rules to ensure that test coins are truly worthless. There i= +s no "automatic reset", or any "demurrage". If large amounts of coins are m= +isused, then that misuse can be stopped, by burning coins, or invalidating = +them in any other way, for example "the coin is unspendable, if it was crea= +ted during the previous halving". As long as there are no such rules, reset= +ting the network won't help in the long term, so something new is needed, t= +o discourage 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 m= +aybe not by "throwing away the whole existing chain", but just by "fixing e= +rrors one-by-one". For example, fixing blockstorms as a soft-fork would be = +a good starting point. And in practice, it may turn out, that all fixes cou= +ld 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, give= +n 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 o= +f notice?<br /><br />No additional "notice" would be needed, 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 difficulty reset bug?<br /= +><br />Yes. But because it could be a soft-fork, miners could signal readin= +ess in block versions. Also, as with every other soft-fork, it would have a= +dditional advantage, that if someone would want to locally test "blockstorm= +s", then that person would be able to locally create a chain, where that pa= +rticular soft-fork would be inactive. Which means, that it would be still p= +ossible, to download the new chain, and disable that soft-fork locally, if = +someone would need it.<br /><br />> Would such a change, which would tec= +hnically be a hard fork<br /><br />It would be a soft-fork. Each difficulty= + increase is a soft-fork, because "old blocks are invalid in a new version"= + (they don't meet increased difficulty), but also "new blocks are valid in = +an old version" (they meet the old difficulty, exactly as the mainnet Genes= +is Block with 40 leading zero bits meets the required difficulty with 32 le= +ading zeroes).<br /><br />> necessitate a BIP or could we just YOLO it?<= +br /><br />Well, it is possible to just add some flag, like "-blockstorm=3D= +0". Then, some miners could activate it, just like they activated full-RBF.= + And if the majority would want to get rid of blockstorms, then it would ju= +st happen naturally, if the majority would simply reject blockstorms in a s= +oft-fork way. I think it is not that important to make a BIP, unless you re= +ally want to get through the whole process.<br /><br />> Is all of the a= +bove a waste of time and we should instead deprecate testnet in favor of si= +gnet?<br /><br />This scenario is also possible, but probably not in the wa= +y you think. Transition from testnet into signet is a perfect soft-fork. If= + you decide, that since block number N, all blocks should be signed with "s= +ignet challenge", then it would lead to a natural conversion from permissio= +nless mining into permissioned mining. You can implement it, and start with= + OP_TRUE, to test, if everything is working correctly. And then, you can ap= +ply for example "OP_1 <taproot_address>" as the signet challenge, and= + then use all TapScript features to sign new testnet3 blocks.<br /><br /><d= +iv><div dir=3D"auto">sunday, 31 march 2024 at 15:24:34 UTC+2 Jameson Lopp w= +rote:<br /></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 al= +l,<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>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>2. The reason the block height is insanely high is due t= +o a rather amusing edge case bug that causes the difficulty to regularly ge= +t reset to 1, which causes a bit of havoc. If you want a deep dive into the= + quirk:=C2=A0<a href=3D"https://blog.lopp.net/the-block-storms-of-bitcoins-= +testnet/" target=3D"_blank" rel=3D"nofollow">https://blog.lopp.net/the-bloc= +k-storms-of-bitcoins-testnet/</a></div><div><br /></div><div>3. Testnet3 is= + being actively used for scammy airdrops; those of us who tend to be genero= +us with our testnet coins are getting hounded by non-developers chasing che= +ap gains.</div><div><br /></div><div>4. As a result, TBTC is being actively= + bought and sold; one could argue that the fundamental principle of testnet= +=C2=A0coins having no value has been broken.</div><div><br /></div><div>Thi= +s leads me to ponder the following questions, for which I'm soliciting feed= +back.</div><div><br /></div><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 product= +ion systems will need to be updated, would a reset need to be done with a g= +reat deal of notice?</div><div><br /></div><div>2. Is there interest in fix= +ing the difficulty reset bug? It should be a one liner fix, and I'd argue i= +t could be done sooner rather than later, and orthogonal to the network res= +et question. Would such a change, which would technically be a hard fork (b= +ut also arguably a self resolving fork due to the difficulty dynamics) nece= +ssitate a BIP or could we just YOLO it?</div><div><br /></div><div>3. Is al= +l of the above a waste of time and we should instead deprecate testnet in f= +avor of signet?</div><div><br /></div><div>- Jameson</div></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/6733b634-e6da-4bb3-a3b6-bffa41395e9cn%40googlegroups.= +com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg= +id/bitcoindev/6733b634-e6da-4bb3-a3b6-bffa41395e9cn%40googlegroups.com</a>.= +<br /> + +------=_Part_315_1786026393.1712603513534-- + +------=_Part_314_918224809.1712603513534-- + |