From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 09 Apr 2024 14:53:01 -0700 Received: from mail-yw1-f185.google.com ([209.85.128.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ruJOm-0005QI-CW for bitcoindev@gnusha.org; Tue, 09 Apr 2024 14:53:01 -0700 Received: by mail-yw1-f185.google.com with SMTP id 00721157ae682-618409ab1acsf5396687b3.3 for ; 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=1712699573; x=1713304373; 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=gMBAyigvuVpMf+21zmiC+EbWHmD81NqmYIK1j4rWIbo=; b=eJNqmfWSPN8k2n/qsko2ZJ6iMo7qxvcIh6DIMB1rbSQA8YxApHXUfj4rYvz+/Gpx5q GbGWTjXq0qT2OuUkfZ1tQ46xaIMq74NS8hSQJAazeSiAIZdf86HuU4BX4Wq8wMdEfCAR VKX0uhwfV4tN2xaspdHt0i5hsb/LBJcNSyzDHQLOyTu/i9LYWkRoBmRlCSnfI8WNaNJi 8NUOTMt+jHmqKtRuWZJBNVBWjd8bZ85Vk4/oLGxXliuwlrXNEIiRn43hKaz4Kj5Nf/HM 0IHjSVVl3wCTMxyaD6odNmAHz6AZ42aWrck+txPXD4lQx9VSsyv3gH6561km/fiGk4dU utEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712699573; x=1713304373; 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=gMBAyigvuVpMf+21zmiC+EbWHmD81NqmYIK1j4rWIbo=; b=iEf4t6SNJqTD/Qi+KmFoDnCBVhqE44JqH4DcL60TU0b1qjFU2yXENqXPRJY+MEim3/ KYgTaH8AsctDpWZFXsA6y0pxjb0FwTYHvw5hv09HJ+O9tWKS1U36Yb+KbF9Aa5PISsMp mqBlrUE2iig+7fK2mxRmGPPXUCTaXzZnZmzzqrdlFNFRU6FRhmLWOR+yGO4Y6WPPjIue 0Y85Z6vq9Dw9sOVNEuh2pYAUAZ9/pPkulAQ9ej4J2XYwlXjTGGGNYCIFvZJDagR5CCLp xcDShQNyBYeghcUG37r+R+ziPYNsA/gkHM1m1K9QOBA011laEp4DBuz3fchUvmqvRSvT XebQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712699573; x=1713304373; 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=gMBAyigvuVpMf+21zmiC+EbWHmD81NqmYIK1j4rWIbo=; b=W8gGNWuZDmAZVurPKsXmmDqWaqUPsSaMs3FbnKFhZDm/N+dso/e37BXccSSif0OoLW l28gB4g1dAddpeb6ACxwMiRYrtjxZJNypanazH3xFHobSLdf4OMGDs6N3rVjohIKAD+P RfXg5vIWH+S80uQnghm4lbATk/8ZYlzmet9ikh66Gx4H5EVATp62NQJPscpKWjEbLnrC QYleYV54KwYyGHRmQcJLqhTECZbU7PodyVOh6RLxXYEgCbKkoxjGQSeZ6nEjnFJtRrDt j3lEdQxT55VArFoY5+xu1agko2vi4r3Rv6qbnOnfnlTKnPdDnYV584x26Ihj9ngdNckW YXqg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVtchxeBpKjhTveEer6LLTvWdzvXpIgezP69UT4NZV04crCdZsA6DtRiFuW7XKfD1pw637jL7y4CjY1w9sYgU+MvJBOnO0= X-Gm-Message-State: AOJu0Yxj3M4sIC9+GYngOJzD5AfAMLPafUKtag2sy0tBXxivg+UqabJY lefLVdAU41qCZIchYdDIv7t695Yu9At6JsddKhSVgGoSy1TguaTt X-Google-Smtp-Source: AGHT+IE5bl//l/tLmbSydhcKPKfDMLseQZu6umXFREtV/kEFffmKfVZ8+G93Lm0/oK6QPbsIP+2KbQ== X-Received: by 2002:a25:6412:0:b0:de1:849:a6f3 with SMTP id y18-20020a256412000000b00de10849a6f3mr1084349ybb.7.1712699573443; Tue, 09 Apr 2024 14:52:53 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:3506:0:b0:dcc:4b24:c0de with SMTP id c6-20020a253506000000b00dcc4b24c0dels1619223yba.0.-pod-prod-00-us; Tue, 09 Apr 2024 14:52:52 -0700 (PDT) X-Received: by 2002:a05:6902:c04:b0:dda:c4ec:7db5 with SMTP id fs4-20020a0569020c0400b00ddac4ec7db5mr244285ybb.4.1712699572205; Tue, 09 Apr 2024 14:52:52 -0700 (PDT) Received: by 2002:a05:690c:fd6:b0:615:6ba5:7389 with SMTP id 00721157ae682-61841905691ms7b3; Tue, 9 Apr 2024 11:28:05 -0700 (PDT) X-Received: by 2002:a25:add4:0:b0:dd9:3a6b:11f8 with SMTP id d20-20020a25add4000000b00dd93a6b11f8mr148184ybe.5.1712687283005; Tue, 09 Apr 2024 11:28:03 -0700 (PDT) Date: Tue, 9 Apr 2024 11:28:02 -0700 (PDT) From: Garlo Nicon To: Bitcoin Development Mailing List Message-Id: <7c2a3be7-ebea-4ea3-abea-93ff8ebe0d42n@googlegroups.com> In-Reply-To: <8c6e98ff-bdec-4955-8132-bd93af2d40dd@dashjr.org> References: <8c6e98ff-bdec-4955-8132-bd93af2d40dd@dashjr.org> Subject: Re: [bitcoindev] The Future of Bitcoin Testnet MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4810_433266223.1712687282627" X-Original-Sender: garlonicon@gmail.com 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: -0.5 (/) ------=_Part_4810_433266223.1712687282627 Content-Type: multipart/alternative; boundary="----=_Part_4811_1735188972.1712687282627" ------=_Part_4811_1735188972.1712687282627 Content-Type: text/plain; charset="UTF-8" > Is the difficulty reset bug actually a bug, or a feature? Both. It is a bug, because it makes things unstable. However, it is also a feature, because it allows us to quickly reach a lot of halvings, and test a situation, where basic block reward is small, and where getting new coins is very difficult, because you have to get them from the current owners. > If it's a bug, couldn't we just fix it and let the blockchain reorg on its own? But there is no need to "reorg" things. If you have 1,5 M blocks, then it is not a problem, that in 2015, there was a blockstorm somewhere. The only problem is if you create some transaction, and see that kind of blockstorm here and now, when you put some timelock on your transaction, or when 100 confirmations are not enough, because it is covered with a very little Proof of Work, and was mined in a minute. Which also means, that fixing previous blockstorms is not that important. Fixing the current ones is more urgent, because if you would see, that since for example block 1,8 M, there will be no blockstorms, then that network will become stable. The only "fix" into previous blockstorms, could be related to the amounts, which were mined during those blockstorms. But then, it is all about "demurrage", or any other penalty, and it does not require erasing past blocks from the history. Those blocks could still be present in the chain of previous block hashes inside block headers. The only question is about throwing away coins from the UTXO set, or turning them into fees for the future blocks. But there is no need to overwrite the history to fix things. > Signet is definitely not a replacement for testnet. I wonder, what people think about merging signet and testnet into a single chain? For example: imagine if signet would be entirely stored on testnet3, but just some blocks would be signed with that "signet challenge", some would be signed with another, and some would be not signed at all. Then, you could scan the whole testnet3, pick some "signet challenge", and your UTXO set would contain only coins from the test network, which you want to observe. And then, everyone could do some "network reset", just by switching the signet challenge, and rebuilding the database. Another interesting model, is making a network, where mainnet and testnet blocks are visible in the same timeline. Then, to make some new test coins, you would just sign some mainnet coins. And to destroy them, you just burn them, or move them in the main network in any way, so they are no longer pegged, and are skipped during Initial Blockchain Download in the test network. > If we fix the difficulty reset bug, we might as well also fix the coin supply issue: get rid of the halving for testnet and just make every block create new coins. To solve the problem of getting the new test coins, people would need to realize the truth: testnet coins are supposed to be worthless. Which means, that performing all tests with zero satoshis should be fine, right? So, why those non-zero amounts are needed? Of course as a protection from spam. Which also means, that if someone has no coins, then we could allow including a transaction, if it provides some Proof of Work instead, right? Because if you have 0.01 tBTC, then what does it mean? It is not something, which should be converted into BTC. It is worthless. However, it is used to express "data pushing ability". It simply means, that if your transaction fee is 1 sat/vB, then you can push 1 MB publicly, and reveal your test cases, so other users can see them. But if instead of including transaction fee, users would share some Proof of Work, then the protocol could allow them to include their tests for free (or just cheaper than usual), because they did some work, so we could reward them accordingly to the hashes they found. By the way, even if we run out of coins, then there are still cases, where producing new blocks with zero reward makes sense, because it affects locktimes, the difficulty, and the whole Script is still followed to the letter, so all kinds of contracts are still executed (and for example timestamping a document in some Proof of Work chain may be worthy, even if the miner didn't earn any new coins by doing so). Another use case is unlocking some previously mined coinbase transaction, because even a new block with no reward, still counts as an additional confirmation. sunday, 31 march 2024 at 18:24:37 UTC+2 Luke Dashjr wrote: Is the difficulty reset bug actually a bug, or a feature? If it's a bug, couldn't we just fix it and let the blockchain reorg on its own? Signet is definitely not a replacement for testnet. Luke On 3/31/24 09:19, 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+...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw%40mail.gmail.com . -- 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/7c2a3be7-ebea-4ea3-abea-93ff8ebe0d42n%40googlegroups.com. ------=_Part_4811_1735188972.1712687282627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Is the difficulty reset bug actually a bug, or a feature?

B= oth. It is a bug, because it makes things unstable. However, it is also a f= eature, because it allows us to quickly reach a lot of halvings, and test a= situation, where basic block reward is small, and where getting new coins = is very difficult, because you have to get them from the current owners.
> If it's a bug, couldn't we just fix it and let the blockchain= reorg on its own?

But there is no need to "reorg" things. If yo= u have 1,5 M blocks, then it is not a problem, that in 2015, there was a bl= ockstorm somewhere. The only problem is if you create some transaction, and= see that kind of blockstorm here and now, when you put some timelock on yo= ur transaction, or when 100 confirmations are not enough, because it is cov= ered with a very little Proof of Work, and was mined in a minute.

Which also means, that fixing previous blockstorms is not that important.= Fixing the current ones is more urgent, because if you would see, that sin= ce for example block 1,8 M, there will be no blockstorms, then that network= will become stable.

The only "fix" into previous blockstorms, c= ould be related to the amounts, which were mined during those blockstorms. = But then, it is all about "demurrage", or any other penalty, and it does no= t require erasing past blocks from the history. Those blocks could still be= present in the chain of previous block hashes inside block headers. The on= ly question is about throwing away coins from the UTXO set, or turning them= into fees for the future blocks. But there is no need to overwrite the his= tory to fix things.

> Signet is definitely not a replacement = for testnet.

I wonder, what people think about merging signet an= d testnet into a single chain? For example: imagine if signet would be enti= rely stored on testnet3, but just some blocks would be signed with that "si= gnet challenge", some would be signed with another, and some would be not s= igned at all. Then, you could scan the whole testnet3, pick some "signet ch= allenge", and your UTXO set would contain only coins from the test network,= which you want to observe. And then, everyone could do some "network reset= ", just by switching the signet challenge, and rebuilding the database.

Another interesting model, is making a network, where mainnet and t= estnet blocks are visible in the same timeline. Then, to make some new test= coins, you would just sign some mainnet coins. And to destroy them, you ju= st burn them, or move them in the main network in any way, so they are no l= onger pegged, and are skipped during Initial Blockchain Download in the tes= t network.

> If we fix the difficulty reset bug, we might as = well also fix the coin supply issue: get rid of the halving for testnet and= just make every block create new coins.

To solve the problem of= getting the new test coins, people would need to realize the truth: testne= t coins are supposed to be worthless. Which means, that performing all test= s with zero satoshis should be fine, right? So, why those non-zero amounts = are needed? Of course as a protection from spam. Which also means, that if = someone has no coins, then we could allow including a transaction, if it pr= ovides some Proof of Work instead, right?

Because if you have 0.= 01 tBTC, then what does it mean? It is not something, which should be conve= rted into BTC. It is worthless. However, it is used to express "data pushin= g ability". It simply means, that if your transaction fee is 1 sat/vB, then= you can push 1 MB publicly, and reveal your test cases, so other users can= see them. But if instead of including transaction fee, users would share s= ome Proof of Work, then the protocol could allow them to include their test= s for free (or just cheaper than usual), because they did some work, so we = could reward them accordingly to the hashes they found.

By the w= ay, even if we run out of coins, then there are still cases, where producin= g new blocks with zero reward makes sense, because it affects locktimes, th= e difficulty, and the whole Script is still followed to the letter, so all = kinds of contracts are still executed (and for example timestamping a docum= ent in some Proof of Work chain may be worthy, even if the miner didn't ear= n any new coins by doing so). Another use case is unlocking some previously= mined coinbase transaction, because even a new block with no reward, still= counts as an additional confirmation.

su= nday, 31 march 2024 at 18:24:37 UTC+2 Luke Dashjr wrote:
=20 =20 =20

Is the difficulty reset bug actually a bug, or a feature?

If it's a bug, couldn't we just fix it and let the blockchain reorg on its own?

Signet is definitely not a replacement for testnet.

Luke


On 3/31/24 09:19, 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:=C2=A0https://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=C2=A0coins 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+...@googleg= roups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CADL= _X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw%40mail.gmail.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/msg= id/bitcoindev/7c2a3be7-ebea-4ea3-abea-93ff8ebe0d42n%40googlegroups.com.=
------=_Part_4811_1735188972.1712687282627-- ------=_Part_4810_433266223.1712687282627--