* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 13:19 [bitcoindev] The Future of Bitcoin Testnet Jameson Lopp
@ 2024-03-31 14:33 ` Luke Dashjr
2024-03-31 14:57 ` Jameson Lopp
2024-04-09 18:28 ` Garlo Nicon
2024-03-31 16:02 ` Peter Todd
` (6 subsequent siblings)
7 siblings, 2 replies; 40+ messages in thread
From: Luke Dashjr @ 2024-03-31 14:33 UTC (permalink / raw)
To: Jameson Lopp, bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 14:33 ` Luke Dashjr
@ 2024-03-31 14:57 ` Jameson Lopp
2024-03-31 17:21 ` Eric Voskuil
2024-04-09 18:28 ` Garlo Nicon
1 sibling, 1 reply; 40+ messages in thread
From: Jameson Lopp @ 2024-03-31 14:57 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 14:33 ` Luke Dashjr
2024-03-31 14:57 ` Jameson Lopp
@ 2024-04-09 18:28 ` Garlo Nicon
1 sibling, 0 replies; 40+ messages in thread
From: Garlo Nicon @ 2024-04-09 18:28 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 13:19 [bitcoindev] The Future of Bitcoin Testnet Jameson Lopp
2024-03-31 14:33 ` Luke Dashjr
@ 2024-03-31 16:02 ` Peter Todd
2024-03-31 21:01 ` Nagaev Boris
2024-04-01 13:25 ` Andrew Poelstra
` (5 subsequent siblings)
7 siblings, 1 reply; 40+ messages in thread
From: Peter Todd @ 2024-03-31 16:02 UTC (permalink / raw)
To: Jameson Lopp; +Cc: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 16:02 ` Peter Todd
@ 2024-03-31 21:01 ` Nagaev Boris
2024-03-31 21:29 ` Peter Todd
0 siblings, 1 reply; 40+ messages in thread
From: Nagaev Boris @ 2024-03-31 21:01 UTC (permalink / raw)
To: Peter Todd; +Cc: Jameson Lopp, bitcoindev
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 21:01 ` Nagaev Boris
@ 2024-03-31 21:29 ` Peter Todd
2024-04-01 12:54 ` Jameson Lopp
2024-04-10 6:57 ` Garlo Nicon
0 siblings, 2 replies; 40+ messages in thread
From: Peter Todd @ 2024-03-31 21:29 UTC (permalink / raw)
To: Nagaev Boris; +Cc: Jameson Lopp, bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 21:29 ` Peter Todd
@ 2024-04-01 12:54 ` Jameson Lopp
2024-04-01 13:37 ` Pieter Wuille
2024-04-10 6:57 ` Garlo Nicon
1 sibling, 1 reply; 40+ messages in thread
From: Jameson Lopp @ 2024-04-01 12:54 UTC (permalink / raw)
To: Peter Todd; +Cc: Nagaev Boris, bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-01 12:54 ` Jameson Lopp
@ 2024-04-01 13:37 ` Pieter Wuille
2024-04-01 14:20 ` Andrew Poelstra
2024-04-03 4:19 ` Anthony Towns
0 siblings, 2 replies; 40+ messages in thread
From: Pieter Wuille @ 2024-04-01 13:37 UTC (permalink / raw)
To: Jameson Lopp; +Cc: Peter Todd, Nagaev Boris, bitcoindev
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-01 13:37 ` Pieter Wuille
@ 2024-04-01 14:20 ` Andrew Poelstra
2024-04-01 22:01 ` 'Fabian' via Bitcoin Development Mailing List
2024-04-03 4:19 ` Anthony Towns
1 sibling, 1 reply; 40+ messages in thread
From: Andrew Poelstra @ 2024-04-01 14:20 UTC (permalink / raw)
To: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-01 14:20 ` Andrew Poelstra
@ 2024-04-01 22:01 ` 'Fabian' via Bitcoin Development Mailing List
2024-04-02 11:53 ` Jameson Lopp
0 siblings, 1 reply; 40+ messages in thread
From: 'Fabian' via Bitcoin Development Mailing List @ 2024-04-01 22:01 UTC (permalink / raw)
To: Andrew Poelstra; +Cc: bitcoindev
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-01 22:01 ` 'Fabian' via Bitcoin Development Mailing List
@ 2024-04-02 11:53 ` Jameson Lopp
2024-04-02 18:36 ` Lukáš Kráľ
0 siblings, 1 reply; 40+ messages in thread
From: Jameson Lopp @ 2024-04-02 11:53 UTC (permalink / raw)
To: Fabian; +Cc: Andrew Poelstra, bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-02 11:53 ` Jameson Lopp
@ 2024-04-02 18:36 ` Lukáš Kráľ
2024-04-02 19:46 ` Jameson Lopp
0 siblings, 1 reply; 40+ messages in thread
From: Lukáš Kráľ @ 2024-04-02 18:36 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-02 18:36 ` Lukáš Kráľ
@ 2024-04-02 19:46 ` Jameson Lopp
0 siblings, 0 replies; 40+ messages in thread
From: Jameson Lopp @ 2024-04-02 19:46 UTC (permalink / raw)
To: Lukáš Kráľ; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-01 13:37 ` Pieter Wuille
2024-04-01 14:20 ` Andrew Poelstra
@ 2024-04-03 4:19 ` Anthony Towns
2024-04-03 18:18 ` emsit
1 sibling, 1 reply; 40+ messages in thread
From: Anthony Towns @ 2024-04-03 4:19 UTC (permalink / raw)
To: Pieter Wuille; +Cc: bitcoindev
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-03 4:19 ` Anthony Towns
@ 2024-04-03 18:18 ` emsit
2024-04-03 19:35 ` Andrew Poelstra
2024-04-30 18:46 ` Matthew Bagazinski
0 siblings, 2 replies; 40+ messages in thread
From: emsit @ 2024-04-03 18:18 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-03 18:18 ` emsit
@ 2024-04-03 19:35 ` Andrew Poelstra
2024-04-30 18:46 ` Matthew Bagazinski
1 sibling, 0 replies; 40+ messages in thread
From: Andrew Poelstra @ 2024-04-03 19:35 UTC (permalink / raw)
To: emsit; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-03 18:18 ` emsit
2024-04-03 19:35 ` Andrew Poelstra
@ 2024-04-30 18:46 ` Matthew Bagazinski
2024-05-01 15:30 ` Garlo Nicon
2024-05-04 17:13 ` Peter Todd
1 sibling, 2 replies; 40+ messages in thread
From: Matthew Bagazinski @ 2024-04-30 18:46 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-30 18:46 ` Matthew Bagazinski
@ 2024-05-01 15:30 ` Garlo Nicon
2024-05-04 17:13 ` Peter Todd
1 sibling, 0 replies; 40+ messages in thread
From: Garlo Nicon @ 2024-05-01 15:30 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-30 18:46 ` Matthew Bagazinski
2024-05-01 15:30 ` Garlo Nicon
@ 2024-05-04 17:13 ` Peter Todd
1 sibling, 0 replies; 40+ messages in thread
From: Peter Todd @ 2024-05-04 17:13 UTC (permalink / raw)
To: Matthew Bagazinski; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 21:29 ` Peter Todd
2024-04-01 12:54 ` Jameson Lopp
@ 2024-04-10 6:57 ` Garlo Nicon
2024-04-22 4:33 ` Ali Sherief
1 sibling, 1 reply; 40+ messages in thread
From: Garlo Nicon @ 2024-04-10 6:57 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-10 6:57 ` Garlo Nicon
@ 2024-04-22 4:33 ` Ali Sherief
0 siblings, 0 replies; 40+ messages in thread
From: Ali Sherief @ 2024-04-22 4:33 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 13:19 [bitcoindev] The Future of Bitcoin Testnet Jameson Lopp
2024-03-31 14:33 ` Luke Dashjr
2024-03-31 16:02 ` Peter Todd
@ 2024-04-01 13:25 ` Andrew Poelstra
2024-04-01 13:32 ` 'Fabian' via Bitcoin Development Mailing List
2024-04-01 14:28 ` Warren Togami
` (4 subsequent siblings)
7 siblings, 1 reply; 40+ messages in thread
From: Andrew Poelstra @ 2024-04-01 13:25 UTC (permalink / raw)
To: Jameson Lopp; +Cc: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-01 13:25 ` Andrew Poelstra
@ 2024-04-01 13:32 ` 'Fabian' via Bitcoin Development Mailing List
0 siblings, 0 replies; 40+ messages in thread
From: 'Fabian' via Bitcoin Development Mailing List @ 2024-04-01 13:32 UTC (permalink / raw)
To: Andrew Poelstra; +Cc: Jameson Lopp, bitcoindev
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 13:19 [bitcoindev] The Future of Bitcoin Testnet Jameson Lopp
` (2 preceding siblings ...)
2024-04-01 13:25 ` Andrew Poelstra
@ 2024-04-01 14:28 ` Warren Togami
2024-04-01 19:22 ` [bitcoindev] " emsit
` (3 subsequent siblings)
7 siblings, 0 replies; 40+ messages in thread
From: Warren Togami @ 2024-04-01 14:28 UTC (permalink / raw)
To: Jameson Lopp; +Cc: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread* [bitcoindev] Re: The Future of Bitcoin Testnet
2024-03-31 13:19 [bitcoindev] The Future of Bitcoin Testnet Jameson Lopp
` (3 preceding siblings ...)
2024-04-01 14:28 ` Warren Togami
@ 2024-04-01 19:22 ` emsit
2024-04-04 8:14 ` Calvin Kim
` (2 subsequent siblings)
7 siblings, 0 replies; 40+ messages in thread
From: emsit @ 2024-04-01 19:22 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread* [bitcoindev] Re: The Future of Bitcoin Testnet
2024-03-31 13:19 [bitcoindev] The Future of Bitcoin Testnet Jameson Lopp
` (4 preceding siblings ...)
2024-04-01 19:22 ` [bitcoindev] " emsit
@ 2024-04-04 8:14 ` Calvin Kim
2024-04-04 12:47 ` Jameson Lopp
2024-04-07 7:20 ` [bitcoindev] " Christian Decker
2024-04-08 19:11 ` Garlo Nicon
2024-04-28 13:45 ` [bitcoindev] " Matt Corallo
7 siblings, 2 replies; 40+ messages in thread
From: Calvin Kim @ 2024-04-04 8:14 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [bitcoindev] Re: The Future of Bitcoin Testnet
2024-04-04 8:14 ` Calvin Kim
@ 2024-04-04 12:47 ` Jameson Lopp
2024-04-05 4:30 ` Calvin Kim
2024-04-07 7:20 ` [bitcoindev] " Christian Decker
1 sibling, 1 reply; 40+ messages in thread
From: Jameson Lopp @ 2024-04-04 12:47 UTC (permalink / raw)
To: Calvin Kim; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] Re: The Future of Bitcoin Testnet
2024-04-04 12:47 ` Jameson Lopp
@ 2024-04-05 4:30 ` Calvin Kim
2024-04-06 23:04 ` David A. Harding
0 siblings, 1 reply; 40+ messages in thread
From: Calvin Kim @ 2024-04-05 4:30 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] Re: The Future of Bitcoin Testnet
2024-04-05 4:30 ` Calvin Kim
@ 2024-04-06 23:04 ` David A. Harding
2024-04-09 16:48 ` Peter Todd
0 siblings, 1 reply; 40+ messages in thread
From: David A. Harding @ 2024-04-06 23:04 UTC (permalink / raw)
To: bitcoindev
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] Re: The Future of Bitcoin Testnet
2024-04-06 23:04 ` David A. Harding
@ 2024-04-09 16:48 ` Peter Todd
2024-04-16 17:30 ` [bitcoindev] " 'Sjors Provoost' via Bitcoin Development Mailing List
0 siblings, 1 reply; 40+ messages in thread
From: Peter Todd @ 2024-04-09 16:48 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-09 16:48 ` Peter Todd
@ 2024-04-16 17:30 ` 'Sjors Provoost' via Bitcoin Development Mailing List
0 siblings, 0 replies; 40+ messages in thread
From: 'Sjors Provoost' via Bitcoin Development Mailing List @ 2024-04-16 17:30 UTC (permalink / raw)
To: bitcoindev; +Cc: David A. Harding, Peter Todd
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] Re: The Future of Bitcoin Testnet
2024-04-04 8:14 ` Calvin Kim
2024-04-04 12:47 ` Jameson Lopp
@ 2024-04-07 7:20 ` Christian Decker
2024-04-07 8:09 ` K Calvin
1 sibling, 1 reply; 40+ messages in thread
From: Christian Decker @ 2024-04-07 7:20 UTC (permalink / raw)
To: Calvin Kim; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] Re: The Future of Bitcoin Testnet
2024-04-07 7:20 ` [bitcoindev] " Christian Decker
@ 2024-04-07 8:09 ` K Calvin
0 siblings, 0 replies; 40+ messages in thread
From: K Calvin @ 2024-04-07 8:09 UTC (permalink / raw)
To: Christian Decker; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* [bitcoindev] Re: The Future of Bitcoin Testnet
2024-03-31 13:19 [bitcoindev] The Future of Bitcoin Testnet Jameson Lopp
` (5 preceding siblings ...)
2024-04-04 8:14 ` Calvin Kim
@ 2024-04-08 19:11 ` Garlo Nicon
2024-04-09 4:29 ` coinableS
2024-04-28 13:45 ` [bitcoindev] " Matt Corallo
7 siblings, 1 reply; 40+ messages in thread
From: Garlo Nicon @ 2024-04-08 19:11 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread* [bitcoindev] Re: The Future of Bitcoin Testnet
2024-04-08 19:11 ` Garlo Nicon
@ 2024-04-09 4:29 ` coinableS
0 siblings, 0 replies; 40+ messages in thread
From: coinableS @ 2024-04-09 4:29 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-03-31 13:19 [bitcoindev] The Future of Bitcoin Testnet Jameson Lopp
` (6 preceding siblings ...)
2024-04-08 19:11 ` Garlo Nicon
@ 2024-04-28 13:45 ` Matt Corallo
2024-05-02 7:10 ` Ali Sherief
7 siblings, 1 reply; 40+ messages in thread
From: Matt Corallo @ 2024-04-28 13:45 UTC (permalink / raw)
To: Jameson Lopp, bitcoindev
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.
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-04-28 13:45 ` [bitcoindev] " Matt Corallo
@ 2024-05-02 7:10 ` Ali Sherief
2024-05-04 17:08 ` Peter Todd
0 siblings, 1 reply; 40+ messages in thread
From: Ali Sherief @ 2024-05-02 7:10 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [bitcoindev] The Future of Bitcoin Testnet
2024-05-02 7:10 ` Ali Sherief
@ 2024-05-04 17:08 ` Peter Todd
0 siblings, 0 replies; 40+ messages in thread
From: Peter Todd @ 2024-05-04 17:08 UTC (permalink / raw)
To: Ali Sherief; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 40+ messages in thread