Hard Fork 14 Testnet

Hard Fork 14 is coming. Before it goes live on mainnet, we need your help testing it on testnet. Testnet is a separate, isolated network: the coins have no value and nothing you do there touches the real chain. It is the safest place to find problems before the fork.

Hard Fork 14 brings smaller, more efficient transactions (CLSAG signatures and Bulletproofs+), stronger privacy through a larger anonymity set, and a new fair-mining algorithm (CryptoNight-Adaptive v8) that keeps mining competitive on ordinary CPUs.

A multi-step process

Hard Fork 14 is a large upgrade with several separate changes, so we did not test it all at once. Rushing everything into a single testnet would have made it impossible to tell which change caused a problem if something broke. Instead we ran each change on its own testnet first, then ran them together.

• Round 1: new transactions and mining algorithm. CLSAG signatures, Bulletproofs+, and CryptoNight-Adaptive v7 together (PR #117). Complete.
• Round 2: larger ring size. Raised the ring size from 5 to 16 for a bigger anonymity set (PR #124). Complete.
• Round 3: combined run. Everything from rounds 1 and 2 on one chain. Complete.
• Round 4: final run with CryptoNight-Adaptive v8. The mining algorithm replaced and everything merged, exactly as it will ship to mainnet (PR #162). Testing now.

Why a fourth round. CryptoNight-Adaptive v7 turned out to make blocks after the fork several times slower to verify, which makes syncing a node slow. CryptoNight-Adaptive v8 replaces it: it still ties mining to the chain’s own history and still favours ordinary CPUs, and it verifies faster than the algorithm mainnet uses today. A change to the mining algorithm changes which blocks are valid, so it gets its own run before mainnet.

This is the last round before mainnet. Every Hard Fork 14 change is merged and running together: CLSAG signatures, Bulletproofs+, ring size 16, CryptoNight-Adaptive v8, and all the fixes from the earlier rounds. The new algorithm is what most needs your hardware: it should compute the same hash on every CPU and operating system, and the only way to confirm that is on machines that are not ours.

Blocks mined under the new algorithm are not valid under the old one, so Round 4 runs on a brand new testnet. Testnet starts fresh from block 0 and activates Hard Fork 14 at block 1000. Difficulty starts at the floor, so mining with a single CPU core is enough to build the chain, cross the fork, and send transactions.

Once past the fork you should see the change in your own transactions: the ring size goes from 5 to 16, so a CLSAG input grows from 224 to 576 bytes and a typical two-in two-out send goes from roughly 1,461 to 2,209 bytes, paying about 50% more fee. That trade-off buys the larger anonymity set, and seeing those bigger transactions go through is part of what we are confirming.

Note: multisig is disabled in this release, and Ledger hardware wallet support is not available for Hard Fork 14. Wallets using either cannot create transactions after the fork. If you rely on either, now is the time to yell very loudly.

1. Download the Round 4 testnet build

Grab the build for your platform. Keep it separate from your mainnet install. You must use this Round 4 build, builds from the earlier rounds will not follow this chain.

Other platforms (ARMv7 / ARMv8, FreeBSD, iOS, 32-bit) are available from the GitHub build below.

2. Prefer source or other platforms?

Every Hard Fork 14 change is merged, so you can build straight from the master branch. Per-platform CI artifacts are attached to each run in the Actions tab of the repository.

3. Run a testnet node

Start the daemon with the --testnet flag. It uses its own data directory and ports, so it will not touch your mainnet node.

nervad --testnet

Check you are on the right build before syncing. Type status in the daemon console and confirm it reports software version 0.3.0.0-22b929f55. An older or wrong build reports a different commit and will fork off onto a dead chain, this is the most common cause of “I can’t sync” reports.

When the daemon starts, it checks that the new mining algorithm computes correctly on your machine. If it stops at startup with Chain fill known-answer test failed, please report it with your CPU model and operating system: that is the check doing its job on a platform we have not covered.

If the node has trouble finding peers, add a known testnet node:

nervad --testnet --add-priority-node 74.208.52.101:18565

4. Create a testnet wallet

Open the CLI wallet in testnet mode and create a new wallet when prompted. It will connect to your local testnet daemon.

nerva-wallet-cli --testnet

5. Mine to build the chain and cross the fork

Because testnet starts fresh from block 0, difficulty is very low and a single CPU core is plenty to mine blocks quickly. Mining is how the chain grows, how you get test coins, and how we reach and cross Hard Fork 14 at block 1000. In the daemon console:

start_mining <your_testnet_address> 1

Let it run past block 1000, then send some transactions and confirm they are accepted under the new rules.

Two things that are expected rather than bugs. Any transaction still unconfirmed when block 1000 arrives will be rejected and needs sending again, because the old transaction format stops being valid at the fork with no overlap period. And if your node ends up on a different branch of the chain from everyone else, more than 256 blocks deep, it stops accepting that branch and logs a message telling you to run pop_blocks with a number. Run it as given and the node resyncs onto the right chain.

What to test (Round 4)

• Mine with a single CPU core to help build the chain from block 0 across Hard Fork 14 (block 1000)
• After the fork, mine with more threads and tell us your hashrate (show_hr in the daemon console) with your CPU model and thread count. On Windows and Linux, also try starting the daemon with --mining-affinity, which pins one mining thread per physical core, and compare. We are looking for the best thread count on different CPUs.
• Confirm a fresh node syncs cleanly from block 0 all the way past the fork, and reaches the same top block as everyone else. Syncing past block 1000 should not be noticeably slower than before it; if it is, tell us.
• After the fork, send transfers between testnet wallets, with single and multiple recipients, and confirm they go through
• Run a sweep (send your whole balance to one address) after the fork and confirm it builds and sends
• Confirm transactions made after the fork are larger and pay a bit more fee than before, this is the expected cost of the larger ring, not a bug
• Create a wallet and restore a wallet from seed, including a rescan across the fork
• Check that your node and wallet survive being stopped and restarted on either side of the fork
• Try it on different operating systems and hardware, especially anything low powered, 32-bit, or ARM

If anything breaks, a crash, a stuck sync, a rejected block, or a wallet error, that is exactly what we want to hear about.

How to report results

Thank you for helping test Hard Fork 14. This is the last chance to catch something before it reaches mainnet, so every node and every platform we cover makes the fork safer.