From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Jameson Lopp <jameson.lopp@gmail•com>
Cc: Peter Todd <pete@petertodd•org>, Nagaev Boris <bnagaev@gmail•com>,
bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
Date: Mon, 01 Apr 2024 13:37:59 +0000 [thread overview]
Message-ID: <wKrcm6SEjcG_7UmxByP-rDDVajB7-oYJRF9p_BjLe5XVzxVV9nCB8RsTAXcD5vF_rWxUmLK4HOM7zV7U4-kZSUO9Ccj4jEehsbbb7FD45GQ=@wuille.net> (raw)
In-Reply-To: <CADL_X_cmcXxHke089OD_45VRJy5aR+9uj-18bSjXBE7FKwR-Jw@mail.gmail.com>
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.
next prev parent reply other threads:[~2024-04-01 13:55 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 [this message]
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
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='wKrcm6SEjcG_7UmxByP-rDDVajB7-oYJRF9p_BjLe5XVzxVV9nCB8RsTAXcD5vF_rWxUmLK4HOM7zV7U4-kZSUO9Ccj4jEehsbbb7FD45GQ=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=bnagaev@gmail$(echo .)com \
--cc=jameson.lopp@gmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/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