---
title: "Hierarchisch-deterministische Wallet (HD-Wallet)"
description: "Erfahren Sie, wie eine HD-Wallet aus einem einzigen Seed einen Schlüsselbaum ableitet, wie sich gehärtete und normale Ableitung unterscheiden und was ein vollständiges, überprüfbares Wallet-Backup enthalten muss."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Hierarchisch-deterministische Wallet (HD-Wallet)
> Nur zu Bildungszwecken; stellt keine Anlageberatung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
Eine hierarchisch-deterministische Wallet (HD-Wallet) leitet aus einem einzigen Root-Seed einen reproduzierbaren Baum kryptografischer Schlüsselpaare ab. BIP-32 definiert den Schlüsselbaum-Mechanismus: Jeder Knoten ist ein erweiterter Schlüssel, der aus einem Schlüssel und einem `32-byte` langen Chaincode besteht; ein Index wählt jeweils den Kindschlüssel aus. Dasselbe Root-Material, dieselben Ableitungsregeln und derselbe Pfad erzeugen dieselben Kindschlüssel.
„Deterministisch“ macht Backups praktikabel, aber nicht jede Wallet mit jeder anderen austauschbar. Eine mnemonische Wortfolge ist eine Möglichkeit, Entropie zu codieren und einen Seed zu erzeugen. Ein Ableitungspfad wählt dagegen einen Knoten aus, und eine Adress- oder Scriptregel wandelt dessen öffentlichen Schlüssel in etwas um, das eine Blockchain erkennt. Werden nur die Wörter wiederhergestellt, kann eine leere Wallet erscheinen, wenn sich Passphrase, Pfad, Netzwerk, Scripttyp oder Regeln zur Kontenerkennung unterscheiden.
„Hierarchisch“ bedeutet, dass sich Berechtigungen auf Teilbäume verteilen lassen. Mit einem erweiterten öffentlichen Schlüssel auf Kontoebene kann ein Watch-only-Dienst normale nachgeordnete öffentliche Schlüssel ableiten, ohne Ausgabeschlüssel zu besitzen. Ein erweiterter privater Schlüssel kann den zugehörigen privaten Teilbaum ableiten und muss wie eine Sammlung privater Schlüssel geschützt werden, nicht wie eine einzelne Adresse.
Eine HD-Wallet ist ein Konzept zur Schlüsselverwaltung, kein Wallet-Objekt auf der Blockchain. Die Blockchain speichert weder Mnemonik noch Seed, Pfad, Bezeichnungen oder Backup. Dabei handelt es sich um Off-Chain-Datensätze, die von der Wallet-Software und dem Nutzer verwaltet werden.
## Funktionsweise
### 1. Von der Entropie zur Wurzel
BIP-39 wird häufig vor BIP-32 eingesetzt, doch die Standards sind voneinander getrennt. BIP-39 codiert `128-256 bits` Entropie samt Prüfsumme als `12-24 words` und wendet anschließend PBKDF2-HMAC-SHA512 mit `2048` Iterationen auf die normalisierte Mnemonik und eine optionale Passphrase an, um einen `512-bit` Seed zu erzeugen. Jede Passphrase ergibt einen gültigen, aber anderen Seed. Eine fehlende oder falsch eingegebene Passphrase wird daher nicht zuverlässig durch die Meldung „ungültiges Passwort“ erkannt.
BIP-32 verwendet HMAC-SHA512 mit dem Schlüssel `Bitcoin seed`, um Seed-Bytes in einen privaten Master-Schlüssel und einen Master-Chaincode umzuwandeln. Dieser erweiterte private Root-Schlüssel ist der Ursprung des BIP-32-Baums. Nicht jede deterministische Wallet verwendet BIP-39 oder BIP-32; bei einer Wiederherstellung muss daher das tatsächliche Schema festgestellt werden, statt es aus dem Vorhandensein von Wiederherstellungswörtern abzuleiten.
### 2. Erweiterte Schlüssel und Ableitung von Kindschlüsseln
Ein erweiterter privater BIP-32-Schlüssel verbindet einen privaten Schlüssel mit einem Chaincode. Sein neutralisierter erweiterter öffentlicher Schlüssel verbindet den entsprechenden öffentlichen Schlüssel mit demselben Chaincode. Bei der normalen Kindableitung werden der öffentliche Elternschlüssel, der Chaincode und der Kindindex verwendet. Ein erweiterter öffentlicher Schlüssel kann deshalb normale öffentliche Kindschlüssel ableiten, aber keine privaten Kindschlüssel.
Gehärtete Kindschlüssel verwenden Indizes von `2^31` bis `2^32 - 1` und beziehen Material des privaten Elternschlüssels ein. Sie können nicht aus dem erweiterten öffentlichen Elternschlüssel abgeleitet werden. In Pfaden werden sie üblicherweise mit einem Apostroph gekennzeichnet, etwa `m/84'/0'/0'`. Die Härtung begrenzt den Schaden eines bestimmten BIP-32-Fehlers: Ein erweiterter öffentlicher Elternschlüssel zusammen mit einem zugehörigen nicht gehärteten privaten Kindschlüssel kann den erweiterten privaten Elternschlüssel offenlegen.
### 3. Pfade geben dem Baum Bedeutung
BIP-44 definiert `m / purpose' / coin_type' / account' / change / address_index`. Die ersten `3` Ebenen sind gehärtet; `change` und `address_index` sind normal, damit öffentliche Kontoschlüssel Empfangs- und Wechselgeldadressen erzeugen können. Konventionsgemäß ist Zweig `0` extern und Zweig `1` für internes Wechselgeld vorgesehen. Die BIP-44-Erkennung durchsucht den Transaktionsverlauf und verwendet eine Lückenbegrenzung von `20` aufeinanderfolgenden ungenutzten externen Adressen.
Der Pfad ist eine Metadatenangabe, kein Geheimnis und keine universelle Garantie. BIP-84 weist nativen SegWit-P2WPKH-Konten den Zweck `84'` zu, während andere Zwecke oder wallet-spezifische Strukturen andere Teilbäume erzeugen. Der Coin-Typ ist eine Namensraumkonvention und keine von einer Blockchain erzwungene Regel.
### 4. Schlüssel allein ergeben noch keine vollständige Wallet
Ein öffentlicher Schlüssel benötigt weiterhin Netzwerk- und Adress- oder Scriptregeln. Bei Bitcoin kann derselbe Schlüssel in unterschiedlichen Output-Scripts vorkommen. Eine Multisignatur-Wallet benötigt außerdem den Schwellenwert, die Schlüssel der Mitunterzeichner, deren Reihenfolge und die Ableitungsursprünge. BIP-380-Output-Deskriptoren verknüpfen Schlüssel und Ursprünge mit ausdrücklichen Script-Ausdrücken und können eine Prüfsumme enthalten. Deshalb reicht ein reines Seed-Backup möglicherweise nicht aus, um nachzubilden, was die ursprüngliche Wallet überwachte oder ausgeben konnte.
Wallet-Bezeichnungen, Kontakte, Transaktionsnotizen, importierte Schlüssel, Kontonamen und manche Wiederherstellungseinstellungen für Verträge oder Smart Accounts werden im Allgemeinen nicht deterministisch abgeleitet. Sie müssen gesondert exportiert oder dokumentiert werden.
### 5. Backup und Wiederherstellung sind geprüfte Prozesse
Dokumentieren Sie die Wallet-Implementierung, das Format der Mnemonik oder des Seeds, das Vorhandensein einer Passphrase, den Master-Fingerabdruck, relevante Pfade, Netzwerke, Kontoindizes und Bitcoin-Deskriptoren oder gleichwertige Richtliniendaten. Bewahren Sie Root-Geheimnisse offline und, soweit praktikabel, getrennt von öffentlichen Wiederherstellungsmetadaten auf. Ein `xpub` kann selbst nichts ausgeben, aber Guthaben, Beziehungen zwischen Adressen und künftige normale Nachfolger offenlegen.
Testen Sie die Wiederherstellung in einer vertrauenswürdigen Umgebung, bevor Sie sich auf das Backup verlassen. Vergleichen Sie zunächst bekannte Adressen oder Deskriptoren, ohne Guthaben zu verschieben. Prüfen Sie danach Empfangs- und Wechselgeldzweige, spätere Konten, den Transaktionsverlauf und das Signieren mit einer kontrollierten kleinen Transaktion. Geben Sie eine Mnemonik, Passphrase oder einen `xprv` niemals auf einer nicht vertrauenswürdigen Website oder in einem Support-Chat ein.
## Beispiel
Betrachten wir ein natives Bitcoin-SegWit-Konto unter `m/84'/0'/0'`. Der Zweck `84'` wählt die BIP-84-Konvention, `0'` den Namensraum für den Bitcoin-Coin-Typ und das letzte `0'` das erste Konto. Ein Watch-only-System kann den erweiterten öffentlichen Kontoschlüssel erhalten und normale Zweige ableiten, ohne den privaten Kontoschlüssel zu erhalten.
Der erste externe Empfangsschlüssel liegt unter `m/84'/0'/0'/0/0`, der nächste unter `m/84'/0'/0'/0/1`. Der erste interne Wechselgeldschlüssel liegt unter `m/84'/0'/0'/1/0`. Alle stammen vom selben Konto ab, doch Zweig und Index wählen verschiedene Schlüssel aus. Wird der Seed mit `m/44'/0'/0'/0/0` erneut verwendet, werden ein anderer Teilbaum und eine andere Output-Konvention gewählt. Ein leeres Ergebnis beweist nicht, dass der Seed falsch ist.
Bewahren Sie für einen vollständigen Bitcoin-Wiederherstellungsdatensatz das Root-Secret-Backup getrennt vom Deskriptor oder gleichwertigen Metadaten auf, die Fingerabdruck, Pfad, erweiterten öffentlichen Schlüssel, Scripttyp und Prüfsumme angeben. Prüfen Sie mehrere zuvor verwendete Adressen in beiden Zweigen. Nur die erste Empfangsadresse zu finden, belegt ein korrektes Blatt, aber nicht, dass jedes Konto, jede Wechselgeldausgabe oder jede Wallet-Richtlinie wiederhergestellt wurde.
## Risiken
- **Konzentration auf eine einzige Wurzel:** Wird ein Root-Seed oder ein hinreichend hoch angesiedelter erweiterter privater Schlüssel kompromittiert, können alle Nachfolger in seinem Bereich offengelegt werden.
- **Verlust des Backups:** Der Verlust des einzigen Seed-Backups oder der gesonderte Verlust einer nicht dokumentierten BIP-39-Passphrase kann sämtliche abgeleiteten Schlüssel unwiederbringlich machen.
- **Falsche Sicherheit durch die Passphrase:** Eine falsche BIP-39-Passphrase erzeugt eine andere gültige Wallet, die wie eine erfolgreiche, aber leere Wiederherstellung aussehen kann.
- **Falscher Pfad oder falsches Script:** Der richtige Seed erzeugt mit falschem Zweck, Konto, Zweig, Netzwerk oder Output-Typ gültige, aber nicht zugehörige Adressen.
- **Unvollständiges Richtlinien-Backup:** Seed und Pfad allein können Multisignatur-, Deskriptor-, Smart-Account- oder wallet-spezifische Ausgabebedingungen möglicherweise nicht rekonstruieren.
- **Datenschutzleck durch den erweiterten öffentlichen Schlüssel:** Ein `xpub` kann einen Adressverbund offenlegen und die fortlaufende Verfolgung normaler Nachfolger ermöglichen.
- **Kompromittierung des Elternknotens bei BIP-32:** Ein Eltern-`xpub` zusammen mit einem geleakten zugehörigen nicht gehärteten privaten Kindschlüssel kann den privaten Teilbaum des Elternknotens offenlegen.
- **Nicht vertrauenswürdige Wiederherstellungswerkzeuge:** Websites, Erweiterungen, gefälschte Geräte, Zwischenablage-Werkzeuge oder Bildschirmfreigaben können das gesamte Root-Geheimnis abgreifen.
- **Ungeprüfte Medien:** Papier, Metall, verschlüsselte Dateien oder Hardware-Backups können durch Übertragungsfehler, Korrosion, vergessene Passwörter oder nicht mehr unterstützte Formate versagen.
- **Unvollständige Migration:** Werden sichtbare Coins verschoben, während Token, Wechselgeldausgaben, Vertragsrollen, Genehmigungen oder spätere Konten unter der alten Wurzel verbleiben, besteht die Gefährdung fort.
## Häufige Missverständnisse
### Enthält eine Backup-Wortfolge alle Wallet-Details?
Nein. Sie kann Root-Schlüsselmaterial reproduzieren, aber nicht zwingend Passphrase, Ableitungskonvention, Netzwerk, Scripts, Multisignatur-Richtlinie, Bezeichnungen, importierte Schlüssel oder den Verlauf der Kontenerkennung. Bewahren Sie die von der tatsächlichen Wallet benötigten Metadaten auf.
### Kann ein `xpub` bedenkenlos veröffentlicht werden, weil er nichts ausgeben kann?
Nein. Normalerweise kann er nicht signieren, aber vergangene und künftige normale Nachfolgeradressen und deren gemeinsamen Verlauf offenlegen. Bei dem oben beschriebenen BIP-32-Fehler kann die Kombination mit einem zugehörigen nicht gehärteten privaten Kindschlüssel außerdem den übergeordneten Teilbaum kompromittieren.
### Erzeugen neue Adressen unabhängige Backups?
Nein. Neue Adressen verringern die Wiederverwendung von Adressen und verbessern den Datenschutz, doch deterministische Nachfolger bleiben unter der Kontrolle desselben Vorfahren. Eine Kompromittierung der Wurzel betrifft den Teilbaum selbst dann, wenn für jede Zahlung eine neue Adresse verwendet wurde.
### Beweist die Wiederherstellung einer bekannten Adresse, dass die Wallet vollständig ist?
Nein. Sie bestätigt eine Kombination aus Root-Material, Pfad und Adresskonstruktion. Die Wiederherstellung muss weiterhin Empfangs- und Wechselgeldzweige, alle verwendeten Konten, Scripts oder Richtlinien sowie die relevanten Netzwerke abdecken.
## Verwandte Themen
- [Wallet-Ableitungspfad](/de/crypto/derivation-path/)
- [Seed-Phrase](/de/crypto/seed-phrase/)
- [Öffentliche und private Schlüssel](/de/crypto/public-private-key/)
- [Hardware-Wallet](/de/crypto/hardware-wallet/)
- [Cold Wallet](/de/crypto/cold-wallet/)
## Quellen
- [BIP 32: Hierarchisch-deterministische Wallets](https://bips.dev/32/) - Bitcoin Improvement Proposals (abgerufen: 2026-08-20)
- [BIP 39: Mnemonischer Code zur Erzeugung deterministischer Schlüssel](https://bips.dev/39/) - Bitcoin Improvement Proposals (abgerufen: 2026-08-20)
- [BIP 44: Mehrkonten-Hierarchie für deterministische Wallets](https://bips.dev/44/) - Bitcoin Improvement Proposals (abgerufen: 2026-08-20)
- [BIP 84: Ableitungsschema für P2WPKH-Konten](https://bips.dev/84/) - Bitcoin Improvement Proposals (abgerufen: 2026-08-20)
- [BIP 380: Allgemeine Funktionsweise von Output-Script-Deskriptoren](https://bips.dev/380/) - Bitcoin Improvement Proposals (abgerufen: 2026-08-20)
Source: https://wiki.fcontext.com/de/crypto/hd-wallet/index.mdx