[bitcoindev] Testnet 4 difficulty/hashrate

[bitcoindev] Testnet 4 difficulty/hashrate

[Anthony Towns]

On Fri, Jun 05, 2026 at 07:35:27PM +1000, Anthony Towns wrote:
> compared with current mainnet difficulty of ~138T, or testnet4's 
> current difficulty of ~1239M,

If testnet4's current difficulty is D=1239M [0], and there were
no min-difficulty blocks, that would be one thing. But there are
min-difficulty blocks, and sufficient hashrate mining them with the clock
set forward to saturate them. What's the actual hashrate for testnet4
given a reported difficulty D?

[0] https://mempool.space/testnet4/block/000000000000000359f805aea2a5f18671bf98a1106d0cdbbfbe1f341f5e08dc?showDetails=true&view=actual#details

Suppose the "correct" difficulty corresponding with actual hashrate would
be H.  Then real difficulty blocks are found every (D/H * 10 minutes)
on average, and minimum time blocks fill up the rest of the retarget
period. So between blocks 135072 and 137087, I see 192 real-difficulty
blocks and 1824 min-difficulty blocks, suggesting that the real testnet4
difficulty should be H=130M.

The limit on not having D/H=2016 is that with 2016 min-difficulty blocks,
you'd have a retarget period taking up 4 weeks instead of 2 weeks. I think
a real-difficulty block can reset up to 5 or 6 blocks of min-difficulty
time (any more than that would violate median time constraints on behalf
of the real difficulty block, or too-far-in-future constraints on the
min-difficulty blocks), so I think that means that you want at least
1 real block for every 10 or 12 min-difficulty blocks, so a 192:1824
(1:9.5) ratio seems close to the max already.

This also suggests ~90% of testnet4 blocks are being confirmed via
competition in network propagation with only ~10% confirmed via
PoW/hashrate competition.

Cheers,
aj

-- 
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 visit https://groups.google.com/d/msgid/bitcoindev/aiKeSdrUDP8N1Xww%40erisian.com.au.

[bitcoindev] Re: Testnet 4 difficulty/hashrate

[Ali Sherief]

[-- Attachment #1.1: Type: text/plain, Size: 2702 bytes --]

This is having consequences in development workflows. Tests with 
bitcoin-related libraries with this kind of block generation is now almost 
impossible unless you mine your old blocks. For instance, my testnet4 
faucet transactions have been sitting in the almost-empty mempool for 
around 30-60 minutes, never confirm, and then drop out.

It is certainly making developing Bitcoin-related stuff much harder

-Ali

On Friday, June 5, 2026 at 1:28:01 PM UTC+3 Anthony Towns wrote:

> On Fri, Jun 05, 2026 at 07:35:27PM +1000, Anthony Towns wrote:
> > compared with current mainnet difficulty of ~138T, or testnet4's 
> > current difficulty of ~1239M,
>
> If testnet4's current difficulty is D=1239M [0], and there were
> no min-difficulty blocks, that would be one thing. But there are
> min-difficulty blocks, and sufficient hashrate mining them with the clock
> set forward to saturate them. What's the actual hashrate for testnet4
> given a reported difficulty D?
>
> [0] 
> https://mempool.space/testnet4/block/000000000000000359f805aea2a5f18671bf98a1106d0cdbbfbe1f341f5e08dc?showDetails=true&view=actual#details
>
> Suppose the "correct" difficulty corresponding with actual hashrate would
> be H. Then real difficulty blocks are found every (D/H * 10 minutes)
> on average, and minimum time blocks fill up the rest of the retarget
> period. So between blocks 135072 and 137087, I see 192 real-difficulty
> blocks and 1824 min-difficulty blocks, suggesting that the real testnet4
> difficulty should be H=130M.
>
> The limit on not having D/H=2016 is that with 2016 min-difficulty blocks,
> you'd have a retarget period taking up 4 weeks instead of 2 weeks. I think
> a real-difficulty block can reset up to 5 or 6 blocks of min-difficulty
> time (any more than that would violate median time constraints on behalf
> of the real difficulty block, or too-far-in-future constraints on the
> min-difficulty blocks), so I think that means that you want at least
> 1 real block for every 10 or 12 min-difficulty blocks, so a 192:1824
> (1:9.5) ratio seems close to the max already.
>
> This also suggests ~90% of testnet4 blocks are being confirmed via
> competition in network propagation with only ~10% confirmed via
> PoW/hashrate competition.
>
> Cheers,
> aj
>
>

-- 
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 visit https://groups.google.com/d/msgid/bitcoindev/3d57026c-7998-468b-ab72-b57cc2e971f2n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 3801 bytes --]

Re: [bitcoindev] Re: Testnet 4 difficulty/hashrate

['Antoine Poinsot' via Bitcoin Development Mailing List]

[-- Attachment #1: Type: text/plain, Size: 3944 bytes --]

Forwarding my reply to the list, which my mobile client did not cc originally.

-------- Original Message --------
On Saturday, 07/25/26 at 16:11 Antoine Poinsot <darosior@protonmail.com> wrote:

> Hi Ali,
>
> The testnet5 BIP is now ready: https://github.com/bitcoin/bips/blob/master/bip-0095.md .
>
> My understanding is the implementation was blocked on me submitting the BIP 54 patchset to Bitcoin Core. This is now done, so nothing blocks a testnet5 PR to Core anymore. I hope we can get it by Core v32, and a genesis block much earlier than that.
>
> Best regards,
> Antoine
>
> -------- Original Message --------
> On Saturday, 07/25/26 at 14:30 Ali Sherief <ali@notatether.com> wrote:
>
>> This is having consequences in development workflows. Tests with bitcoin-related libraries with this kind of block generation is now almost impossible unless you mine your old blocks. For instance, my testnet4 faucet transactions have been sitting in the almost-empty mempool for around 30-60 minutes, never confirm, and then drop out.
>>
>> It is certainly making developing Bitcoin-related stuff much harder
>>
>> -Ali
>> On Friday, June 5, 2026 at 1:28:01 PM UTC+3 Anthony Towns wrote:
>>
>>> On Fri, Jun 05, 2026 at 07:35:27PM +1000, Anthony Towns wrote:
>>>> compared with current mainnet difficulty of ~138T, or testnet4's
>>>> current difficulty of ~1239M,
>>>
>>> If testnet4's current difficulty is D=1239M [0], and there were
>>> no min-difficulty blocks, that would be one thing. But there are
>>> min-difficulty blocks, and sufficient hashrate mining them with the clock
>>> set forward to saturate them. What's the actual hashrate for testnet4
>>> given a reported difficulty D?
>>>
>>> [0] https://mempool.space/testnet4/block/000000000000000359f805aea2a5f18671bf98a1106d0cdbbfbe1f341f5e08dc?showDetails=true&view=actual#details
>>>
>>> Suppose the "correct" difficulty corresponding with actual hashrate would
>>> be H. Then real difficulty blocks are found every (D/H * 10 minutes)
>>> on average, and minimum time blocks fill up the rest of the retarget
>>> period. So between blocks 135072 and 137087, I see 192 real-difficulty
>>> blocks and 1824 min-difficulty blocks, suggesting that the real testnet4
>>> difficulty should be H=130M.
>>>
>>> The limit on not having D/H=2016 is that with 2016 min-difficulty blocks,
>>> you'd have a retarget period taking up 4 weeks instead of 2 weeks. I think
>>> a real-difficulty block can reset up to 5 or 6 blocks of min-difficulty
>>> time (any more than that would violate median time constraints on behalf
>>> of the real difficulty block, or too-far-in-future constraints on the
>>> min-difficulty blocks), so I think that means that you want at least
>>> 1 real block for every 10 or 12 min-difficulty blocks, so a 192:1824
>>> (1:9.5) ratio seems close to the max already.
>>>
>>> This also suggests ~90% of testnet4 blocks are being confirmed via
>>> competition in network propagation with only ~10% confirmed via
>>> PoW/hashrate competition.
>>>
>>> Cheers,
>>> aj
>>
>> --
>> 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 visit https://groups.google.com/d/msgid/bitcoindev/3d57026c-7998-468b-ab72-b57cc2e971f2n%40googlegroups.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 visit https://groups.google.com/d/msgid/bitcoindev/ovX9nrRj5sJsB_rEKqZMdTd89_saTF9h9IVuFelR-e8TPIilrUD9NJFF-FgJSUWkHkck5eZWlmj2JqtNVaIMcQRnbXXsxEaxb7lboM2_rpQ%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 5293 bytes --]