From: "Lukáš Kráľ" <emsit@emsit•sk>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
Date: Tue, 2 Apr 2024 11:36:44 -0700 (PDT) [thread overview]
Message-ID: <c1e32072-55ff-4cca-a56c-09c747e7e4a6n@googlegroups.com> (raw)
In-Reply-To: <CADL_X_dR1ENC9jm76azf_dkbJdeSCSBbPEpTkm71s4i-g_g=WA@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2024-04-02 19:06 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áľ [this message]
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=c1e32072-55ff-4cca-a56c-09c747e7e4a6n@googlegroups.com \
--to=emsit@emsit$(echo .)sk \
--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