Derivation Path ist eine geordnete Folge normaler und hardened Indizes zur Schlüsselableitung nach BIP 32. Er ist weder Seed, privater Schlüssel noch Adresse; dieselbe Schreibweise ergibt bei einem anderen Ausgangsschlüssel andere Schlüssel.
In m/0/7 steht m für den privaten Hauptknoten; jeder Schrägstrich ergänzt eine Ableitung: zuerst Kind 0, dann dessen Kind 7. Verwendet wird ein erweiterter Schlüssel einschließlich chain code. Die Zahlen sind weder Beträge noch Transaktionsnummern; der Pfad allein liefert kein Signaturmaterial. [BIP 32 — Hierarchical Deterministic Wallets]
BIP 32 teilt 32-Bit-Indizes in normale von 0 bis 2^31−1 und hardened von 2^31 bis 2^32−1. 0' und 0h bezeichnen beide den hardened Index 2^31, nicht den normalen 0; BIP 380 akzeptiert Apostroph und h. Ein normales öffentliches Kind lässt sich aus einem xpub ableiten, ein hardened Kind aus einem xpub allein nicht. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 380 — Output Script Descriptors]
Das Beispiel m/84'/0'/0'/0/7 bezeichnet BIP 84, Bitcoin mainnet, Konto 0, den externen Empfangszweig 0 und Index 7, also die achte Adressposition. Die ersten drei Ebenen sind hardened, die letzten zwei normal. In BIP 44 dient Zweig 1 eigenem Wechselgeld; Indizes beginnen bei null. [BIP 44 — Multi-Account Hierarchy] [BIP 84 — Native P2WPKH derivation]
BIP 43 reserviert die erste hardened Ebene für purpose. 44' steht in Verbindung mit P2PKH, 49' mit P2SH-P2WPKH, 84' mit P2WPKH und 86' mit single-key P2TR. Die Zahl allein erzwingt kein Konsensskript; die Software muss den passenden Ausgang konstruieren. Nicht alle Wallets verwenden diese Konventionen. [BIP 43 — Purpose Field] [BIP 44 — Multi-Account Hierarchy] [BIP 49 — P2WPKH nested in P2SH] [BIP 84 — Native P2WPKH derivation] [BIP 86 — Single Key P2TR Outputs]
Wurde ein xpub bereits auf m/84'/0'/0' exportiert, reicht für diesen Nachkommen das relative Suffix /0/7. Den gesamten Wurzelpfad erneut an einen Konto-xpub anzuhängen führt zu einer anderen Ableitung; seine hardened Schritte sind aus diesem xpub ohnehin unmöglich. Serialisierte Tiefe und Eltern-fingerprint enthalten nicht die vollständige ursprüngliche Pfadhistorie. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 380 — Output Script Descriptors]
BIP 380 erlaubt vor dem Schlüssel eine Herkunft fingerprint/Pfad in eckigen Klammern und danach ein Ableitungssuffix. Die Herkunft beschreibt bereits ausgeführte Schritte, das Suffix muss noch abgeleitet werden. Ein Descriptor legt zusätzlich das Skript fest und kann über * einen Bereich enthalten. Der fingerprint hat vier Bytes und kann kollidieren; er ist weder Identitätsbeweis noch Schlüsselersatz. [BIP 380 — Output Script Descriptors] [BIP 32 — Hierarchical Deterministic Wallets] [Bitcoin Core 29.0 — deriveaddresses RPC]
BIP 32 warnt, dass ein Eltern-xpub zusammen mit einem offengelegten normalen privaten Nachkommen den erweiterten privaten Elternschlüssel offenbaren kann. Eine hardened Grenze trennt diesen konkreten Vorgang, schützt aber nicht den bereits offengelegten Schlüssel selbst. Ein geteilter xpub offenbart auch seinen öffentlichen Zweig und kann die Privatsphäre beeinträchtigen, obwohl er allein nicht signiert. [BIP 32 — Hierarchical Deterministic Wallets]
Bei der Wiederherstellung werden der richtige Seed und eine eventuelle Passphrase, Netzwerk, Konto, Zweig, Skript und Scanbereich einschließlich Gap Limit geprüft. Gültige Syntax kann in einen anderen leeren Zweig zeigen; ein Nullsaldo beweist daher keine falschen Schlüssel. Geprüft wird anhand einer bekannten Empfangsadresse und Historie, nicht allein daran, ob die Software den Pfad akzeptiert. [BIP 39 — From mnemonic to seed] [BIP 44 — Multi-Account Hierarchy] [BIP 380 — Output Script Descriptors]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit HD Wallet, Extended Public Key (xpub), Gap Limit, Output Descriptor, BIP 39. Auf diesen Eintrag verweisen außerdem HD Wallet, Watch-only Wallet, Wechselgeld-Ausgang, Extended Public Key (xpub).