The Future of Bitcoin Testnet

[Jameson Lopp]

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

[Luke Dashjr]

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

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

[Jameson Lopp]

On Sun, Mar 31, 2024 at 10:33 AM Luke Dashjr <lu...@dashjr.org> wrote:

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

I haven't thought of or heard of any good reason why it's helpful to have a dozen blocks per second flood the network for several days every time the edge case gets hit. 

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

I believe so. Upon closer inspection I think it's actually a soft forkable fix if all we do is restrict the special testnet minimum difficulty rule so that it can't be triggered on the block right before a difficulty retarget. 

[Peter Todd]

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.

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[Eric Voskuil]

On Mar 31, 2024, at 12:24, Jameson Lopp <jameso...@gmail.com> wrote:

On Sun, Mar 31, 2024 at 10:33 AM Luke Dashjr <lu...@dashjr.org> wrote:

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

I haven't thought of or heard of any good reason why it's helpful to have a dozen blocks per second flood the network for several days every time the edge case gets hit. 

Apart from the genesis block and fork activation points (data), easy blocks is the only line of code (logic) that distinguishes testnet3 from bitcoin.

I have always assumed it’s a feature intended to keep it very easy to produce blocks with the side effect of limiting monetary utility and preserving most of the adjustment logic.

If it’s eliminated there presumably must be some other change to produce those intended results. However it would be important to consider not only all of the dependencies that may be built up upon it, but also that the more it deviates from bitcoin the less useful it becomes for testing bitcoin.

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

I believe so. Upon closer inspection I think it's actually a soft forkable fix if all we do is restrict the special testnet minimum difficulty rule so that it can't be triggered on the block right before a difficulty retarget. 

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_eZ3uDU7PPh11rn2NSGwvRMjjZ3Auu6eVVQoJU78%2BaRxQ%40mail.gmail.com.

[Nagaev Boris]

If such a change is made, then such a network won't be suitable to
test halvings and software behaviour related to halvings.

>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

> --
> 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/ZgmJFfXnQddkTQVq%40petertodd.org.



--
Best regards,
Boris Nagaev

[Peter Todd]

On Sun, Mar 31, 2024 at 06:01:51PM -0300, Nagaev Boris wrote:
> > 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.
>
> If such a change is made, then such a network won't be suitable to
> test halvings and software behaviour related to halvings.

I don't think that's very important. That's a very small part of what testnet
is used for, and nothing stops people from using, say, regtest for that kind of
testing. We already changed important consensus code around difficulty with
testnet-specific behavior.

[Jameson Lopp]

It sounds like folks think testnet is useful enough to continue maintaining.

I think it's a fair point that testnet should strive to be as similar to mainnet as possible. If we fix the difficulty reset edge case then that will arguably make testnet EVEN MORE like mainnet by removing the "block storm" phenomenon.

Changing the supply schedule is an interesting proposal, though I'd counter that fixing the difficulty reset will naturally make the supply schedule more evenly distributed over time, plus we can hopefully move toward resetting the network before long. I'd be slightly worried about changing consensus rules on testnet that deviate significantly from mainnet because I bet there are plenty of systems running that validate that rule or make assumptions that it's the same as mainnet, and deploying such a change could cause far more grief for the developer ecosystem.

[Andrew Poelstra]

On Sun, Mar 31, 2024 at 09:19:50AM -0400, Jameson Lopp wrote:
>

> 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/
>

The purpose of this is to avoid situations where a single miner drives
the difficulty way up and then drops off, leaving the other testnet
miners unable to produce blocks. In the early CPU->GPU->FPGA->ASIC days
it could happen that there was only one person with an ASIC who would
have literally a 1000x advantage over other miners (since miner costs
money and nobody gets paid).

Nowadays we can probably assume that anyone who cares to mine testnet
can scrounge up a couple used S9s or something, so for a griefer to
obtain a 1000x advantage like this would require a serious cash
investment. So maybe it's okay to drop the rule entirely.

But I would propose weakening it -- requiring no blocks for a longer
period of time and resetting the difficulty to something (much) higher
than 1. Or just dropping the difficulty by a fixed factor of 128 or
something (though we'd need extra logic to avoid this being done
repeatedly to drive the difficulty to 1 anyway, maybe) so we don't
need to guess at a reasonable floor.

Obviously this is a major bikeshedding vector but hopefully people don't
get too enthusiastic about particular values here. Just pick something
and run with it.

Anyway ACK resetting testnet if people are valuing its coins. I recall
a long time ago this was (in some sense I don't remember) an official
condition under which testnet was supposed to be reset.


--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew

The sun is always shining in space
-Justin Lewis-Webster

[Fabian]

Hi all,

I second that Signet is not a replacement for Testnet.

Softforking in the fix is definitely possible and worth considering if too many projects complain about the hassle of changing to a testnet4. However, this alone doesn't help with any of the other issues OP mentioned.

Getting rid of the halving for testnet3 doesn't seem like a good idea to me since this would mean all projects that have some kind of unintended inflation detection would need to add exceptions. This seems like a much larger engineering effort than simply switching to a testnet4. Beyond that, I agree with previous posters that there is value in keeping testnet as close to mainnet as possible. Also, we would be locking in an already very low subsidy in testnet3.

So far, I think the reset together with a fix for the difficulty adjustment is the best solution and hopefully discourages scammers from building on Bitcoin testnets. Maybe we should even get into the habit and just reset with every halving. FWIW, I have created a draft PR with a difficulty adjustment fix and some initial work for a testnet4: https://github.com/bitcoin/bitcoin/pull/29775

Side note: I think one of the main causes for the insufficient distribution of testnet/signet coins is that building and running a faucet that works as intended robustly, withstands attacks etc. is a very hard problem. If we had such a system that just works (TM) and will be maintained long-term, I think there would be more people willing to donate their testnet coins to such a system. Maybe this is a project worthy of some OS funding.

Best,
Fabian

> --
> 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/Zgq12xgPpyD9ie0L%40camus.

[Pieter Wuille]

On Monday, April 1st, 2024 at 8:54 AM, Jameson Lopp <jameso...@gmail.com> wrote:

> It sounds like folks think testnet is useful enough to continue maintaining.
> I think it's a fair point that testnet should strive to be as similar to mainnet as possible. If we fix the difficulty reset edge case then that will arguably make testnet EVEN MORE like mainnet by removing the "block storm" phenomenon.

Agreed on both points. Signet is useful, but it is probably not the right solution for everything. And testnet has been reset before, it shouldn't be a big deal to reset it again.

> Changing the supply schedule is an interesting proposal, though I'd counter that fixing the difficulty reset will naturally make the supply schedule more evenly distributed over time, plus we can hopefully move toward resetting the network before long. I'd be slightly worried about changing consensus rules on testnet that deviate significantly from mainnet because I bet there are plenty of systems running that validate that rule or make assumptions that it's the same as mainnet, and deploying such a change could cause far more grief for the developer ecosystem.

I think there is an easier alternative to changing the supply rule: the intention to reset it again when its subsidy drops too low. That may even also counteract the development of a non-zero market price for the coins.

As for using other measures to prevent too large difficulty variations... I'm not sure that's desirable, because it always cuts both ways (nicely demonstrated by the "allow difficulty 1 rule" on testnet3 backfiring and enabling block storms!). For applications that actually need very predictable block rate, there is signet. For others, just the normal mainnet rules are probably not too terrible. I would be ok with having a somewhat reduced block interval (say a few days instead of 2 weeks) if that's not deemed to complex to implement across the ecosystem, but I don't think it's that important.

--
Pieter

[Andrew Poelstra]

On Mon, Apr 01, 2024 at 01:37:59PM +0000, Pieter Wuille wrote:
>
> As for using other measures to prevent too large difficulty variations... I'm not sure that's desirable, because it always cuts both ways (nicely demonstrated by the "allow difficulty 1 rule" on testnet3 backfiring and enabling block storms!). For applications that actually need very predictable block rate, there is signet. For others, just the normal mainnet rules are probably not too terrible. I would be ok with having a somewhat reduced block interval (say a few days instead of 2 weeks) if that's not deemed to complex to implement across the ecosystem, but I don't think it's that important.
>

I really like this. For my part (rust-bitcoin) this would be as simple
as adding an extra parameter to my blockparams structure. Possibly one
already exists, I'd have to check.

This would be much easier than the existing situation where we have
special-case logic for testnet the difficulty-1 target.

It would also limit the amount of bikeshedding possible, since there
aren't too many conflicting goals regarding the retargeting window...
unlike tweaking the existing logic where there's a tradeoff between
"we should make this never happen" and "it should happen often enough
that it doesn't break people's code" and "it should happen if blocks
slow down to like, 1/50th their normal rate even if they are still
technically being produced" and "it shouldn't be possible to trigger
it within the 2-hour timestamp-faking window" etc. And questions
about whether we should fix/redesign the interaction between the reset
rule and the normal difficulty retarget.


OTOH, since we already have the special logic, I'd also be happy with
tweaking the existing rule. My specific proposal (after reading Jameson's
post, which has some nice graphs of difficulty) would be

* increase the reset threshold from 20 minutes to 6 hours, which is
(a) well outside the 2-hour window in which miners can easily fake
timestamps, and (b) will basically never be hit by accident
* increase the reset difficulty from 1 to 1MM, which is an rough lower
bound on the "normal" testnet difficulty seen historically

Which puts us in the "this rule would never be triggered unless
literally everyone stopped mining" corner of the design space.

[Warren Togami]

Would a testnet4 have a new default TCP port number since it is a different network?

Warren Togami

[emsit]

I had to get involved because when I saw the pull request to reset testnet3, I was horrified.
Resetting testnet3 without considering the impact after 13 years of use seems like a very bad and drastic step. As you wrote, testnet3 has been here for 13 years, it's not possible to kill it overnight.
It will require a transitional phase and announcement so that developers have enough time to react. So the BTC client will have the option of both testnet3 and testnet4.
Yes, mining is demanding, it's a pity it went so far... People won't want to give up their testnet3 coins, including me!!!

How will new users earn testnet4? Will they launch a full node and buy an ASIC miner? Faucets will stop working for a while, and most faucets will cease to exist. As long as obtaining testnet coins is not easy and in sufficient quantity, there will always be a small market. Or will it simply deviate from the mainnet, and the reward be more generous? (I lean towards this idea, to keep the block reward from decreasing and having an unlimited amount, when there is a lot of it, it will not be rare and will not have value. Or will it reset every year or two so it doesn't have enough time to become valuable?)

Dátum: nedeľa 31. marca 2024, čas: 15:24:34 UTC+2, odosielateľ: Jameson Lopp

[Fabian]

Hi,

removing the special rule and moving to a reduced block interval sounds like a good and simple solution.

Another idea: Keep the current exception logic and adapt the difficulty adjustment code (`CalculateNextWorkRequired`) to look for the last block that didn't have difficulty 1 and use that block's difficulty as the basis for the new difficulty calculation. It seemed like the most intuitive fix to me when I looked at the code after reading Jameson's first email (see https://github.com/bitcoin/bitcoin/pull/29775/commits/9913549637706749f0af5d326f949bd652cbd5f8).

Best,
Fabian

> --
> 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/ZgrCxWxMkiAt2Tg2%40camus.

[Jameson Lopp]

I think Andrew's difficulty rule suggestions are the least invasive and make sense for fixing the block storm issue while keeping the code changes to the logic that is already conditional to testnet. Though even with those rules I think it would still be possible, though far less likely, for the difficulty to get permanently reset very low unless we also implement the difficulty adjustment patch Fabian mentioned.

I suspect that creating a "fair" faucet is an unsolvable problem: the only robust way to gate free giveaways (much like airdrops) is to impose an economic cost on claiming them, which is against the spirit of testnet.

As emsit and I both noted, 13 years without a reset means that it would be courteous to give testnet operators a reasonably long heads up to prepare. Perhaps 6 months or 1 year lead time?

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%3D%40protonmail.com.

[Lukáš Kráľ]

I think people will be very reluctant to give up testnet3, including myself. I've been running a testnet3 faucet for 10 years, distributing 327197.44 tBTC via the faucet + a few thousand outside the faucet. Resetting the testnet will mean the end for my faucet because I won't be mining new coins anymore. People who have testnet3 will have to find a new way to obtain testnet4.

Are there any official rules for when a testnet reset will occur? If I understand correctly, it's being considered because of the "price" and the low mining reward? When testnet4 launches and starts trading in a month, will testnet5 be launched shortly after...?

I would focus more on how to keep it invaluable and easily accessible to developers. I would definitely leave the transitional phase for at least a year, and the BTC client should have parameters for both -testnet3 and -testnet4. Personally, I think the adoption of testnet4 will be very slow.

Dátum: utorok 2. apríla 2024, čas: 14:00:40 UTC+2, odosielateľ: Jameson Lopp

[Jameson Lopp]

There are no official rules; this is crypto anarchy. No one can kill testnet3 or stop anyone from using it.

However, the only real "principle" of testnet (AFAIK) is that the coins should be worthless in order to encourage freely sharing said coins with anyone who needs them for development or testing purposes. Client implementations can choose to no longer support old versions of testnet in adherence to this principle.

The rough agreement, which hasn't been necessary to enforce for 13 years, is that testnet should get reset any time it starts to have economic value. I propose that such rug pulls should continue until everyone gets a clue that they're going to lose any money they put into it.

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%40googlegroups.com.

[Anthony Towns]

On Mon, Apr 01, 2024 at 01:37:59PM +0000, Pieter Wuille wrote:

> I think there is an easier alternative to changing the supply rule: the intention to reset it again when its subsidy drops too low. That may even also counteract the development of a non-zero market price for the coins.

We could put some weight behind this by committing to resetting testnet
in advance: eg, add a rule that says "blocks are invalid after height X"
or "after mediantime exceeds Y".

Cheers,
aj

[emsit]

Unfortunately, the current form of Testnet is doomed to have value, just like BTC. Its scarcity makes it a valuable asset. And no reset will change that. It will only result in repeated resets, multiple versions of testnet, and people never learning.

When I imagine what I would have to go through to mine testnet BTC, how much time and money to invest (buying/renting ASIC - CPU mining is a thing of the past), and someone offered me a simpler alternative, to just buy it, I probably wouldn't hesitate and would just buy it. Many people HODL testnet coins precisely because it's difficult to obtain them and they don't want to give them up, regardless of their economic value. People have learned, CRYPTO = HODL.

In my opinion, it's more important to address the issue so that testnet doesn't need to be reset. Because it angers people, even those who aren't responsible and want to use it as intended. I'm afraid that after the reset, mining will be very difficult, expensive, and impossible for most people. Not everyone has an ASIC at home, and CPU mining is out of the question. And faucets won't work. I'm also afraid that whales will emerge who will mine it from the beginning while the reward is high, for worse times.

I have a faucet myself and I know how my users behave, they always want more, and most people HODL it. Only a negligible amount comes back to my faucet. So, the idea of freely sharing is nice but unrealistic.

A reset of testnet that will be "the same" as the old one doesn't make sense to me. Wouldn't it be possible to pre-mine all the coins and distribute them via faucet? Or generate more than 21M? If there are a large number of them, there will be enough for everyone and they will be worthless.

Dátum: streda 3. apríla 2024, čas: 8:41:41 UTC+2, odosielateľ: Anthony Towns

[Andrew Poelstra]

The dystopia you describe is not impossible, but I think it's pretty
unlikely. It's true that most users will not be able to mine, and that
nobody will be able to CPU-mine the way you could with testnet3.

But to get from there to "the only miners will be people who are
hoarding coins to somehow force a positive price" and "there will be no
faucets at all" feels like a stretch. Especially if we had a stated
intention to reset the network every 4 or 8 years or whetever the reward
got too low. Fixed supply or not, I don't see how a network slated to be
abandoned would have a sustainable market value.


Certainly, we could try launching testnet4, and if this happens, we
could switch to testnet5 which would need some further protection.
Perhaps, as you say, it would need to be premined by somebody willing to
run a faucet, for example.

[Calvin Kim]

Throwing myself into the conversation because I think there's other devs that use testnet like I do.

I mainly use testnet for checking if the utreexod implementation I'm building runs into consensus

bugs due to the havoc of how testnet creates bursts of blocks and how it reorganizes itself. I find

the unpredictability a feature.

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

For my usage I never really see this as a problem since signet already provides that usecase. While

I can empathize with devs struggling to get coins, there's always signet for the usecase of testing

scripts/wallets. Signet doesn't really provide the same feature for my usecase. 

> 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/

I stated this above but I find this as a feature.

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

Could I get links/sources for this? I'm curious as to how big of a problem this is.

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

Same for this. Would appreciate links/evidence.

> 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?

I lean towards no unless the problem with testnet coins being valued is too significant.

> 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?

Again, I'd lean towards keeping it the same.

> 3. Is all of the above a waste of time and we should instead deprecate testnet in favor of signet?

No as signet doesn't have the features I find valuable in testnet.

Best,

Calvin

[Jameson Lopp]

On Thu, Apr 4, 2024 at 4:29 AM Calvin Kim <ccy...@gmail.com> wrote:

Throwing myself into the conversation because I think there's other devs that use testnet like I do.

I mainly use testnet for checking if the utreexod implementation I'm building runs into consensus

bugs due to the havoc of how testnet creates bursts of blocks and how it reorganizes itself. I find

the unpredictability a feature.

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

For my usage I never really see this as a problem since signet already provides that usecase. While

I can empathize with devs struggling to get coins, there's always signet for the usecase of testing

scripts/wallets. Signet doesn't really provide the same feature for my usecase. 

> 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/

I stated this above but I find this as a feature.

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

Could I get links/sources for this? I'm curious as to how big of a problem this is.

SatoshiVM airdrop: https://twitter.com/lopp/status/1753522413466464756

Not sure how to prove that I'm inundated with beggars; I've probably gotten 50 messages on a variety of platforms this year from non-developers asking for testnet coins.

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

Same for this. Would appreciate links/evidence.

https://buytestnet.com/

https://altquick.com/exchange/market/BitcoinTestnet

 

> 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?

I lean towards no unless the problem with testnet coins being valued is too significant.

> 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?

Again, I'd lean towards keeping it the same.

> 3. Is all of the above a waste of time and we should instead deprecate testnet in favor of signet?

No as signet doesn't have the features I find valuable in testnet.

Best,

Calvin

--

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/950b875a-e430-4bd8-870d-f9a9fab2493an%40googlegroups.com.

[Calvin Kim]

Ok yeah seems bad enough. I support reseting testnet3.

However, I'm more inclined towards keeping the rules the same. We already have the code for resetting the difficulty so any "fix" would be just adding the burden of switching over to the new testnet for everyone. I haven't seen anyone here mention a reason for the change besides the fact that resetting testnet would be a good time to implement the change.

--- Calvin

[David A. Harding]

On April 4, 2024 6:30:19 PM HST, Calvin Kim <ccy...@gmail.com> wrote:
>I support reseting testnet3.
>
>However, I'm more inclined towards keeping the rules the same.

What about fundamentally requiring BIP34 from the start of the next testnet? I haven't heard anyone say this, but I assume the current testnet4 having reverted[1] to BIP30 is bad for utreexo?

For context, BIP30 invalidates any block that has a transaction with the same txid as an entry in the current UTXO set. A utreexo node doesn't have a complete copy of the utxo set, so it can't enforce BIP30 by itself. I don't think current designs support efficient proof of non-membership, so an untrusted third party can't prove to a utreexo node that no current UTXO matches a given txid. Thus, as I understand it, Utreexo depends on every transaction having a unique txid.

BIP34 requires every coinbase transaction include a unique data push, fixing the only known way to include two bit-identical transactions in the same valid blockchain. On blockchains such as mainnet and testnet4 that started before BIP34, duplicate transactions remain possible in some rare edge cases (called the Block 1,983,702 Problem), so BIP30 support remains necessary unless the underlying issue is further fixed (e.g. [2]). For new blockchains, like a potential testnet5, I think we should probably require BIP34 from genesis so that there's no need to ever rely on BIP30.

-Dave

[1] https://bitcoinops.org/en/newsletters/2022/01/12/#bitcoin-core-23882
[2] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710

[Christian Decker]

I'd like to add my counter example to this: all constructions of off-chain protocols that we know to this day require a repudiation period, during which other parties can intervene to correct or penalize a misbehaving party. This period is enforced in all cases by a delay expressed in blocks.

The unpredictable block generation rate means this mechanism is almost impossible to test on testnet, making it's utility for offchain protocol testing dubious if not outright void.

While a better behaved testnet is no guarantee that it will give rise to a persistent ecosystem that allows more extensive real world testing on testnet, I'd love to have at least the option.

TL;DR: addressing the difficulty reset would be much appreciated.

Regards,

Christian

[K Calvin]

The motivation for signet was fixing this problem for testing applications that required more predictable block times. So this functionality is supported in one of the test networks.

Is there something that a testnet with the difficulty fixed offers that signet doesn’t offer?

—Calvin

[Garlo Nicon]

> 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

[Peter Todd]

NACK

One of the purposes of testnet is to exercise edge cases in code, in an
environment where mistakes don't cost money. It's a good thing that, eg, a
utreexo testnet implementation has to deal with all the the same warts as it
would have to eventually deal with in mainnet.

In fact, ideally if we reset testnet we'd delibrately *add* non-unique txids to
testnet to ensure that code related to that flaw is exercised; IIRC testnet
currently does not have any.


I also believe this principal is a reason to avoid resetting testnet: we have a
large body of weirdness in the current testnet that serves as good test cases
for any implementation. At the very least, if we do a testnet reset we should
consider re-adding all those weird edge cases to the new testnet.

[Garlo Nicon]

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

[coinableS]

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 similar ethos making a reset deploy rather trivial to a point of near centralization, today there are a lot more parties involved that would need to cooperate on a reset. 

Whoever is currently mining is spending a non-negligible amount to mine testnet based on the current difficulty and mempool.space indicates most are mined by unknown miners. 

Will there be enough miners willing to spend money, electricity and dedicate HW to mine the reset chain? I'd be willing 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.

What's the incentive for supporters of a reset to deploy resources 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"). 

I think a reset may prove to 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 theory at play which didn't exist with the two prior resets.

[Garlo Nicon]

> nothing stops people from using, say, regtest for that kind of testing.

How can you test the scenario, where it is hard to get new coins, and you have to get them from the current owners, by using regtest? If the difficulty is absolutely minimal, and every second nonce gives you a valid block hash, then you don't have to worry about your hashrate, because you can always produce a new block, and publish your tests, no matter what.

Also, if you have no difficulty adjustments, then you cannot realistically see your hashrate, even on your CPU. You have to apply a lot of soft-forks on regtest, if you want to check those cases. And you cannot test "getting coins from the current owners" either, because regtest is not safe enough to be deployed online, and you have to soft-fork it into signet, if you want to do so.

Which means, that if you want to test "how the network could behave after many halvings", then testnet3 is a better choice than regtest (which you cannot safely deploy online) or signet (which have less halvings than even mainnet).

And in general, I think it is a good idea, to have at least one test network, which will have more halvings than the mainnet, so we can see in advance, what could happen, before those problems will hit the main network. By the way, when I think about it now, then my conclusion is, that it would be nice, to even have a network, where timestamps are pushed forward, and for example we could see year 2038 or year 2106 problem in some test network earlier, than on the mainnet.

[Sjors Provoost]

> Op 9 apr 2024, om 18:48 heeft Peter Todd <pe...@petertodd.org> het volgende geschreven:
>
> On Sat, Apr 06, 2024 at 01:04:16PM -1000, David A. Harding wrote:
>>
>>
>> On April 4, 2024 6:30:19 PM HST, Calvin Kim <ccy...@gmail.com> wrote:
>>> I support reseting testnet3.
>>>
>>> However, I'm more inclined towards keeping the rules the same.
>>
>> What about fundamentally requiring BIP34 from the start of the next testnet? I haven't heard anyone say this, but I assume the current testnet4 having reverted[1] to BIP30 is bad for utreexo?

The current proposed testnet4 has all the usual soft-forks active from block 1,
see e.g. BIP34Height in src/kernel/chainparams.cpp

https://github.com/bitcoin/bitcoin/pull/29775

> NACK
>
> One of the purposes of testnet is to exercise edge cases in code, in an
> environment where mistakes don't cost money. It's a good thing that, eg, a
> utreexo testnet implementation has to deal with all the the same warts as it
> would have to eventually deal with in mainnet.
>
> In fact, ideally if we reset testnet we'd delibrately *add* non-unique txids to
> testnet to ensure that code related to that flaw is exercised; IIRC testnet
> currently does not have any.

No strong feelings here. If people want this, we could pick a height and have
a short free-for-all duplicate transaction mining period before then.

However, it would be annoying if we later propose a permanent BIP30 fix,
and it turns out it only works on mainnet and not on testnet. Though I suppose
we could just reset it again.

> At the very least, if we do a testnet reset we should
> consider re-adding all those weird edge cases to the new testnet.

For consensus valid transactions that can be done later by anyone. For things
that past soft forks made invalid, someone would have to make plan for when to
activate them, plus a script to produce some interesting test vectors before
activation.

The first Bitcoin Core release with testnet4 will probably be v28 in October,
so there's some time to do this.

Note that some soft forks are treated as always active and are not even set in
chainparams.cpp - we might want to do that again for other soft forks that are
sufficiently old. It would be annoying if testnet gets in the way of that, but see above.

- Sjors

[Ali Sherief]

Regarding testing, It is important for it to be done with a deterministic chain if you're building some kind of node.

But other things like wallets can easily mock the blockchain by having lists of static blocks with specially crafted transactions in them. It allows for things like signing to be tested without having to connect to some live blockchain RPC interface that might fail for some reason.

-Ali

[Matt Corallo]

It has always been very clearly communicated that if testnet starts being valued or traded it will
be reset. There's some legitimate debate over parameters in a reset here, but in the mean time
testnet3 has ceased to serve its intended purpose as a valueless test platform. Thus, it should at
minimum be removed.

On 3/31/24 9:19 AM, 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/
> <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 <mailto: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 <https://groups.google.com/d/msgid/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Matthew Bagazinski]

Unfortunately, the current form of Testnet is doomed to have value, just like BTC. Its scarcity makes it a valuable asset. And no reset will change that. It will only result in repeated resets, multiple versions of testnet, and people never learning.

I have to agree with emsit here. Never underestimate the ability for people to ascribe value to something with provable scarcity.  I like Peter Todd's suggestion of removing the halving completely, so that plenty new coins are always coming into circulation, but it received pushback for removing the regular 210,000-block events. Here are a few dumb ideas to chew on to see if we can come up with something better:

• Doubling every 210,000 blocks. This leads to the supply growing exponentially; impossible to try to ascribe value to that.
• Adding 1 to the subsidy every 210,000 blocks. Still an infinite supply, closer to a standard subsidy, but there is still a change happening every 210,000 blocks.
• Subtracting 1 every 210,000 blocks. This is technically still scarce, but a much gentler decline in admissions. Yes, it eventually drops to 0, but after 50 events instead of the current 33 halvings.
• Change "half" to some other fraction like "nine-tenths". Still technically scarce, gentler decline in rewards, but still retains the property of having a geometric sequence to the subsidies.

Like I said, dumb ideas, but I think there is a decision to be made between avoiding a future reset by mitigating reasons people add value to tBTC (such as scarcity) and expecting/planning for more regular resets when people start inevitably valuing tBTC.

[Ali Sherief]

I think the effort required to remove testnet entirely would be too much to work on. Replacing it with something else is a better idea to minimize disruption.

In the mean time, we need to figure out a process to at least lock down the testnet3 network so that no new blocks can be mined while the replacement chain is commissioned. Is there a BIP with a procedure for replacing testnet? How was it done last time?

-Ali

[Garlo Nicon]

> Doubling every 210,000 blocks.

This can potentially increase spam. Why? Because the minimal fee is one satoshi per virtual byte. So, if you increase coin amounts, without changing anything else, then you also increase the amount of bytes, which you can push to the network. Because if you have 50 tBTC, then it means you can push 5 GB of data, so if you suddenly would get 100 tBTC per block, then it would increase your spamming ability to 10 GB, and then 20 GB, and then 40 GB, and so on.

Also, going one bit to the left in every doubling means, that after a few doublings, the values in 64-bit numbers will overflow, so that approach will recreate the Value Overflow Incident. In general, the value of 50 tBTC can be written as 0x12a05f200. That means, after 31 doublings, you will get 0x9502f90000000000, corresponding to 107,374,182,400 tBTC, and the next value will overflow.

> impossible to try to ascribe value to that.

Even if some monetary system has some inflation, some value can always be assigned. For example, a lot of fiat coins like dollars, can have unlimited inflation. And they still have value, even if there is no max supply. There is even a word for what happens in systems with hyperinflation, it is called redenomination: https://en.wikipedia.org/wiki/Redenomination

The same with many altcoins, which don't have any upper limit. Also note, that in many altcoins, there is a trend of burning coins, to increase their value. So, the same could happen in a new testnet: claiming less coins in the coinbase transaction, is a perfectly valid no-fork, that would be compatible, so even if you type in code "you can get 100 tBTC", then miners could still claim only 50 tBTC or 25 tBTC, and their blocks will be valid.

Also, assuming no blockstorms, if you touch any rules, related to halvings, then they don't have to hit us immediately. It is possible, that for the next four years, everything will be fine, but after that, there will be a lot of drama, related to what should be the correct value of the coinbase transaction after that period. Note that even in the official signet, we are still before the first halving.

[Peter Todd]

On Thu, May 02, 2024 at 12:10:43AM -0700, Ali Sherief wrote:
> I think the effort required to remove testnet entirely would be too much to
> work on. Replacing it with something else is a better idea to minimize
> disruption.
>
> In the mean time, we need to figure out a process to at least lock down the
> testnet3 network so that no new blocks can be mined while the replacement
> chain is commissioned. Is there a BIP with a procedure for replacing
> testnet? How was it done last time?

It's impossible to lock down testnet and prevent new blocks from being mined.
Testnet is a decentralized PoW system, just like Bitcoin, with no central
points of control. The best we could do is 51% attack testnet. But that's
could easily be quite expensive precisely because people are using it for
valuable applications.

[Peter Todd]

On Tue, Apr 30, 2024 at 11:46:59AM -0700, Matthew Bagazinski wrote:
>
>
> Unfortunately, the current form of Testnet is doomed to have value, just
> like BTC. Its scarcity makes it a valuable asset. And no reset will change
> that. It will only result in repeated resets, multiple versions of testnet,
> and people never learning.

The scarcity of testnet BTC isn't the only valuable asset in testnet; testnet
blockchain space itself is a scarce, valuable, asset. It's an asset that we
can't easily make worthless, even through testnet resets, as there are usecases
(including scams) where the long-term persistence of the data doesn't matter.