From: coinableS <coinables@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: The Future of Bitcoin Testnet
Date: Mon, 8 Apr 2024 21:29:55 -0700 (PDT) [thread overview]
Message-ID: <83ec2b84-2255-4ac1-a40c-3f3a04a1c86fn@googlegroups.com> (raw)
In-Reply-To: <6733b634-e6da-4bb3-a3b6-bffa41395e9cn@googlegroups.com>
[-- 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 --]
next prev parent reply other threads:[~2024-04-09 21:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-31 13:19 [bitcoindev] " Jameson Lopp
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
2024-03-31 16:02 ` Peter Todd
2024-03-31 21:01 ` Nagaev Boris
2024-03-31 21:29 ` Peter Todd
2024-04-01 12:54 ` Jameson Lopp
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-02 11:53 ` Jameson Lopp
2024-04-02 18:36 ` Lukáš Kráľ
2024-04-02 19:46 ` Jameson Lopp
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
2024-05-01 15:30 ` Garlo Nicon
2024-05-04 17:13 ` Peter Todd
2024-04-10 6:57 ` Garlo Nicon
2024-04-22 4:33 ` Ali Sherief
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
2024-04-01 19:22 ` [bitcoindev] " emsit
2024-04-04 8:14 ` Calvin Kim
2024-04-04 12:47 ` Jameson Lopp
2024-04-05 4:30 ` Calvin Kim
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
2024-04-07 7:20 ` [bitcoindev] " Christian Decker
2024-04-07 8:09 ` K Calvin
2024-04-08 19:11 ` Garlo Nicon
2024-04-09 4:29 ` coinableS [this message]
2024-04-28 13:45 ` [bitcoindev] " Matt Corallo
2024-05-02 7:10 ` Ali Sherief
2024-05-04 17:08 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83ec2b84-2255-4ac1-a40c-3f3a04a1c86fn@googlegroups.com \
--to=coinables@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox