testnet

Bitcoin's mined public test networks. Regtest is local and you mine it yourself; signet is public but its blocks are signed by a fixed key. Testnet blocks are won by real proof of work from whoever shows up — which is simultaneously the point of the network and its recurring failure mode.

Three generations exist. As of September 2026: testnet3 is deprecated but still shipped, testnet4 is the network you actually get, and testnet5 is a draft BIP with no genesis block mined yet.

Chain selection

Verified against Bitcoin Core master, September 2026 (src/kernel/chainparams.cpp, src/chainparamsbase.cpp, src/util/chaintype.cpp):

The bech32 HRP is tb on testnet3, testnet4 and signet alike, so an address does not tell you which network it belongs to. Genesis blocks differ, so UTXO sets are disjoint and transactions cannot be replayed across them.

bitcoind -testnet4 -daemon
bitcoin-cli -testnet4 getblockchaininfo

testnet3 (2011, deprecated)

Genesis dates to February 2011 (timestamp 1296688602). Years of block storms (see below) burned through the subsidy schedule: the tip was height 5,130,590 on 15 September 2026, i.e. past two dozen halvings, so the coinbase reward is dust and faucets are chronically empty.

Bitcoin Core 28.0 (October 2024) deprecated it in the same release that shipped testnet4. As of Core master in September 2026 the deprecation is still only a warning — src/init.cpp logs:

Warning: Support for testnet3 is deprecated and will be removed in an
upcoming release. Consider switching to testnet4.

The RFC issue that decides the removal, bitcoin/bitcoin#31975 ("when to drop testnet3"), is still open (last touched June 2026). Treat testnet3 as working-today-but-doomed and migrate.

testnet4 (BIP94)

BIP94 (Fabian Jahr), status Deployed, shipped in Core 28.0 (October 2024), selected with -testnet4.

All mainnet consensus rules active at the time of the proposal (2024) are enforced from block 1 — taproot being the newest — plus three testnet-specific rules:

1. 20-minute exception, inherited from testnet3: a block whose timestamp is more than 20 minutes past its parent's MUST use nBits = 0x1d00ffff (difficulty 1), regardless of the real network difficulty. The first block of each difficulty period is exempt and MUST use the real difficulty.
2. Block-storm fix: difficulty retargeting takes its base value from the first block of the previous period, not the last. On testnet3 a min-difficulty last block pinned the next period's difficulty to 1-4, which is what let attackers author whole subsidy epochs in weeks.
3. Time-warp prevention: for a block at height ≡ 0 (mod 2016), nTime MUST be ≥ the previous block's nTime − 600 seconds. Without it, a time warp amplifies rule 1 from difficulty 4 down to difficulty 1.

Network parameters: message start 0x1c163f28 (randomly generated, no meaning), genesis timestamp 1714777860 with coinbase message 03/May/2024 000000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e, hashing to 00000000da84f2bafbbc53dee25a72ae507ff4914b867c565be350b0da8bf043.

The exception is being exploited

BIP94 deliberately kept the 20-minute exception so CPU miners could acquire coins and mine non-standard transactions. That has not held up. Block storms are gone, but the exception is saturated: miners run with the clock pushed forward and take the tip with difficulty-1 blocks, so the chain advances by propagation race rather than by work, and small re-orgs are constant as exception blocks compete for the same height.

Measured on 15 September 2026 via the mempool.space testnet4 API: tip height 152,566; the retarget difficulty for the period beginning at block 151,200 is ≈1.33 × 10⁹; yet 13 of the 15 blocks ending at the tip were difficulty 1.

Anthony Towns' analysis on the bitcoin-dev list (June 2026) counted 192 real-difficulty against 1,824 min-difficulty blocks between heights 135,072 and 137,087, i.e. roughly 90% of testnet4 blocks confirmed without meaningful proof of work. The practical symptom developers report is faucet transactions sitting unconfirmed for 30-60 minutes and then falling out of an almost-empty mempool.

bitcoin/bitcoin#31117 ("miner: Reorg Testnet4 minimum difficulty blocks") proposes a mining-policy mitigation and is still open as of September 2026.

testnet5 (BIP95, draft)

BIP95 "Testnet 5", authors Pol Espinasa and Fabian Jahr, first discussed on the bitcoin-dev list on 2 June 2026, assigned a number on 22 June 2026 and merged into the BIPs repository as a draft on 25 June 2026. Status is Draft as of September 2026; it Requires BIP54 and Replaces BIP94.

Three changes relative to testnet4:

• No difficulty exception at all. Any exception to the PoW rules is exploitable by a motivated attacker, so testnet5 drops the 20-minute rule entirely and matches mainnet.
• Higher minimum difficulty. The PoW limit becomes 0x1a0fffff in compact nBits encoding, a minimum difficulty of approximately 1,000,000. This was rejected for testnet4 only because it would have blocked CPU miners from using the exception; with the exception gone, the argument lapses.
• BIP54 (consensus cleanup) enforced from block 1. Signet already enforces BIP54 via Bitcoin Inquisition, but signet cannot exercise a miner's own enforcement of those rules; testnet5 can.

Other parameters: message start 0x46495645 (ASCII FIVE), default p2p port 18335. The genesis block is a TODO in the BIP — the values printed there are testnet4 placeholders, and the intended Pubkey is a recent mainnet block hash used as a provably-unspendable anti-pre-mine commitment, with the coinbase Message left empty.

Patching testnet4 in place was considered and rejected: deploying a change to a network whose attackers can disrupt the deployment is slow, and anything beyond a band-aid would need a hard fork.

Status of the implementation

bitcoin/bitcoin#35861 "Testnet 5 (BIP95)" (fjahr) has been open as a draft since 1 August 2026. It is stacked on #35793 ("Implement BIP 54 (Consensus Cleanup) without mainnet activation", darosior) and per the PR description will not make the v32 feature freeze; the plan is to settle review, mine a genesis block, start the network outside a release, then ship a patched v32 with testnet5 included. As of September 2026 there is no genesis block, no DNS seeds and no fixed seeds, and -testnet5 does not exist in Core master.

Do not plan on testnet5 for anything with a delivery date. Plan the migration — if your software hardcodes chain parameters, the testnet4 experience says you will be adding another set.

Which network to pick

Signet is the default recommendation for most development precisely because it has no mining race to exploit: block production is authorised by signature, so an attacker cannot flood the tip. Reach for testnet4 when the thing under test is proof of work, difficulty handling, or reorg behaviour — and expect the reorgs.

Common pitfalls

• Assuming -testnet means testnet4. It does not; it is testnet3. The flag, the config section ([test]) and the datadir (testnet3) all disagree with each other, which is its own trap.
• Expecting a testnet3 wallet's coins to show up on testnet4. The genesis blocks differ, so the UTXO sets are disjoint and nothing replays across them.
• Trusting a tb1... address to identify a network. It does not.
• Writing tests that assume testnet4 confirms within N minutes. Confirmation there is currently unreliable; use signet or regtest for anything that must be deterministic.
• Treating a testnet4 block at difficulty 1 as a bug in your validation code. It is the 20-minute exception and it is valid.
• Hardcoding 0x1d00ffff as "the testnet minimum". Testnet5 raises it to 0x1a0fffff.

See also

• signet/SKILL.md
• regtest/SKILL.md
• ../core/operations/SKILL.md
• BIP94: https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki
• BIP95: https://github.com/bitcoin/bips/blob/master/bip-0095.md