Signet dient gemeinsamen Tests von Bitcoin-Software. Es besitzt eine eigene Kette und Testmünzen. Neue Blöcke müssen neben den üblichen Regeln und Proof of Work eine besondere Netzbedingung erfüllen, im Standard-Signet eine Signaturbedingung. Das erleichtert Tests, setzt aber ein anderes Vertrauensmodell als im Hauptnetz voraus.
Anna möchte sehen, was eine neue Wallet nach dem Senden einer Zahlung und nach deren Bestätigung in einem Block anzeigt. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Auf Signet verwendet sie Testmünzen, etwa aus einem Faucet, einem Dienst, der sie für Versuche verteilt. Das sind keine BTC des Mainnets, also des Bitcoin-Hauptnetzes. Das Protokoll tauscht sie nicht gegen echte Bitcoin um. Auch Adressen brauchen Aufmerksamkeit: Signet teilt einige Testformate mit Testnet. Am Aussehen allein lässt sich das richtige Netz nicht erkennen. [1] [2] [8]
Karl-Johan Alm und Anthony Towns verfassten BIP 325 (das technische Dokument zur Beschreibung von Signet); Bitcoin Core v0.21.0 führte die Unterstützung für Signet ein. Das Programm bietet ein öffentliches Standardnetz, doch ein Team kann eigene Bedingungen für neue Blöcke und eigene Teilnehmer festlegen. „Wir verwenden Signet“ genügt deshalb nicht: Beide Seiten müssen dasselbe Netz nutzen. Die Kennung der Netzwerknachrichten wird aus dieser Bedingung abgeleitet, nicht aus dem Projektnamen. [1] [3] [4]
Ein Full Node, der die Regeln selbständig prüft, kontrolliert weiterhin Transaktionen und Proof of Work, das Ergebnis der für einen Block nötigen Rechenarbeit. Hinzu kommt die besondere Signet-Bedingung. Im Standardnetz reicht Mining allein daher nicht; auch die passende Signatur ist erforderlich. Der Header, die kompakte Übersicht des Blocks, ersetzt diese Zusatzprüfung nicht. Die nötigen Daten befinden sich im Block selbst. [1] [9]
Mit einer digitalen Signatur lässt sich prüfen, ob der Inhaber des passenden privaten Schlüssels eine Nachricht bestätigt hat. Der Schlüssel ist ein geheimer Zahlenwert und wird dabei nicht offengelegt. Wer die Signaturbedingung erfüllen kann, beeinflusst das Hinzukommen von Blöcken. Er kann das Signieren verzögern oder die aufgenommenen Transaktionen beschränken. Annas private Schlüssel erhält er dadurch nicht, und er kann ihren Knoten nicht zur Annahme beliebiger ungültiger Transaktionen zwingen. Die übrigen Regeln gelten weiter. Diese geregelte Teilnahme ist für Tests nützlich und zugleich der Grund, Signet nicht mit dem Sicherheitsmodell des Mainnets gleichzusetzen. [1] [9]
Bei der Entwicklung genügt eine erfolgreiche Zahlung nicht. Das Team muss wissen, wie die Anwendung auf ausbleibende Blöcke oder eine Reorganisation reagiert: Dabei ersetzt der Knoten jüngste Blöcke durch einen anderen gültigen Zweig. Ein koordinierter Test kann dies herbeiführen und prüfen, ob die Wallet Bestätigungen richtig aktualisiert. Signet verspricht keinen unterbrechungsfreien Betrieb. Es macht auch Fehlerfälle planbarer testbar. [1] [5] [6]
Im Testnet ist die Blockerzeugung offen; Schwankungen können gemeinsame Versuche erschweren. Regtest ermöglicht dagegen, Blöcke einfach nach Bedarf zu erzeugen, was sich für eigene automatisierte Tests eignet. Dabei können auch mehrere Rechner verbunden sein; es muss kein isoliertes Programm sein. Signet erfüllt einen anderen Zweck: längere Zusammenarbeit unabhängiger Teilnehmer unter vereinbarten Bedingungen für die Blockerzeugung. Keiner dieser Modi ersetzt sämtliche anderen Tests. [1] [2]
Die sogenannte Challenge ist ein Skript, ein kurzes Programm, das den erforderlichen Nachweis beschreibt. Es kann eine Signatur oder Multisig verlangen, also eine vereinbarte Zahl von Signaturen mehrerer Schlüssel. Ein eigenes Signet kann aber auch OP_TRUE verwenden, eine ohne Signatur erfüllte Bedingung. Dann genügt eine leere Lösung. Präzise ist deshalb „zusätzliche Skriptbedingung“, nicht die Behauptung, jedes Signet brauche immer einen Unterzeichner. [1] [9]
BIP 325 legt eine nichtleere Lösung in besonderen Daten der Coinbase Transaction ab, der ersten Transaktion im Block. Mit der gleichnamigen Börse hat der Begriff hier nichts zu tun. Die Daten erweitern das Commitment aus BIP 141, das den Block an seine Witness-Daten einschließlich Signaturen bindet, und tragen die Kennung 0xecc7daa2. Sie sind keine zusätzliche gewöhnliche Zahlung an den Unterzeichner. Bei einer trivial erfüllbaren Bedingung darf die Zusatzlösung entfallen, nicht automatisch der Rest der Blockregeln. [1] [9] [10]
Wäre die Signatur Teil ihrer eigenen Nachricht, entstünde eine Kreisabhängigkeit. Die Prüfung verwendet deshalb einen abgeänderten Fingerabdruck der Transaktionen mit geleerter Lösung sowie zwei virtuelle Transaktionen. Diese dienen der Berechnung und werden nicht als zusätzliche Zahlungen versendet. Auch die Header-Nonce, die bei der Suche nach Proof of Work veränderte Zahl, gehört nicht zur signierten Nachricht. Ihre Änderung braucht keine neue Signatur; der übrige Block darf deshalb aber nicht beliebig verändert werden. [1] [9]
Anna prüft zuerst, ob Wallet, Knoten und Blockexplorer dasselbe Testnetz verwenden. Ein Blockexplorer ist eine Anwendung, mit der sich Transaktionen und Blöcke eines bestimmten Netzwerks nachschlagen lassen. In Bitcoin Core helfen getblockchaininfo und das Feld signet_challenge, das die eingestellte Bedingung zeigt. Danach beobachtet sie eine tatsächliche Bestätigung statt nur der Meldung „gesendet“ und verwendet eine getrennte Test-Wallet. Ein erfolgreicher Versuch zeigt das Verhalten unter diesen Bedingungen. Er garantiert weder die Sicherheit echter Guthaben noch Widerstandsfähigkeit gegen einen Angreifer im Mainnet. [7] [8]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Nakamoto Consensus, Block Propagation, Initial Block Download, Block Weight, Bitcoin, Bitcoin Core. Auf diesen Eintrag verweisen außerdem Testnet, Miniscript, Dead Man’s Switch.