[bitcoindev] The Future of Bitcoin Testnet

[bitcoindev] The Future of Bitcoin Testnet

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

Hi all,

I'd like to open a discussion about testnet3 to put out some feelers on
potential changes to it. First, a few facts:

1. Testnet3 has been running for 13 years. It's on block 2.5 million
something and the block reward is down to ~0.014 TBTC, so mining is not
doing a great job at distributing testnet coins any more.

2. The reason the block height is insanely high is due to a rather amusing
edge case bug that causes the difficulty to regularly get reset to 1, which
causes a bit of havoc. If you want a deep dive into the quirk:
https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/

3. Testnet3 is being actively used for scammy airdrops; those of us who
tend to be generous with our testnet coins are getting hounded by
non-developers chasing cheap gains.

4. As a result, TBTC is being actively bought and sold; one could argue
that the fundamental principle of testnet coins having no value has been
broken.

This leads me to ponder the following questions, for which I'm soliciting
feedback.

1. Should we plan for a reset of testnet? If so, given how long it has been
since the last reset and how many production systems will need to be
updated, would a reset need to be done with a great deal of notice?

2. Is there interest in fixing the difficulty reset bug? It should be a one
liner fix, and I'd argue it could be done sooner rather than later, and
orthogonal to the network reset question. Would such a change, which would
technically be a hard fork (but also arguably a self resolving fork due to
the difficulty dynamics) necessitate a BIP or could we just YOLO it?

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

- Jameson

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 2737 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Luke Dashjr]

[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]

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+unsubscribe@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>.

-- 
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/8c6e98ff-bdec-4955-8132-bd93af2d40dd%40dashjr.org.

[-- Attachment #2: Type: text/html, Size: 4734 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 3560 bytes --]

On Sun, Mar 31, 2024 at 10:33 AM Luke Dashjr <luke@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.

> 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+unsubscribe@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>
> .
>
>

-- 
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/CADL_X_eZ3uDU7PPh11rn2NSGwvRMjjZ3Auu6eVVQoJU78%2BaRxQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 5590 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Eric Voskuil]

[-- Attachment #1: Type: text/html, Size: 7718 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Garlo Nicon]

[-- Attachment #1.1: Type: text/plain, Size: 7425 bytes --]

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

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

[-- Attachment #1.2: Type: text/html, Size: 9267 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]

On Sun, Mar 31, 2024 at 09:19:50AM -0400, 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?

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Nagaev Boris]

On Sun, Mar 31, 2024 at 1:25 PM Peter Todd <pete@petertodd.org> wrote:
>
> On Sun, Mar 31, 2024 at 09:19:50AM -0400, 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?
>
> 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.

>
> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZgmJFfXnQddkTQVq%40petertodd.org.



-- 
Best regards,
Boris Nagaev

-- 
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/CAFC_Vt7zKvMEfQLzWHQ6t_9bgv1iqt4Ah8N883CuoSfmLUKdMA%40mail.gmail.com.

Re: [bitcoindev] The Future of Bitcoin Testnet

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

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.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZgnVtJHn2ikLfwa9%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]

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.

On Sun, Mar 31, 2024 at 5:29 PM Peter Todd <pete@petertodd.org> wrote:

> 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.
>
> --
> 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_cmcXxHke089OD_45VRJy5aR%2B9uj-18bSjXBE7FKwR-Jw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 2939 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Pieter Wuille]

On Monday, April 1st, 2024 at 8:54 AM, Jameson Lopp <jameson.lopp@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

-- 
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/wKrcm6SEjcG_7UmxByP-rDDVajB7-oYJRF9p_BjLe5XVzxVV9nCB8RsTAXcD5vF_rWxUmLK4HOM7zV7U4-kZSUO9Ccj4jEehsbbb7FD45GQ%3D%40wuille.net.

Re: [bitcoindev] The Future of Bitcoin Testnet

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 2899 bytes --]

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.


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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

['Fabian' via Bitcoin Development Mailing List]

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



On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra <apoelstra@wpsoftware.net> wrote:

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

-- 
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/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%3D%40protonmail.com.

Re: [bitcoindev] The Future of Bitcoin Testnet

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 5704 bytes --]

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?

On Mon, Apr 1, 2024 at 6:06 PM 'Fabian' via Bitcoin Development Mailing
List <bitcoindev@googlegroups.com> wrote:

> 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
>
>
>
> On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra <
> apoelstra@wpsoftware.net> wrote:
>
> > 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.
> >
> >
> > --
> > 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
> >
> > --
> > 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/ZgrCxWxMkiAt2Tg2%40camus.
>
> --
> 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/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%3D%40protonmail.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/CADL_X_dR1ENC9jm76azf_dkbJdeSCSBbPEpTkm71s4i-g_g%3DWA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 7565 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Lukáš Kráľ]

[-- Attachment #1.1: Type: text/plain, Size: 6907 bytes --]



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

> 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?
>
> On Mon, Apr 1, 2024 at 6:06 PM 'Fabian' via Bitcoin Development Mailing 
> List <bitco...@googlegroups.com> wrote:
>
>> 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
>>
>>
>>
>> On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra <
>> apoe...@wpsoftware.net> wrote:
>>
>> > 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.
>> > 
>> > 
>> > --
>> > 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
>> > 
>> > --
>> > 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.
>>
>> -- 
>> 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/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%3D%40protonmail.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/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 11461 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 8364 bytes --]

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.

On Tue, Apr 2, 2024 at 3:05 PM Lukáš Kráľ <emsit@emsit.sk> wrote:

> 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
>
>> 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?
>>
>> On Mon, Apr 1, 2024 at 6:06 PM 'Fabian' via Bitcoin Development Mailing
>> List <bitco...@googlegroups.com> wrote:
>>
>>> 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
>>>
>>>
>>>
>>> On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra <
>>> apoe...@wpsoftware.net> wrote:
>>>
>>> > 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.
>>> >
>>> >
>>> > --
>>> > 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
>>> >
>>> > --
>>> > 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.
>>>
>>> --
>>> 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/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%3D%40protonmail.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/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CADL_X_c3YhyeqgsrFBVixpPOQWEacsa5cZUSK5uzLLNha9w%3D%2BQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 11920 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[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

-- 
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/ZgzYtZqPcnykqyxK%40erisian.com.au.

Re: [bitcoindev] The Future of Bitcoin Testnet

[emsit]

[-- Attachment #1.1: Type: text/plain, Size: 2784 bytes --]



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

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

-- 
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/7a67edd1-0182-4170-90f4-998d12431024n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5578 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 3271 bytes --]

On Wed, Apr 03, 2024 at 11:18:49AM -0700, emsit 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.
> 
> 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.
>

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.


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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Matthew Bagazinski]

[-- Attachment #1.1: Type: text/plain, Size: 2051 bytes --]



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.

-- 
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/3b1a26a9-acef-496a-8465-c32879d2a833n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2897 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Garlo Nicon]

[-- Attachment #1.1: Type: text/plain, Size: 4294 bytes --]

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

Tuesday, 30 April 2024 at 21:00:32 UTC+2 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.

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.

-- 
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/47e4f1a0-709a-438b-a3ba-9e397c373ea9n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5363 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

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.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZjZstmciwJ9oPZ1x%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Garlo Nicon]

[-- Attachment #1.1: Type: text/plain, Size: 2703 bytes --]

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

sunday, 31 march 2024 at 23:30:04 UTC+2 Peter Todd wrote:

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. 

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/dd1f43b7-bd02-4fe4-9d69-2fa398c99b4en%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3411 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Ali Sherief]

[-- Attachment #1.1: Type: text/plain, Size: 3348 bytes --]

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

On Monday, April 15, 2024 at 6:01:25 PM UTC Garlo Nicon wrote:

> > 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.
>
> sunday, 31 march 2024 at 23:30:04 UTC+2 Peter Todd wrote:
>
> 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. 
>
> -- 
> 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/664a3cd1-44d2-46d7-ae1a-2dca6f609b56n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4472 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

['Fabian' via Bitcoin Development Mailing List]

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


On Monday, April 1st, 2024 at 3:25 PM, Andrew Poelstra <apoelstra@wpsoftware.net> wrote:

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

-- 
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/XMuCEcSeUAgzOVSt2jRtdPPDVpX-ZRvJZ5SW3mc4tsbHNGKcaxOG5ZVYKD9xwCQjd7rIvW8Rq4lcVaL5eKe6AVyxa9unQWAhdU8RozWlj2E%3D%40protonmail.com.

Re: [bitcoindev] The Future of Bitcoin Testnet

[Warren Togami]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

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

Warren Togami

-- 
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/CAEz79PqOCqcRw1_TAJ8ScjkzMNDXmXpzJ7NPuuPxAN8H_cye7A%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 846 bytes --]

[bitcoindev] Re: The Future of Bitcoin Testnet

[emsit]

[-- Attachment #1.1: Type: text/plain, Size: 3552 bytes --]

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

> Hi all,
>
> I'd like to open a discussion about testnet3 to put out some feelers on 
> potential changes to it. First, a few facts:
>
> 1. Testnet3 has been running for 13 years. It's on block 2.5 million 
> something and the block reward is down to ~0.014 TBTC, so mining is not 
> doing a great job at distributing testnet coins any more.
>
> 2. The reason the block height is insanely high is due to a rather amusing 
> edge case bug that causes the difficulty to regularly get reset to 1, which 
> causes a bit of havoc. If you want a deep dive into the quirk: 
> https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/
>
> 3. Testnet3 is being actively used for scammy airdrops; those of us who 
> tend to be generous with our testnet coins are getting hounded by 
> non-developers chasing cheap gains.
>
> 4. As a result, TBTC is being actively bought and sold; one could argue 
> that the fundamental principle of testnet coins having no value has been 
> broken.
>
> This leads me to ponder the following questions, for which I'm soliciting 
> feedback.
>
> 1. Should we plan for a reset of testnet? If so, given how long it has 
> been since the last reset and how many production systems will need to be 
> updated, would a reset need to be done with a great deal of notice?
>
> 2. Is there interest in fixing the difficulty reset bug? It should be a 
> one liner fix, and I'd argue it could be done sooner rather than later, and 
> orthogonal to the network reset question. Would such a change, which would 
> technically be a hard fork (but also arguably a self resolving fork due to 
> the difficulty dynamics) necessitate a BIP or could we just YOLO it?
>
> 3. Is all of the above a waste of time and we should instead deprecate 
> testnet in favor of signet?
>
> - Jameson
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/e9c98c9c-6a61-4cc6-9efb-9ea2ca9a76f0n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4478 bytes --]

[bitcoindev] Re: The Future of Bitcoin Testnet

[Calvin Kim]

[-- Attachment #1.1: Type: text/plain, Size: 2929 bytes --]

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

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

[-- Attachment #1.2: Type: text/html, Size: 4006 bytes --]

Re: [bitcoindev] Re: The Future of Bitcoin Testnet

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 4056 bytes --]

On Thu, Apr 4, 2024 at 4:29 AM Calvin Kim <ccychc@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+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/950b875a-e430-4bd8-870d-f9a9fab2493an%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/950b875a-e430-4bd8-870d-f9a9fab2493an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CADL_X_fs0OVAoFiekm3sLUyODXr6j7mh8M6zQV_dEyg05itE6A%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 5934 bytes --]

Re: [bitcoindev] Re: The Future of Bitcoin Testnet

[Calvin Kim]

[-- Attachment #1.1: Type: text/plain, Size: 4683 bytes --]

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
On Thursday, April 4, 2024 at 10:02:15 PM UTC+9 Jameson Lopp wrote:

> 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 
>> <https://groups.google.com/d/msgid/bitcoindev/950b875a-e430-4bd8-870d-f9a9fab2493an%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/efa3e907-cd2b-4897-b476-8bbc6091a3edn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 8655 bytes --]

Re: [bitcoindev] Re: The Future of Bitcoin Testnet

[David A. Harding]

On April 4, 2024 6:30:19 PM HST, Calvin Kim <ccychc@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 

-- 
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/FB86E432-FAF0-466D-802D-938614AE0BDD%40dtrt.org.

Re: [bitcoindev] Re: The Future of Bitcoin Testnet

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]

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

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.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZhVxZN6eLiCpdQ/F%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

['Sjors Provoost' via Bitcoin Development Mailing List]

[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]

> Op 9 apr 2024, om 18:48 heeft Peter Todd <pete@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 <ccychc@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

-- 
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/B72E693A-4050-4AE8-B8FE-8986760BD9C3%40sprovoost.nl.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] Re: The Future of Bitcoin Testnet

[Christian Decker]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

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

-- 
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/CALxbBHVvizwxzgiX-W%3D0-wOmjBSb9pLK6H25Cn-fuNnZML%2BA%2Bg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 1684 bytes --]

Re: [bitcoindev] Re: The Future of Bitcoin Testnet

[K Calvin]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

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

Christian Decker <decker.christian@gmail.com> schrieb am So. 7. Apr. 2024
um 4:20 PM:

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

-- 
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/CAGYLYJTWPtuKX1NqHHoWpX_%2BTO7fSK2SzGkpqKwp4r4x9%3DKDBA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 2513 bytes --]

[bitcoindev] Re: The Future of Bitcoin Testnet

[Garlo Nicon]

[-- Attachment #1.1: Type: text/plain, Size: 7419 bytes --]

> so mining is not doing a great job at distributing testnet coins any more

It is a feature, not a bug. Would people want to reset Bitcoin main network 
in the future, for exactly the same reasons? Or would they want to 
introduce "tail supply", or other similar inventions, to provide sufficient 
incentive for miners? This testnet3 is unique, because it has quite low 
block reward. And that particular feature should be preserved, even if the 
network would be resetted (for example, it could be "after 12 halvings, but 
where all previous coins were burned"). And not, it is not the same as 
starting from 50 tBTC, as long as fee rates are left unchanged (and 0.014 
TBTC means "the ability to push around 1.4 MB of data, with feerate of 1 
sat/vB", instead of 50 tBTC, which means "pushing 5 GB with the same 
feerate").

> a rather amusing edge case bug that causes the difficulty to regularly 
get reset to 1

It can be fixed in a soft-fork way, no network reset is needed to achieve 
that. Because if there is a block number X, and it could have minimal 
difficulty, under the current rules, then it is possible to reject it, and 
enforce the higher difficulty. In general, increasing difficulty is a 
soft-fork. For example, if someone would enforce testnet difficulty on 
regtest, it would be perfectly valid. All that is needed, is just rejecting 
more block hashes, so even if all fields are left unchanged, the old client 
could see, that the 32-bit difficulty field says "minimal", but produced 
blocks are not accepted, and "the true difficulty" is put anywhere else, 
for example just after the block number in the coinbase transaction.

> Testnet3 is being actively used for scammy airdrops

This is because mining is costly, and because coins are never "resetted", 
so they are never "worthless". Pointing at some chain, and saying "this 
should be worthless" is not enough to make it. There are no consensus rules 
to ensure that test coins are truly worthless. There is no "automatic 
reset", or any "demurrage". If large amounts of coins are misused, then 
that misuse can be stopped, by burning coins, or invalidating them in any 
other way, for example "the coin is unspendable, if it was created during 
the previous halving". As long as there are no such rules, resetting the 
network won't help in the long term, so something new is needed, to 
discourage assigning any value into test coins.

> Should we plan for a reset of testnet?

I guess the answer is "yes", but maybe not by "throwing away the whole 
existing chain", but just by "fixing errors one-by-one". For example, 
fixing blockstorms as a soft-fork would be a good starting point. And in 
practice, it may turn out, that all fixes could be applied in a soft-fork 
way, which would be the best, because then it would be enforced also on 
non-upgraded clients.

> If so, given how long it has been since the last reset and how many 
production systems will need to be updated, would a reset need to be done 
with a great deal of notice?

No additional "notice" would be needed, if every "fix" would be a 
soft-fork, and if all old clients would follow all new changes.

> Is there interest in fixing the difficulty reset bug?

Yes. But because it could be a soft-fork, miners could signal readiness in 
block versions. Also, as with every other soft-fork, it would have 
additional advantage, that if someone would want to locally test 
"blockstorms", then that person would be able to locally create a chain, 
where that particular soft-fork would be inactive. Which means, that it 
would be still possible, to download the new chain, and disable that 
soft-fork locally, if someone would need it.

> Would such a change, which would technically be a hard fork

It would be a soft-fork. Each difficulty increase is a soft-fork, because 
"old blocks are invalid in a new version" (they don't meet increased 
difficulty), but also "new blocks are valid in an old version" (they meet 
the old difficulty, exactly as the mainnet Genesis Block with 40 leading 
zero bits meets the required difficulty with 32 leading zeroes).

> necessitate a BIP or could we just YOLO it?

Well, it is possible to just add some flag, like "-blockstorm=0". Then, 
some miners could activate it, just like they activated full-RBF. And if 
the majority would want to get rid of blockstorms, then it would just 
happen naturally, if the majority would simply reject blockstorms in a 
soft-fork way. I think it is not that important to make a BIP, unless you 
really want to get through the whole process.

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

This scenario is also possible, but probably not in the way you think. 
Transition from testnet into signet is a perfect soft-fork. If you decide, 
that since block number N, all blocks should be signed with "signet 
challenge", then it would lead to a natural conversion from permissionless 
mining into permissioned mining. You can implement it, and start with 
OP_TRUE, to test, if everything is working correctly. And then, you can 
apply for example "OP_1 <taproot_address>" as the signet challenge, and 
then use all TapScript features to sign new testnet3 blocks.

sunday, 31 march 2024 at 15:24:34 UTC+2 Jameson Lopp wrote:

Hi all,

I'd like to open a discussion about testnet3 to put out some feelers on 
potential changes to it. First, a few facts:

1. Testnet3 has been running for 13 years. It's on block 2.5 million 
something and the block reward is down to ~0.014 TBTC, so mining is not 
doing a great job at distributing testnet coins any more.

2. The reason the block height is insanely high is due to a rather amusing 
edge case bug that causes the difficulty to regularly get reset to 1, which 
causes a bit of havoc. If you want a deep dive into the quirk: 
https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/

3. Testnet3 is being actively used for scammy airdrops; those of us who 
tend to be generous with our testnet coins are getting hounded by 
non-developers chasing cheap gains.

4. As a result, TBTC is being actively bought and sold; one could argue 
that the fundamental principle of testnet coins having no value has been 
broken.

This leads me to ponder the following questions, for which I'm soliciting 
feedback.

1. Should we plan for a reset of testnet? If so, given how long it has been 
since the last reset and how many production systems will need to be 
updated, would a reset need to be done with a great deal of notice?

2. Is there interest in fixing the difficulty reset bug? It should be a one 
liner fix, and I'd argue it could be done sooner rather than later, and 
orthogonal to the network reset question. Would such a change, which would 
technically be a hard fork (but also arguably a self resolving fork due to 
the difficulty dynamics) necessitate a BIP or could we just YOLO it?

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

- Jameson

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6733b634-e6da-4bb3-a3b6-bffa41395e9cn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 8366 bytes --]

[bitcoindev] Re: The Future of Bitcoin Testnet

[coinableS]

[-- Attachment #1.1: Type: text/plain, Size: 9354 bytes --]

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.
On Monday, April 8, 2024 at 12:35:38 PM UTC-7 Garlo Nicon wrote:

> > so mining is not doing a great job at distributing testnet coins any more
>
> It is a feature, not a bug. Would people want to reset Bitcoin main 
> network in the future, for exactly the same reasons? Or would they want to 
> introduce "tail supply", or other similar inventions, to provide sufficient 
> incentive for miners? This testnet3 is unique, because it has quite low 
> block reward. And that particular feature should be preserved, even if the 
> network would be resetted (for example, it could be "after 12 halvings, but 
> where all previous coins were burned"). And not, it is not the same as 
> starting from 50 tBTC, as long as fee rates are left unchanged (and 0.014 
> TBTC means "the ability to push around 1.4 MB of data, with feerate of 1 
> sat/vB", instead of 50 tBTC, which means "pushing 5 GB with the same 
> feerate").
>
> > a rather amusing edge case bug that causes the difficulty to regularly 
> get reset to 1
>
> It can be fixed in a soft-fork way, no network reset is needed to achieve 
> that. Because if there is a block number X, and it could have minimal 
> difficulty, under the current rules, then it is possible to reject it, and 
> enforce the higher difficulty. In general, increasing difficulty is a 
> soft-fork. For example, if someone would enforce testnet difficulty on 
> regtest, it would be perfectly valid. All that is needed, is just rejecting 
> more block hashes, so even if all fields are left unchanged, the old client 
> could see, that the 32-bit difficulty field says "minimal", but produced 
> blocks are not accepted, and "the true difficulty" is put anywhere else, 
> for example just after the block number in the coinbase transaction.
>
> > Testnet3 is being actively used for scammy airdrops
>
> This is because mining is costly, and because coins are never "resetted", 
> so they are never "worthless". Pointing at some chain, and saying "this 
> should be worthless" is not enough to make it. There are no consensus rules 
> to ensure that test coins are truly worthless. There is no "automatic 
> reset", or any "demurrage". If large amounts of coins are misused, then 
> that misuse can be stopped, by burning coins, or invalidating them in any 
> other way, for example "the coin is unspendable, if it was created during 
> the previous halving". As long as there are no such rules, resetting the 
> network won't help in the long term, so something new is needed, to 
> discourage assigning any value into test coins.
>
> > Should we plan for a reset of testnet?
>
> I guess the answer is "yes", but maybe not by "throwing away the whole 
> existing chain", but just by "fixing errors one-by-one". For example, 
> fixing blockstorms as a soft-fork would be a good starting point. And in 
> practice, it may turn out, that all fixes could be applied in a soft-fork 
> way, which would be the best, because then it would be enforced also on 
> non-upgraded clients.
>
> > If so, given how long it has been since the last reset and how many 
> production systems will need to be updated, would a reset need to be done 
> with a great deal of notice?
>
> No additional "notice" would be needed, if every "fix" would be a 
> soft-fork, and if all old clients would follow all new changes.
>
> > Is there interest in fixing the difficulty reset bug?
>
> Yes. But because it could be a soft-fork, miners could signal readiness in 
> block versions. Also, as with every other soft-fork, it would have 
> additional advantage, that if someone would want to locally test 
> "blockstorms", then that person would be able to locally create a chain, 
> where that particular soft-fork would be inactive. Which means, that it 
> would be still possible, to download the new chain, and disable that 
> soft-fork locally, if someone would need it.
>
> > Would such a change, which would technically be a hard fork
>
> It would be a soft-fork. Each difficulty increase is a soft-fork, because 
> "old blocks are invalid in a new version" (they don't meet increased 
> difficulty), but also "new blocks are valid in an old version" (they meet 
> the old difficulty, exactly as the mainnet Genesis Block with 40 leading 
> zero bits meets the required difficulty with 32 leading zeroes).
>
> > necessitate a BIP or could we just YOLO it?
>
> Well, it is possible to just add some flag, like "-blockstorm=0". Then, 
> some miners could activate it, just like they activated full-RBF. And if 
> the majority would want to get rid of blockstorms, then it would just 
> happen naturally, if the majority would simply reject blockstorms in a 
> soft-fork way. I think it is not that important to make a BIP, unless you 
> really want to get through the whole process.
>
> > Is all of the above a waste of time and we should instead deprecate 
> testnet in favor of signet?
>
> This scenario is also possible, but probably not in the way you think. 
> Transition from testnet into signet is a perfect soft-fork. If you decide, 
> that since block number N, all blocks should be signed with "signet 
> challenge", then it would lead to a natural conversion from permissionless 
> mining into permissioned mining. You can implement it, and start with 
> OP_TRUE, to test, if everything is working correctly. And then, you can 
> apply for example "OP_1 <taproot_address>" as the signet challenge, and 
> then use all TapScript features to sign new testnet3 blocks.
>
> sunday, 31 march 2024 at 15:24:34 UTC+2 Jameson Lopp wrote:
>
> Hi all,
>
> I'd like to open a discussion about testnet3 to put out some feelers on 
> potential changes to it. First, a few facts:
>
> 1. Testnet3 has been running for 13 years. It's on block 2.5 million 
> something and the block reward is down to ~0.014 TBTC, so mining is not 
> doing a great job at distributing testnet coins any more.
>
> 2. The reason the block height is insanely high is due to a rather amusing 
> edge case bug that causes the difficulty to regularly get reset to 1, which 
> causes a bit of havoc. If you want a deep dive into the quirk: 
> https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/
>
> 3. Testnet3 is being actively used for scammy airdrops; those of us who 
> tend to be generous with our testnet coins are getting hounded by 
> non-developers chasing cheap gains.
>
> 4. As a result, TBTC is being actively bought and sold; one could argue 
> that the fundamental principle of testnet coins having no value has been 
> broken.
>
> This leads me to ponder the following questions, for which I'm soliciting 
> feedback.
>
> 1. Should we plan for a reset of testnet? If so, given how long it has 
> been since the last reset and how many production systems will need to be 
> updated, would a reset need to be done with a great deal of notice?
>
> 2. Is there interest in fixing the difficulty reset bug? It should be a 
> one liner fix, and I'd argue it could be done sooner rather than later, and 
> orthogonal to the network reset question. Would such a change, which would 
> technically be a hard fork (but also arguably a self resolving fork due to 
> the difficulty dynamics) necessitate a BIP or could we just YOLO it?
>
> 3. Is all of the above a waste of time and we should instead deprecate 
> testnet in favor of signet?
>
> - Jameson
>
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/83ec2b84-2255-4ac1-a40c-3f3a04a1c86fn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 11884 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[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+unsubscribe@googlegroups.com <mailto:bitcoindev+unsubscribe@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>.

-- 
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/6a787f0d-db85-48fe-9e00-217ccd2a0f2f%40mattcorallo.com.

Re: [bitcoindev] The Future of Bitcoin Testnet

[Ali Sherief]

[-- Attachment #1.1: Type: text/plain, Size: 3821 bytes --]

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

On Sunday, April 28, 2024 at 2:06:01 PM UTC Matt Corallo wrote:

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


-- 
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/52654980-c4f1-4d8e-a305-3a34c01b8599n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5274 bytes --]

Re: [bitcoindev] The Future of Bitcoin Testnet

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

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.

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZjZrhw9FiYNJ6wBH%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]