144 / 736PATH

Derivation Path

Ableitungspfad eines Schlüssels

Aus einer Sicherung können viele Wallet-Konten und Adressen entstehen. Derivation Path sagt der Wallet, wohin sie in dieser Struktur gehen soll, um bei der Wiederherstellung die früher verwendeten Schlüssel zu finden.

Derivation Path ist die genaue Folge von Schritten, mit der eine Wallet aus einem Ausgangsschlüssel einen bestimmten Schlüssel ableitet. Stell dir Ordner auf einem Computer vor: Das richtige Laufwerk reicht nicht, wenn du die falschen Ordner öffnest. Wallet-Schlüssel werden allerdings mathematisch berechnet und nicht in gespeicherten Dateien gesucht. Gleiche Ausgangsdaten und derselbe Pfad ergeben dasselbe Ergebnis. Ein anderer Pfad kann zu einem anderen Teil derselben Wallet führen. Er ist keine Zahlungsadresse, kein Passwort und kein Ersatz für die Sicherung.

Anna stellt ihre Wallet wieder her, als die Software nach einem Pfad fragt, über den sie bisher nie nachdenken musste. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. m/0/7 wirkt kompliziert, wird aber der Reihe nach gelesen: m ist der private Hauptknoten. Von ihm wird der untergeordnete Schlüssel 0 abgeleitet und davon wiederum Schlüssel 7. Knoten meint hier eine Stelle im Schlüsselbaum, keinen Rechner im Bitcoin-Netzwerk. Die Zahlen sind Indizes, also Positionen, keine Beträge oder Transaktionsnummern. BIP 32 verwendet einen erweiterten Schlüssel: Neben dem Schlüssel selbst enthält er einen chain code, zusätzliche Daten zur Ableitung weiterer Schlüssel. Der aufgeschriebene Pfad ohne Ausgangsschlüssel kann daher keine Zahlung signieren. [1] [10]

Nehmen wir m/84'/0'/0'/0/7. Der erste Teil nach m steht für BIP 84 mit nativem SegWit, eine Art, Adressen und Ausgaben zu bilden. Es folgen Bitcoin mainnet, das Hauptnetz mit echten Bitcoin, Konto 0, externer Empfangszweig 0 und Index 7. Das ist die achte Adressposition, weil die Zählung bei null beginnt. Ein Konto trennt eine Gruppe von Guthaben, der Zweig beschreibt den Zweck der Adressen. In der BIP-44-Struktur dient Zweig 1 eigenem Wechselgeld, also dem Betrag, der nach einer Zahlung beim Absender bleibt. Die ersten drei Schritte tragen einen Apostroph und sind hardened, die letzten zwei normal. Was verändert diese Markierung? [2] [5]

Ein privater Schlüssel ist ein geheimer Zahlenwert, mit dem die Wallet eine digitale Signatur zur Freigabe einer Ausgabe erstellt. Hardened bezeichnet eine Ableitung, die den privaten Elternschlüssel benötigt. Bei einem normalen Schritt lässt sich ein untergeordneter öffentlicher Schlüssel auch aus einem xpub ableiten, einem erweiterten öffentlichen Schlüssel. Mit dem passenden Script-Typ können so Adressen entstehen, ohne Zahlungen signieren zu können. Einen hardened Schritt kann ein xpub allein nicht überwinden. Nach BIP 380 bedeuten 0' und 0h dasselbe, nicht den normalen Index 0. Für technisch Interessierte: BIP 32 teilt die 32-Bit-Indizes in normale 0 bis 2^31−1 und hardened 2^31 bis 2^32−1. Die Markierung macht aus null den Index 2^31. Wer sie weglässt, verändert die Berechnung und nicht nur das Schriftbild. [1] [7] [10]

BIP 43 nennt die erste hardened Ebene purpose, also den vorgesehenen Zweck der Struktur. Vereinbarte Werte helfen Wallets zu erkennen, wie ein Zweig üblicherweise verwendet wird. Zur Einordnung: 44' steht für traditionelles P2PKH, eine durch den Hash eines öffentlichen Schlüssels geschützte Zahlung; 49' für P2SH-P2WPKH, SegWit in einer älteren Hülle zur Kompatibilität; 84' für natives P2WPKH; und 86' für single-key P2TR, eine Taproot-Konstruktion mit einem internen Schlüssel. Das sind unterschiedliche Bedingungen für das Ausgeben von Geld. Die Zahl allein verwandelt den Pfad nicht in das passende Script und erzwingt es auch nicht durch den Netzwerkkonsens. Die Software muss den richtigen Output tatsächlich erstellen. Nicht jede Wallet verwendet diese Konventionen. [3] [2] [4] [5] [6]

Anna kann nur den xpub eines Kontos verbinden, um Zahlungseingänge zu sehen, statt die gesamte Wallet einzubinden. Stammt er aus m/84'/0'/0', befindet er sich schon auf Kontoebene. Zum früheren Beispiel fehlt nur das relative Suffix /0/7. Den gesamten Pfad von der Wurzel erneut anzuhängen würde weitere Ableitung vom falschen Ort aus beginnen; seine hardened Schritte sind mit einem xpub ohnehin unmöglich. Der exportierte erweiterte Schlüssel enthält seine Tiefe im Baum und den fingerprint des Elternschlüssels, eine kurze Kennung, aber kein vollständiges Protokoll früherer Schritte. Der fehlende ursprüngliche Pfad lässt sich deshalb nicht immer einfach aus dem xpub ablesen. [1] [7]

Ein Descriptor beschreibt Schlüssel und Ausgabebedingungen, aus denen die Software die beobachteten Outputs erstellt. BIP 380 erlaubt vor dem Schlüssel in eckigen Klammern dessen Herkunftspfad und fingerprint. Diese Schritte wurden schon ausgeführt. Das Suffix hinter dem Schlüssel beschreibt dagegen weitere Ableitung; ein Stern * kann für eine Reihe von Nachkommen stehen. Der fingerprint hat vier Bytes und kann kollidieren: Verschiedene Schlüssel können dieselbe kurze Kennung haben. Sie ist kein Identitätsbeweis und kein Schlüsselersatz. Bitcoin Core 29.0 bietet deriveaddresses über RPC, die Programmierschnittstelle des Knotens. Daraus werden Adressen für einen Descriptor und gegebenenfalls einen Bereich berechnet; die Berechnung allein prüft keinen Kontostand und versendet kein Geld. [7] [1] [9]

Der Pfad allein kann ohne die Ausgangsdaten deine Schlüssel nicht erzeugen. Einen xpub zu teilen ist etwas anderes: Der Empfänger kann öffentliche Schlüssel des zugänglichen Zweigs ableiten und mit dem passenden Script-Typ dessen Adressen verfolgen. Er darf dadurch nicht ausgeben, doch die Privatsphäre kann leiden. BIP 32 warnt zudem vor einer weniger offensichtlichen Gefahr: Ein Eltern-xpub zusammen mit einem offengelegten privaten Nachkommen, der über normale Schritte erreichbar ist, kann den erweiterten privaten Elternschlüssel offenbaren. Eine hardened Grenze sperrt diesen konkreten Weg zurück zum Elternschlüssel. Sie macht den offengelegten Schlüssel aber nicht ungültig und rettet nicht das von ihm kontrollierte Geld. [1]

Zurück zur Wiederherstellung. Seed Phrase bezeichnet die Sicherungswörter. Nach BIP 39 entsteht daraus zusammen mit einer optionalen Passphrase der Seed, das Ausgangsgeheimnis für die Schlüssel. Die Passphrase ist zusätzlicher geheimer Text, nicht das normale Anwendungspasswort. Mit einem anderen Seed führt derselbe Pfad zu anderen Schlüsseln. Netzwerk, Konto, Zweig und Script-Typ müssen ebenfalls passen. Außerdem muss die Software genügend Adressen und Historie durchsuchen: Gap Limit beendet die Suche nach einer Folge unbenutzter Adressen. Ein Nullsaldo allein beweist daher keinen Schlüsselverlust. Anna kann das Ergebnis mit einer bekannten Empfangsadresse und früheren Zahlungen abgleichen. Dass die Software den Pfad akzeptiert, heißt nur, dass sie ihn verarbeiten kann, nicht dass sie die gesamte ursprüngliche Wallet gefunden hat. [8] [2] [7]

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, Seed Phrase. Auf diesen Eintrag verweisen außerdem HD Wallet, Watch-only Wallet, Change Address, Extended Public Key (xpub).

DOC · 001BIP 32 — Hierarchical Deterministic WalletsSpezifikation DOC · 002BIP 44 — Multi-Account HierarchySpezifikation DOC · 003BIP 43 — Purpose FieldSpezifikation DOC · 004BIP 49 — P2WPKH nested in P2SHSpezifikation DOC · 005BIP 84 — Native P2WPKH derivationSpezifikation DOC · 006BIP 86 — Single Key P2TR OutputsSpezifikation DOC · 007BIP 380 — Output Script DescriptorsSpezifikation DOC · 008BIP 39 — From mnemonic to seedSpezifikation DOC · 009Bitcoin Core 29.0 — deriveaddresses RPCDokumentation DOC · 010Bitcoin Developer Guide — WalletsDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung