Delivery-date: Mon, 01 Apr 2024 15:06:22 -0700
Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 185.70.43.16 as permitted sender) client-ip=185.70.43.16;
Date: Mon, 01 Apr 2024 22:01:35 +0000
To: Andrew Poelstra <apoelstra@wpsoftware.net>
From: "'Fabian' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
Message-ID: <06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE=@protonmail.com>
In-Reply-To: <ZgrCxWxMkiAt2Tg2@camus>
References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com> <ZgmJFfXnQddkTQVq@petertodd.org> <CAFC_Vt7zKvMEfQLzWHQ6t_9bgv1iqt4Ah8N883CuoSfmLUKdMA@mail.gmail.com> <ZgnVtJHn2ikLfwa9@petertodd.org> <CADL_X_cmcXxHke089OD_45VRJy5aR+9uj-18bSjXBE7FKwR-Jw@mail.gmail.com> <wKrcm6SEjcG_7UmxByP-rDDVajB7-oYJRF9p_BjLe5XVzxVV9nCB8RsTAXcD5vF_rWxUmLK4HOM7zV7U4-kZSUO9Ccj4jEehsbbb7FD45GQ=@wuille.net> <ZgrCxWxMkiAt2Tg2@camus>
Feedback-ID: 5067558:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Reply-To: Fabian <fjahr@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hi,

removing the special rule and moving to a reduced block interval sounds lik=
e a good and simple solution.

Another idea: Keep the current exception logic and adapt the difficulty adj=
ustment code (`CalculateNextWorkRequired`) to look for the last block that =
didn't have difficulty 1 and use that block's difficulty as the basis for t=
he 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/9913549637706749f0af5d326f949=
bd652cbd5f8).

Best,
Fabian


On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra <apoelstra@wpsoftwar=
e.net> wrote:

> On Mon, Apr 01, 2024 at 01:37:59PM +0000, Pieter Wuille wrote:
>=20
> > 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 en=
abling 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 bl=
ock interval (say a few days instead of 2 weeks) if that's not deemed to co=
mplex to implement across the ecosystem, but I don't think it's that import=
ant.
>=20
>=20
> 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.
>=20
> This would be much easier than the existing situation where we have
> special-case logic for testnet the difficulty-1 target.
>=20
> 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.
>=20
>=20
> 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
>=20
> * 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
>=20
> Which puts us in the "this rule would never be triggered unless
> literally everyone stopped mining" corner of the design space.
>=20
>=20
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
>=20
> The sun is always shining in space
> -Justin Lewis-Webster
>=20
> --
> 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/msgi=
d/bitcoindev/ZgrCxWxMkiAt2Tg2%40camus.

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7c=
KIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%3D%40protonmail.com.