HD-Wallets erklärt: Wie BIP32 aus einer Seed einen Schlüsselbaum macht

Ein hierarchisch-deterministisches (HD-)Wallet leitet eine unbegrenzte Anzahl von Schlüsseln aus einer einzigen Seed ab. Die Mechanik zu verstehen ist für die Wiederherstellung wichtig: Sie erklärt, warum eine Seed viele gültig aussehende Wallets erzeugen kann und warum Ableitungspfad und Kontoindex entscheiden, welchen Adressen Ihre Coins zugeordnet sind.

Der Master-Schlüssel

BIP32 beginnt mit einem binären Seed, der meist aus einer BIP-39-Phrase abgeleitet wird. Der binäre Seed wird mit HMAC-SHA512 und einem festen Schlüssel ("Bitcoin seed") verarbeitet. Das Ergebnis umfasst 64 Bytes: Die ersten 32 werden der Master-Private-Key, die letzten 32 der Master-Chain-Code. Beide werden für die Ableitung von Kind-Schlüsseln benötigt – weshalb ein erweiterter Schlüssel einen Schlüssel plus Chain Code enthält.

Kind-Schlüssel und Chain Codes

Jeder Kind-Schlüssel wird deterministisch vom Elternknoten abgeleitet:

• Normale Ableitung: HMAC-SHA512 aus öffentlichem Elternschlüssel, Eltern-Chain-Code und einem Index. Wer einen xpub (den erweiterten öffentlichen Schlüssel) hat, kann Kinder ableiten – das ist es, was Watch-only-Wallets möglich macht.
• Hardened Ableitung (der Apostroph, z. B. m/44'): HMAC-SHA512 aus privatem Elternschlüssel, Chain Code und Index. Das geht nur mit dem privaten Schlüssel und isoliert den Zweig vom öffentlichen Schlüssel des Elternteils.

Der Chain Code ist ein 32 Byte langer Wert, der bei der Schlüsselableitung verwendet wird. Er gehört sowohl zu erweiterten privaten als auch zu erweiterten öffentlichen Schlüsseln: Jeder erweiterte Schlüssel verbindet einen Schlüssel mit seinem Chain Code.

Die Purpose-Ebenen (BIP43, BIP44, BIP49, BIP84, BIP86)

BIP43 reservierte die erste Ebene des Baums für einen Purpose. Die üblichen Purposes sind:

• BIP44 – m/44'/coin'/account'/change/index – Legacy-Adressen (1...)
• BIP49 – m/49'/coin'/account'/change/index – SegWit in P2SH (3...)
• BIP84 – m/84'/coin'/account'/change/index – Native SegWit (bc1q...)
• BIP86 – m/86'/coin'/account'/change/index – Taproot (bc1p...)

Unter dem Purpose sitzen der Coin Type (0' Bitcoin, 60' Ethereum usw.), das Konto, der Wechselzweig (0 = Empfang, 1 = Wechsel) und schließlich der Adressindex. Jede Ebene ist ein Zweig im Baum; dieselbe Seed unter zwei verschiedenen Purposes erzeugt zwei völlig verschiedene Adressmengen.

Deterministisch vs. nicht-deterministisch

• HD-Wallets: eine Seed, ein Baum, überall mit dem richtigen Pfad wiederherstellbar
• Nicht-HD-Wallets (frühes Bitcoin Core, MultiBit Classic): Schlüssel wurden in einer Keypool-Datei erzeugt; ohne diese Datei (oder ihre Sicherung) kann eine Seed sie nicht rekonstruieren. Deshalb zählen alte Wallet Dateien.

Was das für die Wiederherstellung bedeutet

• Eine korrekte Seed ist nur die halbe Antwort: Ableitungspfad und Kontoindex entscheiden, welche Adressen geprüft werden
• Ein falscher Pfad oder ein falsches Konto erzeugt gültig aussehende, aber leere Adressen – kein Fehler
• Mit einem xpub kann Software öffentliche Kind-Schlüssel und deren Adressen innerhalb seines Zweigs ableiten, solange keine Hardened Ableitung erforderlich ist. Private Schlüssel lassen sich damit nicht wiederherstellen. Ein xpub enthält Metadaten zum Knoten, aber nicht den vollständigen Ableitungspfad; dafür sind zusätzliche Informationen nötig.
• Gap-Limits und Wechseladressen sind die praktischen Folgen dieser Baumstruktur: Wallets scannen ein begrenztes Fenster unbenutzter Adressen

Die Pfad-Referenz listet die praktischen Standardwerte; diese Seite erklärt die Mechanik dahinter.