Does anyone still need testnet3?

[Sjors Provoost]

Dear list,

Testnet 4 was proposed last year in BIP94 [0] and is supported by Bitcoin Core since v28.

To make Bitcoin Core easier to maintain we would like to drop support for Testnet3 in a future release. This will happen no earlier than v30 this fall. The upcoming v29 release still supports it, and will throughout its maintenance period [1].

The network itself can't be deleted, so anyone willing to maintain node software themselves can keep using testnet3 until the end of time.

One of the motivations for introducing testnet4 was that testnet3 became increasing impractical to use due to block storms. So perhaps everyone already moved on to using testnet4 or a signet.

As an aside, it's possible to create a pure proof-of-work permissionless signet without any signatures, by setting the challenge to OP_TRUE. [2]

However, if anyone is still using testnet3 and needs more time to move away from it, please let us know. E.g. as a reply to the list or a comment on the Github issue [3]. This could include libraries, staging environments, testnet wallets, etc.

Although the v29 maintenance window will last for a few years, it's also important to know if dropping testnet3 would prevent you from upgrading to the next major node version. In other words, if migrating away from testnet3 would take you longer than all of 2025.

Although "I don't feel like it" isn't a great technical argument, it's still useful to know what to expect and perhaps others can help.

- Sjors

[0] https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki
[1] https://bitcoincore.org/en/lifecycle/#maintenance-period
[2] https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki#specification
[3] https://github.com/bitcoin/bitcoin/issues/31975

[Andreas Schildbach]

Hi Sjors,

thanks for asking.

Bitcoinj has just started to implement testnet4, but it's not finished
yet. And the next version 0.18 will probably not be released within 12
months, maybe longer.

By the way, testnet3 works great for us (for testing). I consider block
storms a feature, because it tests our code in rough conditions. We had
planned to support both testnets in the forseeable future.

https://github.com/bitcoinj/bitcoinj/

Then, there is btc-rpc-explorer, a self-hostable block explorer. It
doesn't yet support testnet4. I'm not affiliated to it, I'm just a user.

https://github.com/janoside/btc-rpc-explorer

Cheers,
Andreas

[Sjors Provoost]

Hi Andreas,

> By the way, testnet3 works great for us (for testing). I consider block storms a feature, because it tests our code in rough conditions. We had planned to support both testnets in the forseeable future.
>
> https://github.com/bitcoinj/bitcoinj/

The "good" news is that testnet4 has very frequent short reorgs. [0]

It appears that people are trying to CPU mine by exploiting the rule that difficulty drops to 1 after 20 minutes. For every real difficulty block that's mined, they instantly publish 5 or 6 blocks, right up against the rule that blocks can't be more than 2 hours in the future.

Another side-effect of that behavior is that on testnet4 MTP is typically in the future, rather than an hour in the past. Combined with the timewarp attack mitigation rule helped reveal some bugs. [1, 2, 3]

There is a potential counter measure [4] that involves re-orging out those low difficulty blocks, though it's just a hackathon proof-of-concept and not likely to be included in Bitcoin Core itself. If anyone were to run it, you'd get even more reorgs to test :-)

- Sjors

[0] https://fork.observer/?network=4
[1] https://github.com/benjamin-wilson/public-pool/commit/4282233d2f11ceecbd0d142e8292ccc9c37ea999
[2] https://github.com/stratum-mining/stratum/pull/1325
[3] https://github.com/bitcoin/bitcoin/pull/31600
[4] https://github.com/bitcoin/bitcoin/pull/31117

[Olaoluwa Osuntokun]

> One of the motivations for introducing testnet4 was that testnet3 became
> increasing impractical to use due to block storms.

FWIW, testnet3 appears to be much more stable than testnet4.

To see why, just take a look at these block tree diagrams from
https://fork.observer/:






The first is testnet3. You can see how it some occasionally re-orgs of depth
1-2, but broadly the block tree is narrow, with most blocks contributing to
the "main chain".

The second is testnet4. Compared to testnet3, it has a very wide block tree
with stale branches of double digit depth. Even with all the special case
difficulty adjustment modifications added, mining on testnet4 appears to
behave much more erratically than on testnet3.

-- Laolu

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/9FAA7EEC-BD22-491E-B21B-732AEA15F556%40sprovoost.nl.

[Melvin Carvalho]

út 18. 3. 2025 v 0:12 odesílatel Olaoluwa Osuntokun <lao...@gmail.com> napsal:

> One of the motivations for introducing testnet4 was that testnet3 became
> increasing impractical to use due to block storms.

FWIW, testnet3 appears to be much more stable than testnet4.

To see why, just take a look at these block tree diagrams from
https://fork.observer/:






The first is testnet3. You can see how it some occasionally re-orgs of depth
1-2, but broadly the block tree is narrow, with most blocks contributing to
the "main chain".

The second is testnet4. Compared to testnet3, it has a very wide block tree
with stale branches of double digit depth. Even with all the special case
difficulty adjustment modifications added, mining on testnet4 appears to
behave much more erratically than on testnet3.

Very good points!

I’ve been running, observing, and using testnet4 for quite a while now. The wide block tree is definitely interesting, though not hugely disruptive if you’re prepared to wait for confirmations.  Deep reorgs disrupt, wide reorgs are not too bad.  Though something worth fixing!

I use testnet4 on an hourly basis to track my productivity, and if you zoom out, here’s an example of how things look over time:

https://mempool.space/testnet4/address/tb1pl224wamnnacv9ha0k37cv7yp8hr8fmshehzuku4q265g28hj5uzqaytqul

Testnet3 is stable now, but a big part of that is because much of the "action" has shifted to testnet4. It also lacks faucets or affordable transactions for developers, whereas testnet4 has several working faucets:

https://github.com/testnet4/awesome-testnet4?tab=readme-ov-file#faucets

I do think we should take a closer look at testnet4. I haven’t personally observed double-digit reorgs, but if they exist, we should definitely track them.

It’s also worth considering that in 10-20 years, deep reorgs will be cheaper on Bitcoin. From that perspective, testnet4 could provide valuable insights into the mechanics and defenses against 51% attacks over the next few epochs. If there’s interest, I’d be happy to do some work on this.

-- Melvin

 

-- Laolu

On Fri, Mar 14, 2025 at 3:56 AM Sjors Provoost <sj...@sprovoost.nl> wrote:

Dear list,

Testnet 4 was proposed last year in BIP94 [0] and is supported by Bitcoin Core since v28.

To make Bitcoin Core easier to maintain we would like to drop support for Testnet3 in a future release. This will happen no earlier than v30 this fall. The upcoming v29 release still supports it, and will throughout its maintenance period [1].

The network itself can't be deleted, so anyone willing to maintain node software themselves can keep using testnet3 until the end of time.

One of the motivations for introducing testnet4 was that testnet3 became increasing impractical to use due to block storms. So perhaps everyone already moved on to using testnet4 or a signet.

As an aside, it's possible to create a pure proof-of-work permissionless signet without any signatures, by setting the challenge to OP_TRUE. [2]

However, if anyone is still using testnet3 and needs more time to move away from it, please let us know. E.g. as a reply to the list or a comment on the Github issue [3]. This could include libraries, staging environments, testnet wallets, etc.

Although the v29 maintenance window will last for a few years, it's also important to know if dropping testnet3 would prevent you from upgrading to the next major node version. In other words, if migrating away from testnet3 would take you longer than all of 2025.

Although "I don't feel like it" isn't a great technical argument, it's still useful to know what to expect and perhaps others can help.

- Sjors

[0] https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki
[1] https://bitcoincore.org/en/lifecycle/#maintenance-period
[2] https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki#specification
[3] https://github.com/bitcoin/bitcoin/issues/31975

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/9FAA7EEC-BD22-491E-B21B-732AEA15F556%40sprovoost.nl.

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs9-658GxK%2BFfTFP%2B3_qwOCzxrE5zrT%3DJU_KYCVB_2ek2Q%40mail.gmail.com.

[Melvin Carvalho]

pá 14. 3. 2025 v 14:01 odesílatel 'Andreas Schildbach' via Bitcoin Development Mailing List <bitco...@googlegroups.com> napsal:

Hi Sjors,

thanks for asking.

Bitcoinj has just started to implement testnet4, but it's not finished
yet. And the next version 0.18 will probably not be released within 12
months, maybe longer.

By the way, testnet3 works great for us (for testing). I consider block
storms a feature, because it tests our code in rough conditions. We had
planned to support both testnets in the forseeable future.

https://github.com/bitcoinj/bitcoinj/

Then, there is btc-rpc-explorer, a self-hostable block explorer. It
doesn't yet support testnet4. I'm not affiliated to it, I'm just a user.

https://github.com/janoside/btc-rpc-explorer

Main issue with testnet3 is getting coins for developers to use it, especially with high fees.

A neat idea might be to make an app to swap between testnet3 and testnet4 coins.  Or even an AMM.

If there's a decent amount of interest in this, I could give it a go.

 

Cheers,
Andreas


On 14/03/2025 09.52, Sjors Provoost wrote:
> Dear list,
>
> Testnet 4 was proposed last year in BIP94 [0] and is supported by Bitcoin Core since v28.
>
> To make Bitcoin Core easier to maintain we would like to drop support for Testnet3 in a future release. This will happen no earlier than v30 this fall. The upcoming v29 release still supports it, and will throughout its maintenance period [1].
>
> The network itself can't be deleted, so anyone willing to maintain node software themselves can keep using testnet3 until the end of time.
>
> One of the motivations for introducing testnet4 was that testnet3 became increasing impractical to use due to block storms. So perhaps everyone already moved on to using testnet4 or a signet.
>
> As an aside, it's possible to create a pure proof-of-work permissionless signet without any signatures, by setting the challenge to OP_TRUE. [2]
>
> However, if anyone is still using testnet3 and needs more time to move away from it, please let us know. E.g. as a reply to the list or a comment on the Github issue [3]. This could include libraries, staging environments, testnet wallets, etc.
>
> Although the v29 maintenance window will last for a few years, it's also important to know if dropping testnet3 would prevent you from upgrading to the next major node version. In other words, if migrating away from testnet3 would take you longer than all of 2025.
>
> Although "I don't feel like it" isn't a great technical argument, it's still useful to know what to expect and perhaps others can help.
>
> - Sjors
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki
> [1] https://bitcoincore.org/en/lifecycle/#maintenance-period
> [2] https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki#specification
> [3] https://github.com/bitcoin/bitcoin/issues/31975
>

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7c28f8e9-d221-4633-8b71-53b4db07fa78%40schildbach.de.

[Garlo Nicon]

> A neat idea might be to make an app to swap between testnet3 and testnet4 coins.  Or even an AMM.

With 1:1 ratio? Because now, on centralized exchanges, you have 300 satoshis per 1 tBTC3, and 25 satoshis per 1 tBTC4. Which means, that 1 tBTC3 would be worth 12 tBTC4.

So, if you create some app, which will use significantly different exchange rate, then it will be quickly abused.

[Sanket Kanjalkar]

Hi Sjors, 

Thanks for asking. Block/Cashapp relies on testnet3 and can't migrate to testnet4 mostly because of lack of lightning LND peers.
I don't think there are any LND Lightning peers on testnet4. We (Block/Cashapp lightning) use LDK for Lightning, but most of our peers run LND. LND support for testnet4 was just merged, so it’ll likely take time for the LND community to update node infrastructure.
We want to catch peering, business logic and lightning implementations interoperability issues in testnet. Even though LDK supports testnet4, switching now isn’t viable for us until our mainnet LND peers migrate. 

Thanks,
Sanket

[Sjors Provoost]

Hi Sanket,

I've heard before from some lightning folks that migrating to testnet4 presents a chicken-egg problem.

If we were to start rotating test networks a frequency of e.g. once every three years, this would become a recurring problem.

Lightning seems to be a special case because it relies heavily on interoperability, and so any move has to be coordinated between multiple parties each with their own priorities.

At the same time Lightning software often needs the latest and greatest Bitcoin Core version e.g. for its new policy features. So sticking to v29 back-ports isn't a long term viable option.

I think it's worth considering for the lightning industry to organize a custom signet, either a 1-of-N with keys distributed among the current players, or unsigned proof-of-work based (more hassle, but future new players may feel more comfortable joining). Such a network can be kept online definitely and its replacement can be more easily coordinated. Another advantage is that soft fork proposals can be tested, similar to how Inquisition does that on the default signet, but at a pace that matches Bolt spec work.

- Sjors