path: root/f8/07e5b9f756716a6fc9fcf23425ddf820b51703

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;">&gt; 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 &quot;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 &quot;after 12 halvings, but where all previo=
us coins were burned&quot;). 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 &quot=
;the ability to push around 1.4 MB of data, with feerate of 1 sat/vB&quot;,=
 instead of 50 tBTC, which means &quot;pushing 5 GB with the same feerate&q=
uot;).<br><br>&gt; 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&quot;, but produced blocks are not accepted, and &quot;the true=
 difficulty&quot; is put anywhere else, for example just after the block nu=
mber in the coinbase transaction.<br><br>&gt; Testnet3 is being actively us=
ed for scammy airdrops<br><br>This is because mining is costly, and because=
 coins are never &quot;resetted&quot;, so they are never &quot;worthless&qu=
ot;. Pointing at some chain, and saying &quot;this should be worthless&quot=
; is not enough to make it. There are no consensus rules to ensure that tes=
t coins are truly worthless. There is no &quot;automatic reset&quot;, or an=
y &quot;demurrage&quot;. 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 &quot;the coin is unspendable, if it was created during the=
 previous halving&quot;. As long as there are no such rules, resetting the =
network won&#39;t help in the long term, so something new is needed, to dis=
courage assigning any value into test coins.<br><br>&gt; Should we plan for=
 a reset of testnet?<br><br>I guess the answer is &quot;yes&quot;, but mayb=
e not by &quot;throwing away the whole existing chain&quot;, but just by &q=
uot;fixing errors one-by-one&quot;. 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>&gt=
; 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 &quot;notice&quot; would be nee=
ded, if every &quot;fix&quot; would be a soft-fork, and if all old clients =
would follow all new changes.<br><br>&gt; 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 &quot;blockstorms&quot;, 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>&gt; 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 &quot;old blocks a=
re invalid in a new version&quot; (they don&#39;t meet increased difficulty=
), but also &quot;new blocks are valid in an old version&quot; (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>&gt; n=
ecessitate a BIP or could we just YOLO it?<br><br>Well, it is possible to j=
ust add some flag, like &quot;-blockstorm=3D0&quot;. 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>&gt; 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 &quot;signet challenge&quot;, 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 &quot;OP=
_1 &lt;taproot_address&gt;&quot; 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&#39;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&#39;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&amp;q=3Dhttps://blog.lopp.net/the-block-storms-o=
f-bitcoins-testnet/&amp;source=3Dgmail&amp;ust=3D1712720933408000&amp;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&#39;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&#39;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&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/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--