public inbox for
 help / color / mirror / Atom feed
From: "'Fabian' via Bitcoin Development Mailing List" <>
To: Andrew Poelstra <apoelstra@wpsoftware•net>
Cc: Jameson Lopp <jameson.lopp@gmail•com>,
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
Date: Mon, 01 Apr 2024 13:32:23 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <Zgq12xgPpyD9ie0L@camus>

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:

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.


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:
> >
> 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
> Web:
> 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

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

  reply	other threads:[~2024-04-01 13:33 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
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 [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \
    --cc=apoelstra@wpsoftware$(echo .)net \
    --cc=fjahr@protonmail$(echo .)com \
    --cc=jameson.lopp@gmail$(echo .)com \
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