From: Sjors Provoost <sjors@sprovoost•nl>
To: 'Antoine Poinsot' via Bitcoin Development Mailing List
<bitcoindev@googlegroups.com>
Cc: Antoine Poinsot <darosior@protonmail•com>
Subject: Re: [bitcoindev] Unbreaking testnet4
Date: Wed, 19 Mar 2025 09:32:36 +0100 [thread overview]
Message-ID: <2064B7F4-B23A-44B0-A361-0EC4187D8E71@sprovoost.nl> (raw)
In-Reply-To: <hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU=@protonmail.com>
[-- 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 --]
prev parent reply other threads:[~2025-03-19 9:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 14:29 'Antoine Poinsot' via Bitcoin Development Mailing List
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2064B7F4-B23A-44B0-A361-0EC4187D8E71@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox