Testnet 4 difficulty/hashrate
3 messages, 5 Jun to 26 Jul 2026. Started by Anthony Towns.
Anthony Towns, Ali Sherief, Antoine Poinsot
On Fri, Jun 05, 2026 at 07:35:27PM +1000, Anthony Towns wrote:
Quoted text (2 lines)
> 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
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:
Quoted text (37 lines)
> 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 > >
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:
Quoted text (58 lines)
> 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.