* [bitcoindev] Unbreaking testnet4
@ 2025-03-18 14:29 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-18 21:34 ` Melvin Carvalho
` (5 more replies)
0 siblings, 6 replies; 14+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-18 14:29 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
Hi,
Testnet4 was rolled out a year ago to address the shortcomings of testnet3. One of those shortcomings was the difficulty reset creating havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As a result, testnet4 is similarly creating havoc. [2]
The goal of testnet is to mimic the Bitcoin mainnet. This is why it is useful to have in addition to a more control testing environment such as Signet.
The given rationale for a difficulty reset was to let developers occasionally mine blocks on their laptop. But you cannot have your cake and eat it too: either the network is permissionless (PoW) or you assign identities and privileges to some (Signet). By trying to do both at the same time testnet4 created a loophole for abuse. As a result it failed on both count: it neither mimics mainnet nor allows developers to mine active blocks on their laptop.
I propose to fix this by removing the difficulty reset rule from testnet4 through a flag day hard fork on 2026-01-01. I picked a date well in the future to minimize disruption. This leaves enough time for a patch to be reviewed, merged, included in the next major Bitcoin Core release, backported to previous releases and adopted by the infrastructure running on testnet4. That should be enough for a test network.
Let me know what you think,
Antoine
[0] https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com
[1] https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification
[2] [https://fork.observer](https://fork.observer/) - pick the network on the top right corner
--
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/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 3441 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2025-03-18 21:34 ` Melvin Carvalho
2025-03-19 7:01 ` [bitcoindev] " Garlo Nicon
` (4 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Melvin Carvalho @ 2025-03-18 21:34 UTC (permalink / raw)
To: Antoine Poinsot; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3136 bytes --]
út 18. 3. 2025 v 22:24 odesílatel 'Antoine Poinsot' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> napsal:
> Hi,
>
> Testnet4 was rolled out a year ago to address the shortcomings of
> testnet3. One of those shortcomings was the difficulty reset creating
> havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As
> a result, testnet4 is similarly creating havoc. [2]
>
> The goal of testnet is to mimic the Bitcoin mainnet. This is why it is
> useful to have in addition to a more control testing environment such as
> Signet.
>
> The given rationale for a difficulty reset was to let developers
> occasionally mine blocks on their laptop. But you cannot have your cake and
> eat it too: either the network is permissionless (PoW) or you assign
> identities and privileges to some (Signet). By trying to do both at the
> same time testnet4 created a loophole for abuse. As a result it failed on
> both count: it neither mimics mainnet nor allows developers to mine active
> blocks on their laptop.
>
> I propose to fix this by removing the difficulty reset rule from testnet4
> through a flag day hard fork on 2026-01-01. I picked a date well in the
> future to minimize disruption. This leaves enough time for a patch to be
> reviewed, merged, included in the next major Bitcoin Core release,
> backported to previous releases and adopted by the infrastructure running
> on testnet4. That should be enough for a test network.
>
> Let me know what you think,
>
+1 I think this is a great idea. I can dedicate some resources to it, such
as review, running a node, contributing some hash, if necessary, and a
decentralized faucet (that anyone can run) that I've been working on
> Antoine
>
> [0]
> https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification
> [2] https://fork.observer - pick the network on the top right corner
>
> --
> 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/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com
> <https://groups.google.com/d/msgid/bitcoindev/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%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/CAKaEYhKwsLHfv0gYQYZ9MnDVPyQTN6jAfzShaKkS%3Dk2fDfMq0A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4911 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [bitcoindev] Re: Unbreaking testnet4
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-18 21:34 ` Melvin Carvalho
@ 2025-03-19 7:01 ` Garlo Nicon
2025-03-19 7:56 ` [bitcoindev] " Sjors Provoost
2025-03-19 8:32 ` Sjors Provoost
` (3 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: Garlo Nicon @ 2025-03-19 7:01 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3522 bytes --]
> I propose to fix this by removing the difficulty reset rule from testnet4
through a flag day hard fork on 2026-01-01.
You can do that in a soft-fork way. Just rejecting blocks with
difficulty=1, and requiring always a block with the true network
difficulty, is a valid soft-fork.
To better see that, you can imagine, what would happen, if someone would
apply difficulty adjustment rule on mainnet. Then, it would be possible to
temporarily mine a block on a CPU, see it confirmed by your node (and
rejected by the rest of the network), and then, when the next real block
would appear, your client would automatically switch to a stronger chain
(and then, those CPU-mined blocks would be truly worthless).
So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" to
"false", when block time will be greater than unix time "1767225600", then
you will get a valid soft-fork. Non-upgraded clients could then still see
some CPU-mined blocks, but they will disappear, if the hashrate majority
will support your changes, and then old clients will automatically follow
your chain. Also note that a single ASIC block can reorg a lot of CPU-mined
blocks, so it is always guaranteed, that this change will be
chainwork-compatible.
wtorek, 18 marca 2025 o 22:24:49 UTC+1 Antoine Poinsot napisał(a):
> Hi,
>
> Testnet4 was rolled out a year ago to address the shortcomings of
> testnet3. One of those shortcomings was the difficulty reset creating
> havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As
> a result, testnet4 is similarly creating havoc. [2]
>
> The goal of testnet is to mimic the Bitcoin mainnet. This is why it is
> useful to have in addition to a more control testing environment such as
> Signet.
>
> The given rationale for a difficulty reset was to let developers
> occasionally mine blocks on their laptop. But you cannot have your cake and
> eat it too: either the network is permissionless (PoW) or you assign
> identities and privileges to some (Signet). By trying to do both at the
> same time testnet4 created a loophole for abuse. As a result it failed on
> both count: it neither mimics mainnet nor allows developers to mine active
> blocks on their laptop.
>
> I propose to fix this by removing the difficulty reset rule from testnet4
> through a flag day hard fork on 2026-01-01. I picked a date well in the
> future to minimize disruption. This leaves enough time for a patch to be
> reviewed, merged, included in the next major Bitcoin Core release,
> backported to previous releases and adopted by the infrastructure running
> on testnet4. That should be enough for a test network.
>
> Let me know what you think,
> Antoine
>
> [0]
> https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vP...@mail.gmail.com
> <https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com>
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification
> [2] https://fork.observer - pick the network on the top right corner
>
--
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/f0cace2b-d734-4b36-b8a1-d4364a573a19n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5238 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-19 7:01 ` [bitcoindev] " Garlo Nicon
@ 2025-03-19 7:56 ` Sjors Provoost
2025-03-19 8:43 ` Garlo Nicon
0 siblings, 1 reply; 14+ messages in thread
From: Sjors Provoost @ 2025-03-19 7:56 UTC (permalink / raw)
To: Bitcoin Development Mailing List; +Cc: Garlo Nicon
> Op 19 mrt 2025, om 08:01 heeft Garlo Nicon <garlonicon@gmail•com> het volgende geschreven:
>
> > I propose to fix this by removing the difficulty reset rule from testnet4 through a flag day hard fork on 2026-01-01.
>
> You can do that in a soft-fork way. Just rejecting blocks with difficulty=1, and requiring always a block with the true network difficulty, is a valid soft-fork.
Unfortunately it's a hard-fork.
> So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" to "false", when block time will be greater than unix time "1767225600", then you will get a valid soft-fork.
The fPowAllowMinDifficultyBlocks rule says that after 20 minutes the new block MUST have difficulty 1. A block with the real difficulty will be rejected.
This is because in general the block nBits value, which announces how much work the block has, must have an exact value. It can't be higher.
In validation.cpp we have this:
if (block.nBits != GetNextWorkRequired(pindexPrev, &block, consensusParams))
return state.Invalid(BlockValidationResult::BLOCK_INVALID_HEADER, "bad-diffbits", "incorrect proof of work");
Inside GetNextWorkRequired there is the testnet exception rule, which Antoine proposes to drop:
if (params.fPowAllowMinDifficultyBlocks) {
// Special difficulty rule for testnet:
// If the new block's timestamp is more than 2* 10 minutes
// then allow mining of a min-difficulty block.
if (pblock->GetBlockTime() > pindexLast->GetBlockTime() + params.nPowTargetSpacing*2)
return nProofOfWorkLimit;
else
... (same difficulty as last block, unless it's a retarget)
The code comment is misleading, "allow" should be "require".
- Sjors
--
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/688E575D-C370-4D7D-A6DB-11E0B56710B1%40sprovoost.nl.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-18 21:34 ` Melvin Carvalho
2025-03-19 7:01 ` [bitcoindev] " Garlo Nicon
@ 2025-03-19 8:32 ` Sjors Provoost
2025-03-19 9:11 ` Melvin Carvalho
2025-03-19 17:03 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
` (2 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: Sjors Provoost @ 2025-03-19 8:32 UTC (permalink / raw)
To: 'Antoine Poinsot' via Bitcoin Development Mailing List
Cc: Antoine Poinsot
[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]
Antoine Poinsot wrote:
> The given rationale for a difficulty reset was to let developers occasionally mine blocks on their laptop. But you cannot have your cake and eat it too: either the network is permissionless (PoW) or you assign identities and privileges to some (Signet). By trying to do both at the same time testnet4 created a loophole for abuse. As a result it failed on both count: it neither mimics mainnet nor allows developers to mine active blocks on their laptop.
Let me clarify why developers can't mine on their own laptop with testnet4.
The way you would do that is to move your computer clock forward by 20 minutes (or use faketime), at which point the difficulty drops to 1. You would then mine your (presumably non-standard transaction) and broadcast it to the network.
This is also the strategy used to acquire more testnet coins if you don't have an ASIC and don't want to use a faucet.
On testnet3 the latter wasn't very productive because at height 4 million the block subsidy is under 10k sats.
But on testnet4 every block yields 50 tBTC. So several people try to mine such a block, leading to the many parallel forks.
If you're a developer trying to mine a non-standard transaction, you have to be fast, well connected and lucky to be the first block picked up by the rest of the network.
But why mine just one if you can mine many?
Some CPU miners are now mining as many testnet4 blocks as they can by bumping their clock 20 minutes not just once, but several times in a row. Until they run against the limit other nodes put on how far a block can be in the future, namely two hours. So when a real difficulty block appears, you may see 5 blocks on top of it instantly.
This behavior is even worse from the point of view of a developer trying to mine a non-standard transaction. Because the tip of your node is always going to be about two hours in the future, when you mine on top of that by moving your clock even further, it will be rejected by your peers.
So this use case of CPU mining non-standard transactions is simply dead as long as this behaviour exists. We might as well reduce code complexity.
That said, testnet will never mimic mainnet. It has no value, or worse, very little value. So the incentives are different, which leads to different behavior. That's a whack-a-mole game, which we should probably not dedicate time to.
- Sjors
--
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/2064B7F4-B23A-44B0-A361-0EC4187D8E71%40sprovoost.nl.
[-- Attachment #2: Type: text/html, Size: 3788 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-19 7:56 ` [bitcoindev] " Sjors Provoost
@ 2025-03-19 8:43 ` Garlo Nicon
0 siblings, 0 replies; 14+ messages in thread
From: Garlo Nicon @ 2025-03-19 8:43 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3474 bytes --]
It seems you are right. However, this rule is based on block timestamps,
which gives me another idea: what about simply invalidating a block, if the
block time difference is bigger than 20 minutes? Because that's what ASIC
miners would want to do anyway, to reorg a long chain of CPU-mined blocks:
if the difficulty is 12345678, and you can see hundreds of blocks with
difficulty 1, then a single block with difficulty 12345678 will reorg all
of these CPU-mined blocks in a single shot.
By the way: if we are entering a hard-fork territory, and if testnet4 coins
are traded, then what about switching to testnet5 with new rules instead?
And also, in case of any forks, there is a question, how many miners will
actually support new changes. Because in case of new timewarp rules, we saw
hundreds of blocks being reorged, because some ASIC miners didn't upgrade
their code: https://github.com/bitcoin/bitcoin/issues/30786
And even when mempool.space upgraded their code, a few weeks after that, I
could still see some ASIC nodes in the wild, which were mining on the wrong
branch, and with just a CPU, it was possible to fork them once every 2016
blocks, for a few hundred blocks.
środa, 19 marca 2025 o 08:59:26 UTC+1 Sjors Provoost napisał(a):
>
>
> > Op 19 mrt 2025, om 08:01 heeft Garlo Nicon <garlo...@gmail•com> het
> volgende geschreven:
> >
> > > I propose to fix this by removing the difficulty reset rule from
> testnet4 through a flag day hard fork on 2026-01-01.
> >
> > You can do that in a soft-fork way. Just rejecting blocks with
> difficulty=1, and requiring always a block with the true network
> difficulty, is a valid soft-fork.
>
> Unfortunately it's a hard-fork.
>
> > So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" to
> "false", when block time will be greater than unix time "1767225600", then
> you will get a valid soft-fork.
>
>
> The fPowAllowMinDifficultyBlocks rule says that after 20 minutes the new
> block MUST have difficulty 1. A block with the real difficulty will be
> rejected.
>
> This is because in general the block nBits value, which announces how much
> work the block has, must have an exact value. It can't be higher.
>
> In validation.cpp we have this:
>
> if (block.nBits != GetNextWorkRequired(pindexPrev, &block,
> consensusParams))
> return state.Invalid(BlockValidationResult::BLOCK_INVALID_HEADER,
> "bad-diffbits", "incorrect proof of work");
>
> Inside GetNextWorkRequired there is the testnet exception rule, which
> Antoine proposes to drop:
>
> if (params.fPowAllowMinDifficultyBlocks) {
> // Special difficulty rule for testnet:
> // If the new block's timestamp is more than 2* 10 minutes
> // then allow mining of a min-difficulty block.
> if (pblock->GetBlockTime() > pindexLast->GetBlockTime() +
> params.nPowTargetSpacing*2)
> return nProofOfWorkLimit;
> else
> ... (same difficulty as last block, unless it's a retarget)
>
> The code comment is misleading, "allow" should be "require".
>
> - Sjors
--
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/66e51750-56d3-4fc7-b55b-eb838c07adb4n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4198 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-19 8:32 ` Sjors Provoost
@ 2025-03-19 9:11 ` Melvin Carvalho
0 siblings, 0 replies; 14+ messages in thread
From: Melvin Carvalho @ 2025-03-19 9:11 UTC (permalink / raw)
To: Sjors Provoost
Cc: 'Antoine Poinsot' via Bitcoin Development Mailing List,
Antoine Poinsot
[-- Attachment #1: Type: text/plain, Size: 4093 bytes --]
st 19. 3. 2025 v 10:04 odesílatel Sjors Provoost <sjors@sprovoost•nl>
napsal:
> Antoine Poinsot wrote:
>
> The given rationale for a difficulty reset was to let developers
> occasionally mine blocks on their laptop. But you cannot have your cake and
> eat it too: either the network is permissionless (PoW) or you assign
> identities and privileges to some (Signet). By trying to do both at the
> same time testnet4 created a loophole for abuse. As a result it failed on
> both count: it neither mimics mainnet nor allows developers to mine active
> blocks on their laptop.
>
>
> Let me clarify why developers can't mine on their own laptop with testnet4.
>
> The way you would do that is to move your computer clock forward by 20
> minutes (or use faketime), at which point the difficulty drops to 1. You
> would then mine your (presumably non-standard transaction) and broadcast it
> to the network.
>
> This is also the strategy used to acquire more testnet coins if you don't
> have an ASIC and don't want to use a faucet.
>
> On testnet3 the latter wasn't very productive because at height 4 million
> the block subsidy is under 10k sats.
>
> But on testnet4 every block yields 50 tBTC. So several people try to mine
> such a block, leading to the many parallel forks.
>
> If you're a developer trying to mine a non-standard transaction, you have
> to be fast, well connected and lucky to be the first block picked up by the
> rest of the network.
>
> But why mine just one if you can mine many?
>
> Some CPU miners are now mining as many testnet4 blocks as they can by
> bumping their clock 20 minutes not just once, but several times in a row.
> Until they run against the limit other nodes put on how far a block can be
> in the future, namely two hours. So when a real difficulty block appears,
> you may see 5 blocks on top of it instantly.
>
> This behavior is even worse from the point of view of a developer trying
> to mine a non-standard transaction. Because the tip of your node is always
> going to be about two hours in the future, when you mine on top of that by
> moving your clock even further, it will be rejected by your peers.
>
> So this use case of CPU mining non-standard transactions is simply dead as
> long as this behaviour exists. We might as well reduce code complexity.
>
> That said, testnet will never mimic mainnet. It has no value, or worse,
> very little value. So the incentives are different, which leads to
> different behavior. That's a whack-a-mole game, which we should probably
> not dedicate time to.
>
The question I’ve had for some time is why spoofed blocks on testnet4 come
in batches of:
- 6 blocks
-20-minute intervals
- A maximum lead time of 2 hours
If these values were set for early Bitcoin network reasons, would it make
sense to tweak them for testnet4 to improve functionality? Reducing the
maximum lead from 2 hours to 1 hour and limiting batches to 3 blocks
instead of 6 seems like it could mitigate some of the observed issues while
maintaining testnet’s purpose.
Would this be feasible?
>
> - Sjors
>
>
>
> --
> 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/2064B7F4-B23A-44B0-A361-0EC4187D8E71%40sprovoost.nl
> <https://groups.google.com/d/msgid/bitcoindev/2064B7F4-B23A-44B0-A361-0EC4187D8E71%40sprovoost.nl?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/CAKaEYhLNTbA%3DqMuQ5W63jxwUoa2%2Bmpn020NC31JqGzbk0wPF-A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5463 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
` (2 preceding siblings ...)
2025-03-19 8:32 ` Sjors Provoost
@ 2025-03-19 17:03 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
2025-03-20 18:58 ` Melvin Carvalho
2025-03-21 21:20 ` Murch
5 siblings, 0 replies; 14+ messages in thread
From: bitcoin-dev-ml.void867 via Bitcoin Development Mailing List @ 2025-03-19 17:03 UTC (permalink / raw)
Cc: Bitcoin Development Mailing List
> The given rationale for a difficulty reset was to let developers occasionally mine blocks on their laptop.
Your suggestion to unbreak testnet4 makes sense. The need to mine a
non-standard consensus-valid transaction is satisfied as long as there
is a single miner who is willing to accept and mine it. Ideally such
transactions could be submitted on a public interface with some kind
of DoS protection.
Best, void867
--
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/174240385333.6.13961685190897668632.642902301%40slmail.me.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
` (3 preceding siblings ...)
2025-03-19 17:03 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
@ 2025-03-20 18:58 ` Melvin Carvalho
2025-03-21 21:20 ` Murch
5 siblings, 0 replies; 14+ messages in thread
From: Melvin Carvalho @ 2025-03-20 18:58 UTC (permalink / raw)
To: Antoine Poinsot; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3369 bytes --]
út 18. 3. 2025 v 22:24 odesílatel 'Antoine Poinsot' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> napsal:
> Hi,
>
> Testnet4 was rolled out a year ago to address the shortcomings of
> testnet3. One of those shortcomings was the difficulty reset creating
> havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As
> a result, testnet4 is similarly creating havoc. [2]
>
> The goal of testnet is to mimic the Bitcoin mainnet. This is why it is
> useful to have in addition to a more control testing environment such as
> Signet.
>
> The given rationale for a difficulty reset was to let developers
> occasionally mine blocks on their laptop. But you cannot have your cake and
> eat it too: either the network is permissionless (PoW) or you assign
> identities and privileges to some (Signet). By trying to do both at the
> same time testnet4 created a loophole for abuse. As a result it failed on
> both count: it neither mimics mainnet nor allows developers to mine active
> blocks on their laptop.
>
> I propose to fix this by removing the difficulty reset rule from testnet4
> through a flag day hard fork on 2026-01-01. I picked a date well in the
> future to minimize disruption. This leaves enough time for a patch to be
> reviewed, merged, included in the next major Bitcoin Core release,
> backported to previous releases and adopted by the infrastructure running
> on testnet4. That should be enough for a test network.
>
I just built a Taproot web wallet for Testnet4, designed for anyone who
wants to experiment with it. You can log in using either a hex private key
or Nostr. The wallet lets you send coins to an address or a Nostr npub,
receive coins from a faucet, and send an OP_RETURN.
https://testcoin.org/
There may still be some bugs, but hopefully, this gets more people playing
with Testnet4. If you have feature requests, feel free to mail me.
>
> Let me know what you think,
> Antoine
>
> [0]
> https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification
> [2] https://fork.observer - pick the network on the top right corner
>
> --
> 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/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com
> <https://groups.google.com/d/msgid/bitcoindev/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%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/CAKaEYhKxxiQ%2BpkVGunCHgZs6%2BVrjmVsr6BSK7of5%2BK%3Djjc_W6A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5191 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
` (4 preceding siblings ...)
2025-03-20 18:58 ` Melvin Carvalho
@ 2025-03-21 21:20 ` Murch
2025-03-24 7:00 ` Garlo Nicon
2025-03-24 12:25 ` Murch
5 siblings, 2 replies; 14+ messages in thread
From: Murch @ 2025-03-21 21:20 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1.1: Type: text/plain, Size: 1101 bytes --]
Hey Antoine and everyone,
What you suggest makes sense to me. Since the 20-minute difficulty
exception is now exploited perpetually, it doesn’t serve its intended
purpose of allowing developers to mine themselves a few coins easily or
confirm their own non-standard transactions. In that case, it would be
better to not have it at all.
On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development Mailing
List wrote:
> I propose to fix this by removing the difficulty reset rule from
> testnet4 through a flag day hard fork on 2026-01-01.
I would suggest to pick a date that’s not a holiday in many places to
avoid disrupting people’s holiday, how about 2026-01-01 instead?
Cheers,
Murch
--
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/5c13e130-aaa2-4866-be26-7498100e868b%40murch.one.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-21 21:20 ` Murch
@ 2025-03-24 7:00 ` Garlo Nicon
2025-03-31 7:32 ` Saint Wenhao
2025-03-24 12:25 ` Murch
1 sibling, 1 reply; 14+ messages in thread
From: Garlo Nicon @ 2025-03-24 7:00 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1877 bytes --]
> The given rationale for a difficulty reset was to let developers
occasionally mine blocks on their laptop.
It is technically possible to allow CPU users to get some coins, if they
provide some Proof of Work.
Example Script: "OP_SIZE 60 OP_LESSTHAN OP_VERIFY
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
OP_CHECKSIG".
Related topic:
https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937
And because this method is network-independent, and can be deployed
anywhere (all testnets, mainnet, signet, regtest, doesn't matter), then it
is probably a good idea to disable 20 minute rule, that way or another.
poniedziałek, 24 marca 2025 o 02:29:17 UTC+1 Murch napisał(a):
> Hey Antoine and everyone,
>
> What you suggest makes sense to me. Since the 20-minute difficulty
> exception is now exploited perpetually, it doesn’t serve its intended
> purpose of allowing developers to mine themselves a few coins easily or
> confirm their own non-standard transactions. In that case, it would be
> better to not have it at all.
>
> On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development Mailing
> List wrote:
> > I propose to fix this by removing the difficulty reset rule from
> > testnet4 through a flag day hard fork on 2026-01-01.
>
> I would suggest to pick a date that’s not a holiday in many places to
> avoid disrupting people’s holiday, how about 2026-01-01 instead?
>
> Cheers,
> Murch
>
--
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/85db9980-f6c9-48d8-a650-c69f16cd835fn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2428 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-21 21:20 ` Murch
2025-03-24 7:00 ` Garlo Nicon
@ 2025-03-24 12:25 ` Murch
2025-03-24 13:57 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
1 sibling, 1 reply; 14+ messages in thread
From: Murch @ 2025-03-24 12:25 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1.1: Type: text/plain, Size: 1273 bytes --]
Errr, I wrote the same date as you, but I meant a week later, 2026-01-08
instead.
-Murch
On 2025-03-21 14:20, Murch wrote:
> Hey Antoine and everyone,
>
> What you suggest makes sense to me. Since the 20-minute difficulty
> exception is now exploited perpetually, it doesn’t serve its intended
> purpose of allowing developers to mine themselves a few coins easily or
> confirm their own non-standard transactions. In that case, it would be
> better to not have it at all.
>
> On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development Mailing
> List wrote:
> > I propose to fix this by removing the difficulty reset rule from
> > testnet4 through a flag day hard fork on 2026-01-01.
>
> I would suggest to pick a date that’s not a holiday in many places to
> avoid disrupting people’s holiday, how about 2026-01-01 instead?
>
> Cheers,
> Murch
>
--
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/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-24 12:25 ` Murch
@ 2025-03-24 13:57 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
0 siblings, 0 replies; 14+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-24 13:57 UTC (permalink / raw)
To: Murch; +Cc: bitcoindev
Good point on not having the flag day on a holiday. One or two weeks sounds good to me.
On Monday, March 24th, 2025 at 8:25 AM, Murch <murch@murch•one> wrote:
>
>
> Errr, I wrote the same date as you, but I meant a week later, 2026-01-08
> instead.
>
> -Murch
>
> On 2025-03-21 14:20, Murch wrote:
>
> > Hey Antoine and everyone,
> >
> > What you suggest makes sense to me. Since the 20-minute difficulty
> > exception is now exploited perpetually, it doesn’t serve its intended
> > purpose of allowing developers to mine themselves a few coins easily or
> > confirm their own non-standard transactions. In that case, it would be
> > better to not have it at all.
> >
> > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development Mailing
> > List wrote:
> >
> > > I propose to fix this by removing the difficulty reset rule from
> > > testnet4 through a flag day hard fork on 2026-01-01.
> >
> > I would suggest to pick a date that’s not a holiday in many places to
> > avoid disrupting people’s holiday, how about 2026-01-01 instead?
> >
> > Cheers,
> > Murch
>
>
> --
> 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/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.
--
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/vgcVopNpWCowIGaIpVgjsCWyTMjxVKoWtRdDVnTNrM8tYPjKtC6MJ6S-2KxIYdJYgAhG8iNPig-xijwd7DtAm6tHN3T3xgIMUNUSTBYvT_A%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoindev] Unbreaking testnet4
2025-03-24 7:00 ` Garlo Nicon
@ 2025-03-31 7:32 ` Saint Wenhao
0 siblings, 0 replies; 14+ messages in thread
From: Saint Wenhao @ 2025-03-31 7:32 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 890 bytes --]
> But on testnet4 every block yields 50 tBTC. So several people try to mine
such a block, leading to the many parallel forks.
What about lowering the coinbase block reward (with fees), if the
difficulty was resetted? For example: if the real difficulty is equal to
1,000,000, and some CPU miner got 50.01 tBTC, then that miner could simply
receive 5,001 satoshis instead. And the rest of the block reward can be
just timelocked to the future block number, or simply burned (which is
easier to implement).
--
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/896cdecf-6b73-4f50-aa0f-aafb02c93ff8n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 1160 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2025-03-31 20:50 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-18 21:34 ` Melvin Carvalho
2025-03-19 7:01 ` [bitcoindev] " Garlo Nicon
2025-03-19 7:56 ` [bitcoindev] " Sjors Provoost
2025-03-19 8:43 ` Garlo Nicon
2025-03-19 8:32 ` Sjors Provoost
2025-03-19 9:11 ` Melvin Carvalho
2025-03-19 17:03 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
2025-03-20 18:58 ` Melvin Carvalho
2025-03-21 21:20 ` Murch
2025-03-24 7:00 ` Garlo Nicon
2025-03-31 7:32 ` Saint Wenhao
2025-03-24 12:25 ` Murch
2025-03-24 13:57 ` 'Antoine Poinsot' 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