A wallet can display a balance, generate an address and show a confirmed payment without holding any spendable mainnet bitcoin. Bitcoin's testing environments deliberately reproduce familiar wallet behavior on separate chains. That makes them useful for rehearsal, provided everyone involved knows which network they are using.
The first distinction is between the ledger and the interface. Changing a wallet's network setting does not convert test coins into BTC. Bitcoin Core defines separate chain parameters and histories for mainnet and its test environments. A successful test payment belongs to the selected chain. Bitcoin Core's network definitions
Four environments with different purposes
Mainnet is the production Bitcoin network, where mistakes can cost real money. It is also Bitcoin Core's default when no different chain is selected. Before experimenting, verify the selection rather than assuming an application opened in its previous testing mode. Core 31.1 network options
Testnet4 is a public proof-of-work test network specified by BIP94. It largely follows mainnet's consensus rules, with changes intended to address problems including rapid bursts of blocks on testnet3. Its special minimum-difficulty rule can help keep blocks moving, but BIP94 also documents circumstances in which the network can stall. It is useful for public-network interaction, not a guarantee of predictable confirmation times. BIP94's design and limitations
Signet adds a block-validation challenge to proof of work. On the default public signet, producing valid blocks requires the appropriate signatures. This enables coordinated testing with more controlled behavior; it also makes block production dependent on those authorized signers. Anyone can use the public network without holding those signing keys. Custom signets can use different challenges, so two applications labeled “signet” need not share a network. BIP325's signet specification, Core's signet settings
Regtest is intended for private experiments. A developer can create a fresh chain and produce blocks on demand, making it useful for repeatable tests of confirmations, spending and recovery workflows. It does not reproduce the uncertainty of independent public miners. The developer documentation describes this control as regtest's central difference. Regtest testing guide
There is also a version trap. Core 28.0 introduced testnet4 support. In Core 31.1, checked on October 16, 2026, the older testnet3 remains selectable but is explicitly deprecated. The option named “testnet” still selects testnet3 in that version. A tutorial's generic reference to “testnet” therefore needs clarification. Core 28.0 release notes, Core 31.1 option definitions
An address prefix is only one check
For native witness addresses, mainnet uses bc1, testnet3, testnet4 and signet use tb1, and regtest uses bcrt1. These settings are visible in Core's network definitions. A tb1 address alone cannot tell you whether a faucet, wallet or explorer is using testnet4 or signet. Core 31.1 address parameters
Confirm the named network at both ends. In Core, getblockchaininfo reports the active chain and, for signet, the challenge. This is more useful than guessing from an address or balance. Match the explorer to that same environment before treating a transaction lookup as evidence of success. Core's blockchain-information interface
Keep production keys separate
A testing label does not make a real recovery phrase safe to expose. BIP39 derives a seed from the mnemonic and optional passphrase; the derivation does not take a network selector. BIP44 can organize Bitcoin and testnet keys into different branches beneath a common master seed. Those branches do not protect a mainnet wallet if its underlying seed is disclosed. BIP39 seed derivation, BIP44 wallet hierarchy
The following is a practical rehearsal workflow, rather than a protocol requirement:
- Create a fresh, test-only wallet using trusted software. Never import the recovery phrase, private keys or wallet backup that protects actual savings into an experimental app.
- Label the wallet, its backup and any screenshots with the exact network. Keep experimental files apart from production backups, and never later use exposed demonstration keys to receive real BTC.
- Obtain a small amount of test coins from a faucet for the selected network, or generate regtest blocks locally. A faucet needs a receiving address, not the secret that authorizes spending. Stop if it asks for your recovery phrase.
- Rehearse receiving, sending and restoring the disposable wallet. Record the software version, network and expected result. Check that the restored wallet can spend its test funds, rather than stopping when a familiar address appears.
A successful rehearsal demonstrates a particular workflow under particular conditions. It does not establish mainnet fee levels, confirmation speed or the security of an unreviewed application. The useful outcome is narrower: understanding the steps while keeping real funds and their secrets outside the experiment.