Subject: Re: [bitcoindev] The Future of Bitcoin Testnet

From: "'Fabian' via Bitcoin Development Mailing List" <[email-masked]>
Date: Mon, 01 Apr 2024 22:01:35 +0000

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 <[email-masked]> 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 [email-masked].
> 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 [email-masked].
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.