Testnet

Anna は自分のお金を使う前に、ビットコインの受け取り方と送り方を覚えたいと考えています。Testnet 対応アプリで別のテスト用ウォレットを作り、少量のテストコインを配るサービス、faucet からコインを受け取ります。その一部を同じネットワークの Pavel に送れば、本物の BTC を使わずに、アドレス、取引、承認待ちの流れを確認できます。これは説明のための例で、特定アプリの手順ではありません。すべてのウォレットがこのモードに対応するわけでもありません。テストコインは無料のビットコインではなく、設定を切り替えても送金しても残高を mainnet へ移せません。Faucet が使えないからといって投資目的で買うものでもありません。 [11]

Testnet は本番のビットコイン内にある練習用口座ではありません。独自の Genesis Block から始まる、別のブロックチェーンです。ブロックは取引をまとめて共通の履歴に記録する単位で、Genesis Block はその出発点です。Testnet の UTXO、つまりまだ使われていない取引の出力も独立しています。出力には金額と、それを使うための条件、例えば必要な署名が記録されています。そのため、Anna が一方でコインを受け取っても、もう一方の残高は増えません。プログラムは、通信メッセージの先頭識別子やポートなどの設定でネットワークを区別します。ただし、別のネットワークでもアドレスの見た目が違うとは限りません。秘密鍵は、対応する資金の支出を認める署名をウォレットが作るための秘密のデータです。同じ秘密鍵を使っても、二つの履歴が共通残高のウォレットに統合されることはありません。 [12] [15]

tb1 で始まるアドレスは Testnet3、Testnet4、Signet のいずれでも使われます。Anna と Pavel は具体的なネットワーク名を合わせ、両方のアプリで確認します。「テスト用」というだけでは不十分です。実験には新しい鍵と別のバックアップを使い、本物の資金が入ったウォレットの Seed Phrase（復元用の単語列） をテストアプリに入力しません。モードを変えても、信用できないソフトウェアが安全になるわけではないからです。Faucet に必要なのも、せいぜい公開の受取アドレスであり、復元用の単語や秘密鍵ではありません。ファイル、鍵、バックアップを分けることで、取り違えや実験と個人的な支払いの不要な関連付けを減らせます。 [12] [14]

公開 Testnet は、知らない参加者や誰でも参加できる採掘を相手に試す環境です。Signet もテスト環境ですが、Proof of Work（有効なブロックを見つけるための計算作業） に加えてブロックの条件を満たす必要があり、通常は許可された鍵で作成した署名を使います。そのためブロック生成を調整しやすくなりますが、無停止を保証するものではありません。Regtest は実験を管理したい開発者向けです。自分の環境で、必要なときにブロックを作り、自動テストなどに使えます。Anna がウォレット操作を学ぶだけなら、アプリが対応するネットワークも選択の条件です。どの環境も、そのコインを本番のビットコインへ変換する仕組みではありません。 [10] [11] [16]

Pavel のテスト送金は、少ない手数料ですぐ届くかもしれません。それだけで mainnet の同じ操作に必要な費用は分かりません。利用状況、採掘能力、参加者の動機が違うためです。公開 Testnet では、ブロックを長く待つ、サービスが停止する、ノード（ネットワークのルールを検証するコンピューター）が最近の履歴を別の有効な分岐に置き換える再編成が起きる、といったことがあります。アプリの不具合を見つける助けにはなりますが、すべての障害が意図的という説明は正しくありません。成功したテストが確かめたのは、特定の条件での特定の動作です。鍵の安全な保管や、本物のお金を扱うサービスの耐障害性まで証明したわけではありません。 [10] [2]

古い手順書には、2011 年に始まった Testnet3 が登場します。長い運用の間に、コインの配布や採掘難度の規則に問題が見えてきました。block storms と呼ばれる現象では、短時間に大量のブロックが採掘されます。チェーンの高さが異常に速く伸び、新しいブロックの補助金も、暦から想像する以上の速さで減っていきました。入手しやすい実験用の道具であるはずのコインが売買されることもありました。次の世代は新しい履歴の出発であり、古い残高の再評価ではありません。手順書では Testnet という名前だけでなく、番号まで確認する必要があります。 [1]

Testnet4 は技術提案 BIP 94 で定められ、Bitcoin Core 28.0 から対応しています。新しい Genesis Block に加え、既知の block storms を起こしにくくするため、難度計算とブロックの時刻の規則を変更しました。ただし特例は残っています。難度期間の最初のブロックを除き、前のブロックより時刻が 20 分を超えて先なら、最低難度を使う必要があります。これは支払いが 20 分以内に承認されるという約束ではありません。また、提案時点の 2024 年 5 月に mainnet で有効だった規則変更を最初から適用します。こうした改善でも、本番を完全に再現する障害のない環境にはなりません。 [1] [9]

2026 年 10 月 17 日時点で、Testnet5 の BIP 95 は Draft、つまり作成中の提案です。最低難度の特例を廃止して最低値を上げ、最初のブロックから BIP 54 の提案された合意規則変更を適用する内容です。しかし Genesis Block の確定データや参照実装へのリンクはまだありません。この文書を根拠に、Testnet5 を通常運用されている Bitcoin Core のネットワークとして紹介することはできません。新しい規則をテストしても、mainnet で自動的に有効にはなりません。後日読む場合は、番号の大きさではなく、提案の状態と使うソフトウェアの版の文書を確認してください。 [2]

Bitcoin Core では testnet4 オプションで Testnet4 を選びます。正確なコマンド構文は使う版の文書で確認します。設定ファイルの [test] は Testnet3、[testnet4] は Testnet4 です。データは testnet3、testnet4、signet、regtest の別々のサブディレクトリに保存されます。実行中のプログラムも確認し、getblockchaininfo の chain フィールドでネットワーク識別子を調べます。Genesis Block のハッシュ、同期状態、接続先ノードも照合します。独自の Signet では共通の genesis だけでは不十分で、そのブロック条件も確認が必要です。ウィンドウの名前や似たアドレスは、この確認の代わりになりません。 [8] [12] [13] [14] [10]

Anna はまず、双方のウォレットが同じネットワークを使うことを確認します。それから受取、送信、送信済みと承認済みの違いを試します。復元は独立したテスト用バックアップだけで行います。開発者なら、アプリの再起動、接続先ノードの停止、再編成、誤ったネットワークの拒否も加えられます。手数料関連では、未承認取引を新しい取引で置き換える RBF や、手数料の高い子取引によって未承認の親取引も採掘してもらう動機を作る CPFP を試せます。結果にはネットワーク、ソフトウェアの版、実際に確認した動作を残します。Testnet は本物のお金で避けたい失敗を経験する場所ですが、以後の確認が不要になる証明ではありません。 [11] [9]