RFC: when to drop testnet3

Sjors commented at 4:33 pm on March 3, 2025: member

Testnet3 was deprecated in v28 with the introduction of testnet4. #31974 implements its removal.

Dropping it in v30 seems reasonable to me, but let’s discuss this here as to not clutter the implementation PR.

Note that v29 (coming soon), which includes testnet3, will be supported for a while. See https://bitcoincore.org/en/lifecycle/ @instagibbs wrote:

I’ve said it elsewhere, but I think it deserves a quite long deprecation cycle, along with some data gathering.

We don’t want services not upgrading for fixes because their test environment would break.

e.g., what exchanges with testnet environments have adopted testnet4 (or signet), much less would be ok with removing testnet3?

Does btcd support it? LND? Eclaire? CLN? etc.

Lots of work to be done here imo.

glozow added the label Tests on Mar 3, 2025

glozow added the label Needs Conceptual Review on Mar 3, 2025

fjahr commented at 8:11 pm on March 3, 2025: contributor

I’m guessing we need to weigh the potential pain for those that have built infrastructure on Testnet3 for a while (wallets with lot’s of UTXOs for testing elaborate multisig setups, lightning nodes etc.) with the fact that Testnet3 doesn’t seem to be usable for anyone according to some commenters. It think a mailing list post is in order and if nobody complains for good reason (not “I’m rich there”) then I would even be fine with removal in v30. We can also do a Github grep and reach out to open source projects directly that still have it implemented if the ML post doesn’t seem sufficient alone.

1440000bytes commented at 8:53 pm on March 10, 2025: none

I think testnet3 and testnet4 should be dropped together when testnet5 is available.

https://x.com/0x_orkun/status/1899192195175076144

Sjors commented at 8:10 am on March 11, 2025: member

@1440000bytes I can’t see the X post without an account (or maybe they’re still dealing with a DoS). Can you quote it or post a screenshot?

Dropping testnet4 without first deprecating it, is not the usual way we do things. It also doesn’t really simplify anything, compared to e.g. releasing testnet5, deprecating testnet4 and dropping testnet3 in one release, and then dropping testnet4 in the next release.

1440000bytes commented at 8:26 am on March 11, 2025: none

This link should work: https://xcancel.com/0x_orkun/status/1899192195175076144

Sjors commented at 8:56 am on March 11, 2025: member

At this point, another Bitcoin testnet is becoming unusable for devs, with huge reorgs for months and another likely incoming.

Fork Obsever also shows frequent reorgs on testnet4: https://fork.observer/?network=4

However they don’t look “huge” to me, just frequent. It’s good if you’re trying to write code that robust against reorgs.

Testnet5 is not going to magically fix all problems though. It seems useful to discuss ideas on the bitcoin-dev mailinglist or Delving.

Signet isn’t an option since we need to test hashrate-related proofs for BitVM, but Testnet4 is becoming more painful to use every day.

You can run a custom signet with OP_TRUE as the challenge and it will behave like a normal proof-of-work chain. See https://en.bitcoin.it/wiki/BIP_0325:

There is one other acceptable special case: if a block’s challenge is e.g. OP_TRUE (0x51), where an empty solution would result in success, the block is also considered valid if the signet commitment is absent.

RFC: when to drop testnet3 #31975