Testnet

Anna möchte den Empfang und Versand von Bitcoin kennenlernen, bevor sie eigenes Geld verwendet. In einer Anwendung mit Testnet-Unterstützung erstellt sie eine separate Test-Wallet. Ein Faucet, ein Dienst zur Ausgabe kleiner Mengen Testcoins, gibt ihr Guthaben, von dem sie etwas an Pavel im selben Netz sendet. Sie sieht eine Adresse, eine Transaktion und das Warten auf Bestätigung, ohne echte BTC auszugeben. Das ist ein Beispiel, keine Anleitung für eine bestimmte App: Nicht jede Wallet bietet diesen Modus. Testcoins sind keine geschenkten Bitcoin. Ihr Guthaben lässt sich weder auf Mainnet umschalten noch dorthin übertragen. Ein unerreichbarer Faucet ist auch kein Grund, sie als Geldanlage zu kaufen. [11]

Testnet ist kein Übungskonto innerhalb des Hauptnetzes. Es ist eine andere Blockkette mit einem eigenen Genesis Block. Ein Block bündelt Transaktionen in der gemeinsamen Historie; der Genesis Block ist deren Anfang. Auch die UTXO, also noch nicht ausgegebene Transaktionsausgänge, gehören zu dieser Kette. Ein Ausgang legt einen Betrag und die Bedingungen für dessen Ausgabe fest, etwa eine erforderliche Signatur. Ein Zahlungseingang bei Anna erzeugt daher kein Guthaben im anderen Netz. Programme unterscheiden die Netze anhand ihrer Parameter, etwa der Kennungen am Anfang von Netzwerknachrichten und der Ports. Unterschiedliche Netze haben aber nicht zwingend sichtbar unterschiedliche Adressen. Ein privater Schlüssel ist eine geheime Information, mit der die Wallet eine Signatur zur Freigabe der zugehörigen Mittel erstellt. Selbst identische private Schlüssel machen aus beiden Historien keine gemeinsame Wallet mit einem gemeinsamen Guthaben. [12] [15]

Adressen mit tb1 können zu Testnet3, Testnet4 oder Signet gehören. Anna und Pavel vereinbaren deshalb das genaue Netz und prüfen es in beiden Anwendungen; „Testnetz“ allein reicht nicht. Anna nutzt für Versuche neue Schlüssel und eine separate Sicherung. Die Seed Phrase (die Wiederherstellungswörter) einer Wallet mit echtem Guthaben gibt sie nicht in eine Testanwendung ein. Ein Moduswechsel macht eine nicht vertrauenswürdige Software nicht sicher. Auch ein Faucet benötigt höchstens eine öffentliche Empfangsadresse, niemals Wiederherstellungswörter oder einen privaten Schlüssel. Getrennte Wallet-Dateien, Schlüssel und Sicherungen verringern Verwechslungen und unerwünschte Verbindungen zwischen Tests und persönlichen Zahlungen. [12] [14]

Öffentliches Testnet dient Versuchen mit unbekannten Teilnehmern und offenem Mining. Auch Signet ist eine Testumgebung, verlangt aber zusätzlich zu Proof of Work (der Rechenarbeit zum Finden eines gültigen Blocks) die Erfüllung einer Blockbedingung, üblicherweise eine mit berechtigten Schlüsseln erstellte Signatur. So lässt sich die Blockproduktion besser koordinieren; einen unterbrechungsfreien Betrieb garantiert das nicht. Regtest eignet sich, wenn Entwickler den Versuch kontrollieren müssen: Sie betreiben ihre eigene Umgebung und erzeugen Blöcke bei Bedarf, etwa für automatisierte Tests. Lernt Anna nur die Wallet-Bedienung, ist außerdem entscheidend, welche Netze ihre App unterstützt. Keines dieser Netze wandelt seine Coins in Mainnet-Bitcoin um. [10] [11] [16]

Pavels Testzahlung kommt möglicherweise schnell und günstig an. Daraus lässt sich nicht ableiten, was derselbe Vorgang auf Mainnet kostet. Auslastung, Rechenleistung der Miner und Anreize der Teilnehmer unterscheiden sich. Ein öffentliches Testnet kann lange auf einen Block warten, einen Dienstausfall oder eine Reorganisation erleben: Dabei ersetzen Nodes, also Computer, die die Netzwerkregeln prüfen, einen jüngeren Teil der Historie durch einen anderen gültigen Zweig. Solche Situationen helfen, Anwendungsfehler aufzudecken. Es wäre aber falsch, jede Störung als beabsichtigt zu bezeichnen. Ein erfolgreicher Test prüft bestimmtes Verhalten unter bestimmten Bedingungen. Er belegt allein weder sichere Schlüsselverwahrung noch die Belastbarkeit eines Dienstes mit echtem Geld. [10] [2]

Ältere Anleitungen nennen Testnet3, das 2011 startete. Im langen Betrieb zeigten sich Probleme bei der Coin-Verteilung und den Regeln für die Mining-Schwierigkeit. Sogenannte block storms waren Serien sehr schnell gefundener Blöcke: Die Kettenhöhe wuchs ungewöhnlich rasch und die neu ausgegebene Belohnung pro Block sank schneller, als der Kalender vermuten ließ. Testcoins wurden sogar gehandelt, obwohl sie ein leicht verfügbares Hilfsmittel sein sollten. Eine neue Generation beginnt deshalb eine neue Historie; sie bewertet alte Guthaben nicht neu. Prüfen Sie in Anleitungen die Netznummer, nicht nur den Namen Testnet. [1]

Der technische Vorschlag BIP 94 beschreibt Testnet4; Bitcoin Core 28.0 brachte die Unterstützung. Neben einem neuen Genesis Block änderte es die Schwierigkeitsberechnung und Regeln für Blockzeitstempel, um bekannte Ursachen von block storms einzudämmen. Eine Sonderregel blieb: Außer beim ersten Block einer Schwierigkeitsperiode verlangt ein Zeitstempel mehr als 20 Minuten nach dem vorherigen Block die minimale Schwierigkeit. Das verspricht keine Zahlungsbestätigung innerhalb von 20 Minuten. Testnet4 wendet außerdem von Anfang an jene Regeländerungen an, die bei seiner Vorstellung im Mai 2024 auf Mainnet aktiv waren. Auch diese Verbesserungen machen es nicht zum störungsfreien Modell des Hauptnetzes. [1] [9]

Am 17. Oktober 2026 trägt BIP 95 zu Testnet5 den Status Draft, also Entwurf. Vorgeschlagen werden die Abschaffung der Ausnahme für minimale Schwierigkeit, die Anhebung dieses Minimums und BIP 54 ab dem ersten Block. BIP 54 enthält vorgeschlagene Änderungen der Konsensregeln. Im Dokument fehlen jedoch noch endgültige Genesis-Block-Daten und ein Link zur Referenzimplementierung. Daraus lässt sich daher kein regulär bereitgestelltes Bitcoin-Core-Netz Testnet5 ableiten. Das Testen neuer Regeln aktiviert sie auch nicht auf Mainnet. Wer den Text später liest, sollte den Vorschlagsstatus und die Dokumentation seiner Softwareversion prüfen, statt sich auf die höhere Nummer zu verlassen. [2]

In Bitcoin Core wählt die Option testnet4 Testnet4 aus; die genaue Befehlsschreibweise steht in der Dokumentation der jeweiligen Version. In der Konfigurationsdatei steht [test] für Testnet3 und [testnet4] für Testnet4. Daten liegen in getrennten Unterverzeichnissen testnet3, testnet4, signet oder regtest. Wichtig ist auch die Prüfung des laufenden Programms: getblockchaininfo liefert die Netzkennung im Feld chain. Prüfen Sie zusätzlich den Hash des Genesis Blocks, den Synchronisationsstand und die verbundenen Nodes. Bei einem eigenen Signet genügt der gemeinsame Genesis Block nicht; auch dessen konkrete Blockbedingung muss stimmen. Ein Fenstertitel oder eine ähnlich aussehende Adresse ersetzt das nicht. [8] [12] [13] [14] [10]

Anna prüft zuerst, ob beide Wallets dasselbe Netz verwenden. Dann probiert sie Empfang, Versand und die Unterscheidung zwischen gesendeter und bestätigter Zahlung aus. Eine Wiederherstellung testet sie nur mit einer separaten Testsicherung. Entwickler können Neustarts, unerreichbare Nodes, Reorganisationen oder die Ablehnung eines falschen Netzes ergänzen. Bei Gebühren helfen Tests von RBF, dem Ersetzen einer unbestätigten Transaktion, und CPFP: Eine höher vergütete Folgetransaktion motiviert Miner, auch ihren unbestätigten Vorgänger aufzunehmen. Zum Ergebnis gehören Netz, Softwareversion und tatsächlich geprüftes Verhalten. Testnet ist ein guter Ort für Fehler, die man mit echtem Geld vermeiden möchte; es beweist nicht, dass weitere Prüfungen überflüssig sind. [11] [9]