HD Wallet

Alice öffnet die Empfangsansicht, und ihre Wallet zeigt eine Adresse. Darauf erhält sie 10 000 Satoshis, die kleinen Einheiten von Bitcoin. Für die nächste Zahlung bietet die App eine andere Adresse an, auf der 20 000 Satoshis eingehen. Sind dies ihre einzigen noch nicht ausgegebenen Eingänge, zeigt die Wallet insgesamt 30 000 Satoshis. Die neue Adresse hat kein eigenständiges Konto erzeugt, und das frühere Geld wurde nicht automatisch verschoben. Die App verwaltet die Schlüssel für beide Eingänge. Eine HD Wallet macht das praktikabel. HD steht für Hierarchical Deterministic: hierarchisch, weil die Schlüssel eine verzweigte Struktur bilden, und deterministisch, weil derselbe Seed und derselbe Pfad immer dieselben Schlüssel ergeben, auch bei der Wiederherstellung. Ein Pfad ist eine Zahlenfolge, die festlegt, welchen Zweig und welchen Schlüssel das Programm berechnen soll. Beim Empfang muss Alice sich gewöhnlich nicht damit befassen; bei der Wiederherstellung müssen aber die richtigen Pfade verwendet werden. Eine Sicherung des Ausgangsgeheimnisses kann daher auch zukünftige Adressen abdecken. Die Wallet-Einstellungen müssen trotzdem erhalten bleiben. Neue Adressen vermeiden die Wiederverwendung von Adressen, garantieren für sich allein jedoch keine Anonymität. [1] [12]

Ein erweiterter öffentlicher Schlüssel, meist xpub genannt, erlaubt die Berechnung öffentlicher Schlüssel eines Teils dieser Struktur. Er enthält nicht die privaten Schlüssel zum Signieren von Zahlungen. Ein xpub allein kann daher keine Coins ausgeben; zum Erzeugen konkreter Adressen muss die App zusätzlich deren Format kennen. Eine Watch-only-Wallet kann mit einem passenden xpub Adressen erzeugen und Zahlungen verfolgen, ohne Signierschlüssel zu besitzen. Ein offengelegter xpub kann jedoch vergangene und zukünftige Adressen des Zweigs, Guthaben und Transaktionen verknüpfen. Teilen Sie nur den benötigten Zweig. Auch ein korrekter xpub verhindert nicht, dass ein kompromittierter Computer eine fremde Adresse anzeigt. Prüfen Sie die Empfangsadresse auf einem vertrauenswürdigen Signiergerät, das die Wallet kennt. [1] [12] [14]

Ein Shop kann für jede Bestellung eine andere Adresse erzeugen. Die Website muss diese Adressen kennen, sollte aber keine Schlüssel zum Ausgeben der Einnahmen besitzen. BIP32 trennt diesen Empfangszweig vom Rest der Wallet. Pieter Wuille verfasste den Vorschlag; zugewiesen wurde er am 11. Februar 2012. Er ist ein Wallet-Standard, keine Konsensregel. BIP39-Sicherungswörter, Skripttypen und das vollständige Wiederherstellungsverfahren gehören zu anderen Ebenen. [1] [11] [12]

BIP32 ergänzt den Schlüssel um einen 256-Bit-Chain-Code, also 32 Byte für weitere Ableitungen. Die private Form besteht aus dem secp256k1-Skalar k und Chain-Code c; die öffentliche verwendet K = point(k) und dasselbe c. Der Hauptschlüssel entsteht durch HMAC-SHA512 mit der exakten Zeichenfolge „Bitcoin seed“ als Funktionsschlüssel und dem Seed als Daten. Die linken 32 Byte liefern den privaten Schlüsselkandidaten, die rechten 32 den Chain-Code. Null oder ein Wert mindestens gleich der Kurvenordnung n macht den Hauptschlüssel ungültig. [1]

Ableitung ist eine Berechnung, keine Suche in einer gespeicherten Liste. Es gibt normale und hardened-Ableitung. Bei der normalen Ableitung lassen sich weitere öffentliche Schlüssel aus dem erweiterten öffentlichen Elternschlüssel berechnen; ein hardened-Schritt benötigt den erweiterten privaten Elternschlüssel. CKDpriv berechnet I = HMAC-SHA512(cpar, data), zerlegt das Ergebnis in IL und IR und addiert parse256(IL) modulo n zum privaten Elternschlüssel. IR wird der neue Chain-Code. Normale Ableitung verwendet serP(Kpar) || ser32(i), hardened dagegen 0x00 || ser256(kpar) || ser32(i) mit i ≥ 2^31. CKDpub erzeugt nur normale öffentliche Zweige, indem es point(parse256(IL)) zu Kpar addiert. Eine andere Zweignummer verändert die anschließend abgeleiteten Schlüssel. [1]

Ein xpub kann öffentliche Schlüssel ableiten, solange der Pfad keinen hardened-Schritt überschreitet. Damit ist ein Risiko verbunden: Der Eltern-xpub zusammen mit einem offengelegten privaten Schlüssel eines normalen Kindes erlaubt die Berechnung des privaten Elternschlüssels. Auch dessen andere Zweige sind dann gefährdet. Hardened verhindert diese Rückrechnung, schützt aber weder vor dem Diebstahl des Seeds noch vor schwachen Zufallsdaten oder der Bestätigung einer schädlichen Transaktion. [1]

Im Mainnet beginnt die öffentliche Standarddarstellung mit xpub, die private mit xprv; ihre Versionen sind 0x0488B21E und 0x0488ADE4. Vor Base58Check umfasst der Datensatz 78 Byte: Version 4, Tiefe 1, Eltern-Fingerprint 4, Kindnummer 4, Chain-Code 32 und Schlüsseldaten 33. Das Ergebnis hat 111 Zeichen. Der kurze Fingerprint hilft beim Zuordnen, beweist aber keine Identität. Die SLIP132-Präfixe ypub/zpub deuten teilweise den Skripttyp an. Ein Präfixwechsel allein ändert weder Schlüssel noch Wallet-Regeln. [1] [9]

BIP43 reserviert die erste hardened-Ebene für den Verwendungszweck. BIP44 nutzt m / 44' / coin_type' / account' / change / address_index. Nach dem Konto folgen Zweig 0 für Empfang oder 1 für Wechselgeld und die Adressnummer. Apostroph oder h kennzeichnet einen um 2^31 erhöhten Index. BIP44 sucht mit einem Gap Limit von 20 und stoppt nach 20 aufeinanderfolgenden ungenutzten Empfangsadressen. BIP48 beschreibt Multisig, BIP84 den Zweck 84' für natives SegWit und BIP86 den Zweck 86' für Taproot mit einem Schlüssel. Diese Konventionen stehen nicht im Seed und werden nicht von Nodes erzwungen. [2] [3] [4] [5] [6]

Schlüssel allein bestimmen noch nicht das Skript, das die Coins schützt. Ein Output Descriptor kann Schlüsselherkunft, Pfade, eine Konstruktion wie wpkh(), erforderliche Signaturen, weitere Multisig-Teilnehmer und eine Prüfsumme festhalten. Ein Multipath-Descriptor kann Empfangs- und Wechselgeldzweig zusammenfassen. Der Seed eines Teilnehmers rekonstruiert weder die übrigen xpubs noch gemeinsame Regeln. Sichern Sie deshalb auch einen geprüften öffentlichen Descriptor oder Konfigurationsexport und schützen Sie dessen Vertraulichkeit. Enthält der Export private Schlüssel, behandeln Sie ihn als Geheimnis. [7] [8] [10] [13]

Der Seed kann Schlüssel erneut ableiten; die Anwendung braucht aber Seedformat, gegebenenfalls BIP39-Passphrase, Netzwerk, Skripttyp, Coin Type, Konten, beide Zweige und Suchbereich. Multisig benötigt zusätzlich die gemeinsame Konfiguration. Ein Nullsaldo muss keinen Verlust bedeuten: Vielleicht wird ein anderer Pfad durchsucht. Ein sicherer Test auf einem vertrauenswürdigen Gerät soll die richtigen UTXOs, also noch nicht ausgegebene Transaktionsausgänge, finden und das Signieren prüfen. Geben Sie echte Seeds oder Sicherungswörter niemals in ein Webwerkzeug oder einen gewöhnlichen Onlinecomputer ein. [3] [7] [10] [11]

BIP32 behandelt auch seltene ungültige Ergebnisse: parse256(IL) ≥ n, einen abgeleiteten privaten Schlüssel von null oder einen öffentlichen Punkt im Unendlichen. Dann wird der nächste Index versucht. Häufiger fehlen bei der Wiederherstellung Pfad, Wechselgeldzweig oder ein unterstützter Skripttyp. Prüfen Sie vor dem Wechsel, ob die Coins gefunden werden, und testen Sie eine kleine Überweisung. Behalten Sie die ursprüngliche Sicherung und Konfiguration, bis das neue Verfahren funktioniert. xprv liefert die Schlüssel zum Signieren, xpub offenbart finanzielle Zusammenhänge und der Descriptor beschreibt den Aufbau der Wallet. [1] [7] [9] [10]