Watch-only Wallet

Alice verwahrt ihre Schlüssel in einer Hardware-Wallet und möchte am Handy einen Zahlungseingang prüfen. Dazu überträgt sie die öffentliche Wallet-Konfiguration auf das Telefon, nicht ihre Sicherungswörter. Die App erkennt damit die passenden Adressen und sucht deren Zahlungen im Netzwerk. Alice sieht den Eingang von 20 000 sat, den kleinsten Bitcoin-Einheiten, und seine Bestätigungen, obwohl das Signiergerät ausgeschaltet zu Hause liegt. Das Telefon darf das Geld dadurch nicht ausgeben. Ebenso kann ein Händler seiner Buchhalterin einen Zahlungsüberblick geben, ohne ihr die Schlüssel anzuvertrauen. Entscheidend ist, was tatsächlich importiert wurde: Eine Seed Phrase, also die Wörter zur Wiederherstellung der Schlüssel, würde diese Trennung aufheben. [12]

Auch eine fremde öffentliche Adresse lässt sich in einer Beobachtungs-App hinzufügen. Die Zahl auf dem Bildschirm beweist deshalb nicht, dass der Nutzer das Geld ausgeben oder sämtliche Schulden begleichen kann. Die App summiert gefundene UTXOs, also noch nicht ausgegebene Outputs früherer Zahlungen. Sie findet aber nur, was zu den importierten Angaben und der verfügbaren Historie passt. Fehlende Adressen, eine unvollständige Suche oder ein unzuverlässiger Server können das Bild verzerren. Eine angezeigte Null bedeutet nicht automatisch verlorene Bitcoins; zunächst sind Umfang der Beobachtung und Datenquelle zu prüfen. [8] [9]

Will Alice bezahlen, wählt die App verfügbare UTXOs und bereitet Empfänger, Betrag und Gebühr vor. Der nicht verbrauchte Teil eines Inputs kann als Wechselgeld, auch Change genannt, an die eigene Wallet zurückgehen. Die Angaben lassen sich als PSBT übertragen, das in BIP174 definierte Format für teilweise signierte Bitcoin-Transaktionen. Das separate Gerät erhält so die nötigen Signierdaten ohne eigene UTXO-Datenbank. Alice muss auf dessen vertrauenswürdigem Display tatsächlichen Empfänger, Betrag, Gebühr und Wechselgeld prüfen. Eine manipulierte App könnte einen anderen Zahlungsvorschlag liefern. Auch sighash ist wichtig: Diese Einstellung legt fest, welche Transaktionsteile die Signatur abdeckt. Erst nach Prüfung und Signatur wird die fertige, dem genehmigten Vorschlag und den Wallet-Regeln entsprechende Transaktion gesendet. [2] [10]

Ein erweiterter öffentlicher Schlüssel, kurz xpub, leitet weitere öffentliche Schlüssel eines Wallet-Zweigs ab; allein kann er keine Zahlung signieren. Wer ihn samt Wallet-Regeln erhält, kann jedoch erreichbare Adressen, vergangene und künftige Zahlungen und Guthaben verknüpfen. Das verrät weit mehr als eine Adresse für einen einzelnen Eingang. Ein fremder Server kann aus wiederholten App-Abfragen ein ähnliches Bild gewinnen. Ein eigener Full Node, der die Blockchain selbst prüft, begrenzt diese Weitergabe; eine verschlüsselte oder sonst private Verbindung verbirgt Abfragen nicht vor dem Zielserver. Exportieren Sie nur das benötigte Konto, begrenzen Sie Kopien und schützen Sie Beschriftungen, die Adressen Namen oder Zahlungszwecken zuordnen. [1] [13] [14]

Die folgenden Abschnitte dienen als technische Referenz für Einrichtung und Wiederherstellung. Ein Skript legt Ausgabebedingungen fest; ein Output Descriptor enthält diese Regeln und Angaben zur Adressableitung. Eine HD Wallet erzeugt einen Schlüsselbaum aus einem Seed, also geheimen Ausgangsdaten für die Ableitung der Schlüssel. Non-hardened-Ableitung erzeugt weitere öffentliche Schlüssel aus einem xpub, während Hardened-Ableitung einen privaten Schlüssel benötigt. Multisig legt zusätzlich die erforderliche Anzahl von Signaturen fest. Der Import einer Adresse beobachtet nur ihr Skript, nicht künftige Empfangs- oder Wechselgeldadressen. Ein öffentlicher Schlüssel umfasst verschiedene Skripttypen nur, wenn die Software sie ausdrücklich ableitet. Ein Konto-xpub liefert Non-hardened-Nachkommen, legt aber weder P2PKH, SegWit, Taproot, den internen Zweig noch die Multisig-Signaturschwelle fest. Diese Angaben ergänzt der Deskriptor. Exportieren Sie ihn aus dem richtigen Konto des Signiergeräts mit passendem Netzwerk und Skripttyp; raten Sie den Ableitungspfad, also die Schrittfolge vom Ausgangsschlüssel, nicht. [1] [4] [7]

HD-Wallets trennen meist den Empfangszweig /0/* vom internen Zweig /1/* für Change, also Wechselgeld. Ohne internen Zweig kann Guthaben nach einer Ausgabe scheinbar verschwinden. Ein zu kleiner range, also der Bereich abgeleiteter Adressen, kann Eingänge verbergen. next_index bestimmt die nächste zu erzeugende Adresse; ein abweichender Stand in zwei Programmen kann zur Wiederverwendung von Adressen führen. Halten Sie aktive Deskriptoren, Bereiche und Indizes synchron. Prüfen Sie Empfangsadressen am Signiergerät: Schadsoftware kann sie trotz plausibler Guthabenanzeige austauschen. [6] [9]

Bitcoin Cores importdescriptors verwendet timestamp als Beginn des erneuten Durchsuchens. now überspringt alte Historie, 0 fordert eine Suche ab dem Genesis Block an. Auch range und die Verfügbarkeit alter Blöcke sind entscheidend. active bestimmt, ob der Deskriptor zum Erzeugen neuer Adressen verwendet wird; internal kennzeichnet walletinterne Ausgänge, etwa Wechselgeld. Ein Node mit Pruning, der alte Blöcke zum Platzsparen gelöscht hat, besitzt die nötigen Blöcke möglicherweise nicht mehr. Ein Rescan entdeckt lediglich vorhandene Transaktionen. Bewahren Sie Datum oder Höhe der ersten Nutzung auf und vergleichen Sie die Wiederherstellung mit bekannten Adressen und Transaktionen, nicht nur mit einer Null auf dem Bildschirm. [9] [10]

BIP380 beschreibt eine Sprache für Mengen von Output-Skripten. Das Beispiel wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum enthält Skripttyp, Fingerabdruck des Hauptschlüssels, Herkunftspfad, öffentlichen Kontoschlüssel, Zweig, variablen Index und Prüfsumme. Es ist keine gültige Importangabe. Taproot nutzt tr() gemäß BIP386; BIP389 erlaubt mehrere Pfade in einem Ausdruck. Die Prüfsumme erkennt Übertragungsfehler, bestätigt aber nicht den Urheber. Ein Deskriptor mit xprv enthält einen geheimen Schlüssel und gehört nicht in einen beobachtenden Koordinator. [4] [5] [6] [7]

BIP32 beschreibt eine wichtige Ausnahme: Ein übergeordneter xpub zusammen mit dem privaten Schlüssel eines ausschließlich über Non-hardened-Schritte abgeleiteten Nachkommen erlaubt die Berechnung des übergeordneten privaten Schlüssels. Der xpub allein genügt nicht; gefährlich ist die Kombination. Ein Hardened-Schritt oberhalb des exportierten Kontos verhindert, dass der Angriff diese Grenze überschreitet. Speichern Sie niemals xprv, Seed oder private Schlüssel in der beobachtenden Wallet, ihrer Datenbank oder begleitenden PSBT-Dateien. [1]

Zur Multisig-Beobachtung gehören Signaturschwelle, Skripttyp, xpub jedes Mitunterzeichners, Schlüsselherkunft und -reihenfolge sowie beide Adresszweige. Ein einzelner xpub reicht nicht. Ein verlorener Deskriptor erschwert die Wiederherstellung auch bei intakten Seeds; eine andere Reihenfolge oder Skripteinbettung kann andere Adressen erzeugen. Prüfen Sie Regeln und Beispieladresse auf allen Signiergeräten. Sichern Sie einen Deskriptor mit Prüfsumme oder eine standardisierte Konfiguration und beachten Sie, dass diese die Beziehungen zwischen Mitunterzeichnern offenlegt. [4] [11]

Sichern Sie getrennt von privaten Schlüsseln beide Zweigdeskriptoren, Schlüsselherkunft, Netzwerk, Erstellungsdatum oder -höhe, Bereiche, Indizes, Beschriftungen und Multisig-Regeln. BIP329 überträgt Beschriftungen, ersetzt aber weder Deskriptor noch Historie. Testen Sie die Wiederherstellung in einem separaten Profil oder Testnetz: öffentliche Konfiguration importieren, Historie durchsuchen, alte Adressen beider Zweige und erwartete UTXOs vergleichen, PSBT erstellen und am vorgesehenen Gerät signieren. Prüfen Sie das Ergebnis vor dem Senden. Watch-only ermöglicht Beobachtung und Vorbereitung, verleiht aber keine Ausgabebefugnis. [3] [9] [12]