From: Garlo Nicon <garlonicon@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
Date: Tue, 9 Apr 2024 23:57:23 -0700 (PDT) [thread overview]
Message-ID: <dd1f43b7-bd02-4fe4-9d69-2fa398c99b4en@googlegroups.com> (raw)
In-Reply-To: <ZgnVtJHn2ikLfwa9@petertodd.org>
[-- 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 --]
next prev parent reply other threads:[~2024-04-15 18:01 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-31 13:19 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 [this message]
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
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=dd1f43b7-bd02-4fe4-9d69-2fa398c99b4en@googlegroups.com \
--to=garlonicon@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