* [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4
@ 2026-01-18 17:26 'Angelo' via Bitcoin Development Mailing List
2026-01-19 8:40 ` Saint Wenhao
0 siblings, 1 reply; 4+ messages in thread
From: 'Angelo' via Bitcoin Development Mailing List @ 2026-01-18 17:26 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
Hello mailing list.
I have forked Bitcoin Core and modified the code to fix testnet4 by disabling the min difficulty rule after block 150,000: https://github.com/bitcoin/bitcoin/compare/master...batmanbytes:bitcoin:testnet4-fix
The changes in the code are minimal. As I've written in [Bitcointalk](https://bitcointalk.org/index.php?topic=5569103.msg66301279#msg66301279):
> I have introduced int nMinDifficultyBlocksForkHeight which is 0 by default in consensus/params.h, only ever used by the CTestNet4Params class. GetNextWorkRequired and PermittedDifficultyTransition are also modified to check whether min difficulty blocks are enabled, and if yes, whether nMinDifficultyBlocksForkHeight is 0 (which would indicate it is not testnet4).
With no other changes to the code, during the epoch that includes block 150,000 (which already began at block 149,184), we should expect the block interval to increase by roughly sixfold (to about one hour per block). This is because the effective hashrate would correspond to approximately one-sixth of the difficulty. The difficulty increases by about 6x since there are roughly six times more difficulty-1 blocks than blocks at the normal difficulty.
We could modify the code to not suffer from the temporary 1-hour block interval if needed. I'm just interested to see what you think of those changes, so that we can move forward.
--
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/85djL2Ah0Mh9Appt934138jLRE23gGmaIr96y8q-clEmMa_APPZLerKrrUZN524_Diq4pOydQLaEOZ3XBy4-sQIPxYODOHreM5RWuNHILto%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 3404 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 2026-01-18 17:26 [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 'Angelo' via Bitcoin Development Mailing List @ 2026-01-19 8:40 ` Saint Wenhao 2026-01-22 10:56 ` 'Angelo' via Bitcoin Development Mailing List 0 siblings, 1 reply; 4+ messages in thread From: Saint Wenhao @ 2026-01-19 8:40 UTC (permalink / raw) To: Angelo; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 3416 bytes --] > The changes in the code are minimal. Yes, but you need some test cases as well. > We could modify the code to not suffer from the temporary 1-hour block interval if needed. It is not needed. Testnet4 overproduced around 30k blocks, if we count the time between today, and the Genesis Block. If it will take three months, instead of two weeks, to re-adjust the difficulty, then it wouldn't matter that much, because we already have around 1.5 million more coins, than we should have today. Also, rejecting all blocks with CPU difficulty would mean, that the updated network will be stuck from time to time, when ASIC miners will come in, raise the difficulty, and then go away, leaving the rest of the users with halted chain. pon., 19 sty 2026 o 00:35 'Angelo' via Bitcoin Development Mailing List < bitcoindev@googlegroups.com> napisał(a): > Hello mailing list. > > I have forked Bitcoin Core and modified the code to fix testnet4 by > disabling the min difficulty rule after block 150,000: > https://github.com/bitcoin/bitcoin/compare/master...batmanbytes:bitcoin:testnet4-fix > > The changes in the code are minimal. As I've written in Bitcointalk > <https://bitcointalk.org/index.php?topic=5569103.msg66301279#msg66301279>: > > I have introduced int nMinDifficultyBlocksForkHeight which is 0 by default > in consensus/params.h, only ever used by the CTestNet4Params class. > GetNextWorkRequired and PermittedDifficultyTransition are also modified to > check whether min difficulty blocks are enabled, and if yes, whether > nMinDifficultyBlocksForkHeight is 0 (which would indicate it is not > testnet4). > > > With no other changes to the code, during the epoch that includes block > 150,000 (which already began at block 149,184), we should expect the block > interval to increase by roughly sixfold (to about one hour per block). This > is because the effective hashrate would correspond to approximately > one-sixth of the difficulty. The difficulty increases by about 6x since > there are roughly six times more difficulty-1 blocks than blocks at the > normal difficulty. > > We could modify the code to not suffer from the temporary 1-hour block > interval if needed. I'm just interested to see what you think of those > changes, so that we can move forward. > > -- > 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/85djL2Ah0Mh9Appt934138jLRE23gGmaIr96y8q-clEmMa_APPZLerKrrUZN524_Diq4pOydQLaEOZ3XBy4-sQIPxYODOHreM5RWuNHILto%3D%40protonmail.com > <https://groups.google.com/d/msgid/bitcoindev/85djL2Ah0Mh9Appt934138jLRE23gGmaIr96y8q-clEmMa_APPZLerKrrUZN524_Diq4pOydQLaEOZ3XBy4-sQIPxYODOHreM5RWuNHILto%3D%40protonmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CACgYNOLCvOiHSSpU0m9mGZmjH1JYb1S%2B_XfGpOFUV%2BgyJsGNKQ%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 5221 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 2026-01-19 8:40 ` Saint Wenhao @ 2026-01-22 10:56 ` 'Angelo' via Bitcoin Development Mailing List [not found] ` <QivViO7YYXUY_b7I-HibvzwD9dftAUl8Yv4nOSRzlCeY12fdtLC5TcAWtqPodMnBeRQ73WPj_OtrSvWlO5mHyQpRYdWbwvslVtxBHJpSqO8=@protonmail.com> 0 siblings, 1 reply; 4+ messages in thread From: 'Angelo' via Bitcoin Development Mailing List @ 2026-01-22 10:56 UTC (permalink / raw) To: Saint Wenhao; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 5667 bytes --] - Yes, but you need some test cases as well. I added unit tests that test the modified functions in isolation. Check my changes again. Testnet4 fork behavior (4 tests): 1. testnet4_min_difficulty_pre_fork: At height 149,999, min-difficulty blocks ARE allowed (returns powLimit when block is >20min late) 2. testnet4_min_difficulty_at_fork: At height 150,000, min-difficulty blocks are NOT allowed (returns previous difficulty instead) 3. testnet4_min_difficulty_post_fork: At height 150,001, min-difficulty blocks are NOT allowed. 4. testnet4_permitted_difficulty_transition: PermittedDifficultyTransition() is permissive before fork, strict after. Other chains unaffected (3 tests): 5. regtest_min_difficulty_unaffected: Regtest still allows min-difficulty at any height (nMinDifficultyBlocksForkHeight=0 means no fork) 6. mainnet_min_difficulty_unaffected: Mainnet unaffected (fPowAllowMinDifficultyBlocks=false) 7. Existing ChainParams_TESTNET4_sanity already verifies basic testnet4 param sanity. Running the proof-of-work tests, I get no errors detected: > $ ./build/bin/test_bitcoin --run_test=pow_tests > Running 21 test cases... > *** No errors detected > > $ ./build/bin/test_bitcoin --run_test=pow_tests/testnet4* > Running 4 test cases... > > *** No errors detected If you have any other unit tests in mind, let me know, but I think those are enough. - Also, rejecting all blocks with CPU difficulty would mean, that the updated network will be stuck from time to time, when ASIC miners will come in, raise the difficulty, and then go away, leaving the rest of the users with halted chain. The network is already in a halted chain, because empty blocks are propagated faster than non-empty, and transactions are confirmed most often when ASIC miners include them in their blocks. When ASIC miners go away with the current model, the users will have to wait for a much longer time, due to empty blocks. On Monday, January 19th, 2026 at 12:28 PM, Saint Wenhao <saintwenhao@gmail.com> wrote: >> The changes in the code are minimal. > > Yes, but you need some test cases as well. > >> We could modify the code to not suffer from the temporary 1-hour block interval if needed. > > It is not needed. Testnet4 overproduced around 30k blocks, if we count the time between today, and the Genesis Block. If it will take three months, instead of two weeks, to re-adjust the difficulty, then it wouldn't matter that much, because we already have around 1.5 million more coins, than we should have today. > > Also, rejecting all blocks with CPU difficulty would mean, that the updated network will be stuck from time to time, when ASIC miners will come in, raise the difficulty, and then go away, leaving the rest of the users with halted chain. > > pon., 19 sty 2026 o 00:35 'Angelo' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> napisał(a): > >> Hello mailing list. >> >> I have forked Bitcoin Core and modified the code to fix testnet4 by disabling the min difficulty rule after block 150,000: https://github.com/bitcoin/bitcoin/compare/master...batmanbytes:bitcoin:testnet4-fix >> >> The changes in the code are minimal. As I've written in [Bitcointalk](https://bitcointalk.org/index.php?topic=5569103.msg66301279#msg66301279): >> >>> I have introduced int nMinDifficultyBlocksForkHeight which is 0 by default in consensus/params.h, only ever used by the CTestNet4Params class. GetNextWorkRequired and PermittedDifficultyTransition are also modified to check whether min difficulty blocks are enabled, and if yes, whether nMinDifficultyBlocksForkHeight is 0 (which would indicate it is not testnet4). >> >> With no other changes to the code, during the epoch that includes block 150,000 (which already began at block 149,184), we should expect the block interval to increase by roughly sixfold (to about one hour per block). This is because the effective hashrate would correspond to approximately one-sixth of the difficulty. The difficulty increases by about 6x since there are roughly six times more difficulty-1 blocks than blocks at the normal difficulty. >> >> We could modify the code to not suffer from the temporary 1-hour block interval if needed. I'm just interested to see what you think of those changes, so that we can move forward. >> >> -- >> 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/85djL2Ah0Mh9Appt934138jLRE23gGmaIr96y8q-clEmMa_APPZLerKrrUZN524_Diq4pOydQLaEOZ3XBy4-sQIPxYODOHreM5RWuNHILto%3D%40protonmail.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/CACgYNOLCvOiHSSpU0m9mGZmjH1JYb1S%2B_XfGpOFUV%2BgyJsGNKQ%40mail.gmail.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/-XaFaE2DFoVGKF0rABuGC3vtjLoA2zptE5L-xP1FQg3JPwSdc3-AQJZep7AMO3dOYpxD-jK3l2DtoHpz9344ZTQ8vwONoNj8HliVHy4C5fU%3D%40protonmail.com. [-- Attachment #2: Type: text/html, Size: 9686 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <QivViO7YYXUY_b7I-HibvzwD9dftAUl8Yv4nOSRzlCeY12fdtLC5TcAWtqPodMnBeRQ73WPj_OtrSvWlO5mHyQpRYdWbwvslVtxBHJpSqO8=@protonmail.com>]
* [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 [not found] ` <QivViO7YYXUY_b7I-HibvzwD9dftAUl8Yv4nOSRzlCeY12fdtLC5TcAWtqPodMnBeRQ73WPj_OtrSvWlO5mHyQpRYdWbwvslVtxBHJpSqO8=@protonmail.com> @ 2026-01-26 11:36 ` 'Angelo' via Bitcoin Development Mailing List 0 siblings, 0 replies; 4+ messages in thread From: 'Angelo' via Bitcoin Development Mailing List @ 2026-01-26 11:36 UTC (permalink / raw) To: Saint Wenhao; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 8831 bytes --] Made some changes: https://github.com/bitcoin/bitcoin/compare/master...batmanbytes:bitcoin:testnet4-fix - The hardfork activates at block 151200 instead of 150000. The reason is that block 151200 is the start of epoch 75, and this is less prone to error and confusion. - At block 151200, difficulty is reset to 1 million, to compensate for the artificially high difficulty caused by the CPU miners. This would result in a small mining race for epochs 75 to around 78, where miners with hashpower would find blocks in a matter of seconds. The difficulty will then 4x in the 76th epoch, then again 4x, and it goes up until it naturally finds the 10 minute block interval. The number 1 million was selected arbitrarily to get the best of both worlds: (1) it won't result in a block storm (as it would if difficulty was reset to 1) and (2) it won't result in very long block intervals. If there weren't any difficulty reset, and difficulty would just be calculated as normal, it'd take around an hour for a block to be found, and this would mean epoch 75 alone would take around three months instead of two weeks. (Original message is from Bitcointalk) On Saturday, January 24th, 2026 at 10:04 PM, Angelo <bymet4@protonmail.com> wrote: > Made some changes: https://github.com/bitcoin/bitcoin/compare/master...batmanbytes:bitcoin:testnet4-fix > - The hardfork activates at block 151200 instead of 150000. The reason is that block 151200 is the start of epoch 75, and this is less prone to error and confusion. > - At block 151200, difficulty is reset to 1 million, to compensate for the artificially high difficulty caused by the CPU miners. This would result in a small mining race for epochs 75 to around 78, where miners with hashpower would find blocks in a matter of seconds. The difficulty will then 4x in the 76th epoch, then again 4x, and it goes up until it naturally finds the 10 minute block interval. > > The number 1 million was selected arbitrarily to get the best of both worlds: (1) it won't result in a block storm (as it would if difficulty was reset to 1) and (2) it won't result in very long block intervals. If there weren't any difficulty reset, and difficulty would just be calculated as normal, it'd take around an hour for a block to be found, and this would mean epoch 75 alone would take around three months instead of two weeks. > > (Original message is from Bitcointalk) > On Thursday, January 22nd, 2026 at 1:37 PM, 'Angelo' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote: > >> - Yes, but you need some test cases as well. >> >> I added unit tests that test the modified functions in isolation. Check my changes again. >> >> Testnet4 fork behavior (4 tests): >> >> 1. testnet4_min_difficulty_pre_fork: At height 149,999, min-difficulty blocks ARE allowed (returns powLimit when block is >20min late) >> 2. testnet4_min_difficulty_at_fork: At height 150,000, min-difficulty blocks are NOT allowed (returns previous difficulty instead) >> 3. testnet4_min_difficulty_post_fork: At height 150,001, min-difficulty blocks are NOT allowed. >> 4. testnet4_permitted_difficulty_transition: PermittedDifficultyTransition() is permissive before fork, strict after. >> >> Other chains unaffected (3 tests): >> 5. regtest_min_difficulty_unaffected: Regtest still allows min-difficulty at any height (nMinDifficultyBlocksForkHeight=0 means no fork) >> 6. mainnet_min_difficulty_unaffected: Mainnet unaffected (fPowAllowMinDifficultyBlocks=false) >> 7. Existing ChainParams_TESTNET4_sanity already verifies basic testnet4 param sanity. >> Running the proof-of-work tests, I get no errors detected: >> >>> $ ./build/bin/test_bitcoin --run_test=pow_tests >>> Running 21 test cases... >>> *** No errors detected >>> >>> $ ./build/bin/test_bitcoin --run_test=pow_tests/testnet4* >>> Running 4 test cases... >>> >>> *** No errors detected >> >> If you have any other unit tests in mind, let me know, but I think those are enough. >> >> - Also, rejecting all blocks with CPU difficulty would mean, that the updated network will be stuck from time to time, when ASIC miners will come in, raise the difficulty, and then go away, leaving the rest of the users with halted chain. >> >> The network is already in a halted chain, because empty blocks are propagated faster than non-empty, and transactions are confirmed most often when ASIC miners include them in their blocks. When ASIC miners go away with the current model, the users will have to wait for a much longer time, due to empty blocks. >> On Monday, January 19th, 2026 at 12:28 PM, Saint Wenhao <saintwenhao@gmail.com> wrote: >> >>>> The changes in the code are minimal. >>> >>> Yes, but you need some test cases as well. >>> >>>> We could modify the code to not suffer from the temporary 1-hour block interval if needed. >>> >>> It is not needed. Testnet4 overproduced around 30k blocks, if we count the time between today, and the Genesis Block. If it will take three months, instead of two weeks, to re-adjust the difficulty, then it wouldn't matter that much, because we already have around 1.5 million more coins, than we should have today. >>> >>> Also, rejecting all blocks with CPU difficulty would mean, that the updated network will be stuck from time to time, when ASIC miners will come in, raise the difficulty, and then go away, leaving the rest of the users with halted chain. >>> >>> pon., 19 sty 2026 o 00:35 'Angelo' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> napisał(a): >>> >>>> Hello mailing list. >>>> >>>> I have forked Bitcoin Core and modified the code to fix testnet4 by disabling the min difficulty rule after block 150,000: https://github.com/bitcoin/bitcoin/compare/master...batmanbytes:bitcoin:testnet4-fix >>>> >>>> The changes in the code are minimal. As I've written in [Bitcointalk](https://bitcointalk.org/index.php?topic=5569103.msg66301279#msg66301279): >>>> >>>>> I have introduced int nMinDifficultyBlocksForkHeight which is 0 by default in consensus/params.h, only ever used by the CTestNet4Params class. GetNextWorkRequired and PermittedDifficultyTransition are also modified to check whether min difficulty blocks are enabled, and if yes, whether nMinDifficultyBlocksForkHeight is 0 (which would indicate it is not testnet4). >>>> >>>> With no other changes to the code, during the epoch that includes block 150,000 (which already began at block 149,184), we should expect the block interval to increase by roughly sixfold (to about one hour per block). This is because the effective hashrate would correspond to approximately one-sixth of the difficulty. The difficulty increases by about 6x since there are roughly six times more difficulty-1 blocks than blocks at the normal difficulty. >>>> >>>> We could modify the code to not suffer from the temporary 1-hour block interval if needed. I'm just interested to see what you think of those changes, so that we can move forward. >>>> >>>> -- >>>> 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/85djL2Ah0Mh9Appt934138jLRE23gGmaIr96y8q-clEmMa_APPZLerKrrUZN524_Diq4pOydQLaEOZ3XBy4-sQIPxYODOHreM5RWuNHILto%3D%40protonmail.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/CACgYNOLCvOiHSSpU0m9mGZmjH1JYb1S%2B_XfGpOFUV%2BgyJsGNKQ%40mail.gmail.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/-XaFaE2DFoVGKF0rABuGC3vtjLoA2zptE5L-xP1FQg3JPwSdc3-AQJZep7AMO3dOYpxD-jK3l2DtoHpz9344ZTQ8vwONoNj8HliVHy4C5fU%3D%40protonmail.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/IZU5GCk5S4W9V1OE_X77S1ugRZ0wDnvZfYzPNUZBb0vBjCdbImbGmg5gw85WbFRt5pmMIKTc56CkUtBLiDQA4IpSiBqSLvjMLqU_es6qsa0%3D%40protonmail.com. [-- Attachment #2: Type: text/html, Size: 14234 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-02-02 23:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-01-18 17:26 [bitcoindev] Re: [bitcoin-dev] Unbreaking testnet4 'Angelo' via Bitcoin Development Mailing List
2026-01-19 8:40 ` Saint Wenhao
2026-01-22 10:56 ` 'Angelo' via Bitcoin Development Mailing List
[not found] ` <QivViO7YYXUY_b7I-HibvzwD9dftAUl8Yv4nOSRzlCeY12fdtLC5TcAWtqPodMnBeRQ73WPj_OtrSvWlO5mHyQpRYdWbwvslVtxBHJpSqO8=@protonmail.com>
2026-01-26 11:36 ` 'Angelo' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox