Zum Inhalt springen
Financial Context Wiki

Wallet-Ableitungspfade: Standards, Suche und Wiederherstellung

Erfahren Sie, wie Wallet-Ableitungspfade deterministische Kindschlüssel auswählen, wie sich gehärtete Ebenen und Kontokonventionen unterscheiden und wie man Pfade während der Wiederherstellung überprüft.

Aktualisiert

Nur zu Bildungszwecken; keine Anlageberatung. Anlagen können zu Verlusten führen.

Direkte Antwort

Ein Wallet-Ableitungspfad ist eine geordnete Folge von Kindindizes, die einem deterministischen Schlüsselableitungsalgorithmus vorgibt, welchen Knoten im Schlüsselbaum er auswählen soll. In der üblichen BIP-32-Notation beginnt m/84'/0'/0'/0/7 am privaten Master-Knoten m und durchläuft fünf Kindknoten. Das Apostroph kennzeichnet eine gehärtete BIP-32-Ableitung. Der Pfad enthält Routing-Metadaten: Er ist kein privater Schlüssel, verschlüsselt keinen Seed, bestimmt selbst keinen Blockchain-Saldo und kann ohne das richtige Root-Material und den Ableitungsalgorithmus nichts wiederherstellen.

Für BIP-44-Wallets lautet die Vorlage m / purpose' / coin_type' / account' / change / address_index. Die Ebenen haben festgelegte Bedeutungen, keine willkürlichen Bezeichnungen. purpose wählt eine Wallet-Konvention, coin_type trennt registrierte Asset-Namensräume, account trennt logische Konten, change unterscheidet normalerweise externe Empfangsadressen (0) von internen Wechselgeldadressen (1), und address_index wählt ein Blatt aus. BIP-44 härtet die ersten drei Ebenen und lässt die letzten beiden ungehärtet, sodass ein erweiterter öffentlicher Kontoschlüssel Empfangs- und Wechselgeldadressen ohne private Schlüssel ableiten kann.

Das gleiche Mnemonic kann zu vielen gültigen, aber nicht zusammenhängenden Adresssätzen führen. Für Bitcoin umfassen gängige Einzel-Schlüssel-Pfade m/44'/0'/account'/change/index für P2PKH, m/49'/0'/account'/change/index für P2WPKH verschachtelt in P2SH, m/84'/0'/account'/change/index für native SegWit P2WPKH und m/86'/0'/account'/change/index für Einzel-Schlüssel-Taproot P2TR. Eine Wallet muss auch die Ausgabe- oder Skriptkonstruktion kennen; ein Pfad allein ist keine vollständige Bitcoin-Wallet-Policy.

Andere Ökosysteme verwenden Teile dieser Notation wieder, ohne identische Semantik zu garantieren. Ether ist als BIP-44-Münztyp 60 registriert, und m/44'/60'/0'/0/index ist eine gängige Konvention für extern verwaltete Konten, aber Wallet-Implementierungen haben mehrere Kontenlayouts verwendet. Derselbe EVM-Schlüssel kann dieselbe Kontoadresse auf mehreren EVM-Netzwerken erzeugen, obwohl Salden und Transaktionsverläufe kettenspezifisch sind. Ethereum-Validator-BLS-Schlüssel verwenden ERC-2333 und ERC-2334 anstelle von BIP-32; ihr m/12381/3600/account/use-Pfad hat keine Apostrophe und ist nicht interoperabel mit einem BIP-32-Baum. Eine Wiederherstellung erfordert daher die genaue Implementierung, Kurve, Seed oder Passphrase, Pfadkonvention, Netzwerk und Adresskonstruktion, nicht nur eine plausibel aussehende Zeichenfolge.

Ableitungspfad identifizieren und prüfen

1. Root-Material und Ableitungsalgorithmus bestimmen

Inventarisieren Sie das mnemonische Format, die Wortliste, die optionale Passphrase, den Roh-Seed oder den erweiterten Schlüssel sowie die Software- oder Hardware-Implementierung, die die Wallet erstellt hat. BIP-39 wandelt 128 in 256 Bits Entropie in ein Mnemonik um und leitet einen 512-bit-Seed aus diesem Mnemonik plus der genauen Passphrase ab; jede Passphrase erzeugt einen syntaktisch gültigen, aber unterschiedlichen Seed. BIP-32 leitet dann secp256k1 erweiterte Schlüssel aus einem Seed ab. Andere Wallet-Familien können unterschiedliche mnemonische Schemata, Kurven, Schlüsselableitungsfunktionen oder Master-Key-Regeln verwenden, sodass übereinstimmende Wörter keine übereinstimmende Wurzel beweisen.

2. Standard, Netzwerk und Schlüsselrolle bestimmen

Bestimmen Sie, ob das Ziel ein Bitcoin-Zahlungsschlüssel, ein extern verwaltetes EVM-Konto, ein Validatorenschlüssel, ein Multisig-Unterzeichner, ein Vertragsadministrator oder eine andere Befugnis ist. Erfassen Sie Blockchain und Netzwerk, den anwendbaren Standard samt Version, die Schlüsselkurve, den Ausgabe- oder Adresstyp sowie die Wallet-Anwendung. Eine SLIP-0044-Coin-Typ-Registrierung weist einen Namensraum zu; sie beweist nicht, dass jede Wallet für diesen Vermögenswert BIP-44 befolgt, ein Projekt unterstützt oder verhindert, dass eine andere Blockchain denselben Schlüssel andernorts ableitet.

3. Jede Pfadkomponente exakt auswerten

Behandle / als eine Eltern-Kind-Grenze und bewahre jeden Index, jede Tiefe und jedes Härtungszeichen. Unter BIP-32 verwenden normale Kinder die Indizes 0 bis 2^31 - 1; gehärtete Kinder verwenden 2^31 bis 2^32 - 1, üblicherweise geschrieben mit ', h oder H. Somit kodiert 7' die Kindnummer 2^31 + 7, nicht das gewöhnliche Kind 7. Bestätige, wie eine Import-Schnittstelle die Wurzel darstellt, ob sie einen vollständigen Pfad oder einen relativen Suffix akzeptiert, und ob ein exportierter erweiterter Schlüssel bereits unter einem Teil dieses Pfades liegt.

4. Pfad mit Adress- oder Ausgabesemantik verknüpfen

Prüfen Sie bei Bitcoin-Wallets der BIP-44-Familie purpose, coin_type, account, change und address_index und anschließend unabhängig davon den vorgesehenen Skripttyp und das Netzwerk. BIP-49, BIP-84 und BIP-86 verwenden bewusst unterschiedliche Zweckwerte, damit inkompatible Ausgabetypen nicht unbemerkt in einem Konto erscheinen. Bewahren Sie bei Multisig- oder Deskriptor-Wallets jeden Schlüsselursprung, den Master-Fingerabdruck, den Ableitungssuffix, die Schwelle, die Schlüsselreihenfolge, den Skriptaufbau und die Prüfsumme auf; ein Pfad allein kann die vollständige Policy nicht rekonstruieren.

5. Konto- und Adresssuche reproduzieren

Schließen Sie einen Verlust nicht aus einem einzigen leeren Standardkonto. BIP-44-Entdeckungsprüfungen überprüfen Konten der Reihe nach und scannen die externe Kette, wobei ein Adresslückenlimit von 20 aufeinanderfolgenden ungenutzten Adressen verwendet wird. Wallets, die Adressen über dieses Limit hinaus erstellt, interne Zweige ungewöhnlich verwendet, Konten übersprungen oder ein proprietäres Layout angewendet haben, können bei einem Standardscan möglicherweise nicht gefunden werden. Suchen Sie nur mit vertrauenswürdigen Watch-Only-Daten oder offline Ableitung, setzen Sie explizite Grenzen, dokumentieren Sie jeden durchsuchen Zweig und vermeiden Sie es, eine Mnemonic oder erweiterten privaten Schlüssel auf eine Website hochzuladen.

6. Wallet-Identität vor Verwendung des Saldos prüfen

Vergleichen Sie den Master-Fingerabdruck, den kontoübergreifenden erweiterten öffentlichen Schlüssel, wo dies zutrifft, den vollständigen Ursprungspfad sowie mehrere zuvor aufgezeichnete Empfangs- und Änderungadressen. Für Bitcoin leiten Sie die erwarteten Ausgabeskripte oder Deskriptoren ab und fragen das richtige Netzwerk nach der Transaktionshistorie ab, einschließlich ausgegebener Outputs. Für kontobasierte Ketten überprüfen Sie das genaue chainId, die Adresse, Token-Verträge und die historische Aktivität. Ein leerer Kontostand ist ein schwaches Indiz: Die Adresse könnte falsch sein, das Netzwerk oder der Index könnte abweichen oder die Vermögenswerte wurden möglicherweise bereits verschoben.

7. Kontrolliert wiederherstellen oder migrieren

Verwenden Sie verifizierte, kompatible Software in einer vertrauenswürdigen Umgebung; ziehen Sie es vor, einen nur Lese-Descriptor oder den öffentlichen Kontoschlüssel für die Entdeckung zu importieren, bevor Sie Signiermaterial preisgeben. Testen Sie das Signieren und die Wiederherstellung mit einem isolierten Konto oder einer kleinen Transaktion und gleichen Sie dann die abgeleiteten Adressen, die On-Chain-Historie, die Besitzrechte der Ausgänge, die Gebühren und den Endzustand ab. Wenn Geheimnisse in ein nicht vertrauenswürdiges Wiederherstellungstool eingegeben wurden, behandeln Sie sie als kompromittiert und migrieren Sie alle Vermögenswerte, Vertragsrollen, Genehmigungen, Validatorenaufgaben und Wiederherstellungsbefugnisse zu einer neuen Root, anstatt die wiederhergestellte Wallet weiterhin zu verwenden.

Rechenbeispiele

Einen gehärteten Bitcoin-Pfad auswerten

Betrachten Sie m/84'/0'/2'/1/17. Die Felder stehen für den nativen SegWit-Zweck 84', den Bitcoin-Coin-Typ 0', Konto 2', den internen oder Wechselgeldzweig 1 und Adressindex 17. Da gehärtete BIP-32-Indizes 2^31 = 2,147,483,648 addieren, lauten die serialisierten Kindnummern 84' = 2,147,483,732, 0' = 2,147,483,648 und 2' = 2,147,483,650. Die letzten beiden bleiben die normalen Indizes 1 und 17; ein fehlendes Apostroph wählt einen anderen Teilbaum, keine gleichwertige Schreibweise.

Eine Adresslücke, die eine verwendete Adresse verbirgt

Angenommen, im externen Zweig wurden die Adressen mit Index 0 und 5 genutzt. Danach scannt die Wallet 6 bis 25 und findet 20 aufeinanderfolgende ungenutzte Adressen. Nach der BIP-44-Adresslückenregel endet die Suche bei 25; die genutzte Adresse 26 liegt damit hinter der Stoppbedingung und wird ausgelassen. Eine Erweiterung bis zu einer dokumentierten Grenze kann sie finden. Ursache ist jedoch, dass die Quell-Wallet ohne zwischenzeitliche Aktivität eine Adresse jenseits der Standardlücke erzeugt hat.

Eine begrenzte Wiederherstellungssuche berechnen

Ein Wiederherstellungsprotokoll lässt offen, welche der 4 Bitcoin-Zweckfamilien (44', 49', 84' und 86'), welches von 3 Konten, welcher von 2 Zweigen und welcher der ersten 20 Indizes verwendet wurde. Die erste Suche umfasst 4 × 3 × 2 × 20 = 480 Blattkandidaten. Eine bekannte Adresse bestimmt nur einen Kandidatenpfad, nicht zwingend die ganze Wallet; Wechselgeld, spätere Indizes, andere Konten, Deskriptordetails und Verlauf sind weiter zu prüfen. Explizite Dimensionen machen die Suche reproduzierbar und begrenzen das Ausprobieren.

Warum ein Konto-xpub keine gewöhnliche öffentliche Angabe ist

Bei einem nicht gehärteten BIP-32-Kind gilt für die privaten Skalare child = parent + tweak (mod n). In einem vereinfachten Beispiel modulo 101 bestimmen die durch den erweiterten öffentlichen Kontoschlüssel offengelegten Ableitungsdaten tweak = 37; leckt der private Kindskalar 12, folgt parent = 12 - 37 mod 101 = 76. BIP-32 verwendet tatsächlich die secp256k1-Gruppenordnung und HMAC-Werte, doch die algebraische Folge ist gleich: Ein Eltern-xpub und ein passender nicht gehärteter privater Nachkommenschlüssel können den erweiterten privaten Elternschlüssel samt Teilbaum offenlegen. Gehärtete Kontogrenzen begrenzen diesen Fehler.

Risiken und Prüfungsfehler

  • Falsche mnemonische Phrase oder Passphrase: Schon ein anderes Wort, die Reihenfolge, Unicode-Normalisierung oder Passphrase erzeugt einen anderen, scheinbar gültigen Root-Schlüssel.
  • Falsches Ableitungsschema: Wird BIP-32 auf eine Wallet mit anderem Mnemonik-Schema, anderer Kurve, KDF oder Master-Key-Methode angewandt, entstehen unverbundene Schlüssel.
  • Falsches Netzwerk oder falscher Coin-Typ: Ein korrekter Root-Schlüssel in einem anderen Namensraum kann plausible Adressen erzeugen, während die Ziel-Blockchain ungesucht bleibt.
  • Falscher Zweck oder falsches Skript: Eine Verwechslung von 44', 49', 84' und 86' kann die tatsächlich finanzierte Bitcoin-Ausgabeart auslassen.
  • Fehlende Härtungsmarkierung: 7, 7', 7h und 7H können anders ausgewertet oder abgelehnt werden; gehärtete und normale Kindschlüssel sind nicht austauschbar.
  • Falscher Kontoindex: Wer nur Konto 0' prüft, kann Guthaben oder Befugnisse in späteren logischen Konten übersehen.
  • Verwechslung von externem und Wechselgeldzweig: Eine Suche nur in Zweig 0 kann Wechselgeldausgaben in Zweig 1 oder Wallet-spezifische Zweige übersehen.
  • Falscher Adressindex: Eine bekannte erste Adresse beweist nicht, dass spätere, übersprungene oder importierte Adressen erfasst wurden.
  • Adresslückenfehler: 20 aufeinanderfolgende ungenutzte externe Adressen können eine BIP-44-Suche vor einer späteren, nicht standardkonformen Nutzung stoppen.
  • Übersprungenes Konto: Die sequenzielle Kontosuche kann bei einem ungenutzten Konto stoppen und ein danach erstelltes Konto auslassen.
  • Unvollständige Bitcoin-Policy: Ohne Deskriptor, Skripte, Schwelle, Schlüsselreihenfolge, Fingerprints oder Prüfsumme kann ein Pfad finanzierte Ausgaben nicht rekonstruieren.
  • Wallet-spezifische Konvention: Eine Anwendung kann alte, proprietäre oder Migrationspfade nutzen, die ein allgemeines Wiederherstellungstool nicht aufzählt.
  • Datenschutzleck durch erweiterten öffentlichen Schlüssel: Ein xpub kann Adressgruppen, Verlauf, Guthaben und künftige nicht gehärtete Nachkommen offenlegen.
  • Übermäßige Offenlegung des erweiterten privaten Schlüssels: Der Import eines xprv kann einen ganzen Teilbaum statt nur des benötigten Blatts offenlegen.
  • Kompromittierung des BIP-32-Elternschlüssels: Ein Eltern-xpub zusammen mit einem passenden nicht gehärteten privaten Kindschlüssel kann den erweiterten privaten Elternschlüssel und seinen Teilbaum offenlegen.
  • Falsches Vertrauen in das Adressformat: Eine syntaktisch gültige Adresse beweist weder Seed, Pfad, Netzwerk und Skript noch Eigentum.
  • Netzwerkverwechslung bei gleicher Adresse: Ein EVM-Schlüssel kann in mehreren Netzwerken dieselbe Adresse erzeugen, obwohl Guthaben, nonce, Token und Risiken getrennt sind.
  • Bösartige Wiederherstellungssoftware: Websites, Erweiterungen, Bildschirmfreigabe, Zwischenablageüberwachung, Logger oder Fälschungen können das Root-Geheimnis abgreifen.
  • Verwechslung von Import und Sweep: Ein Import lässt die alte Befugnis bestehen; Sweep oder Migration erzeugen eine Transaktion, deren Gebühr und Ziel geprüft werden müssen.
  • Unvollständige Wiederherstellung: Ein gefundenes Guthaben ohne Prüfung von Signaturen, Wechselgeld, Token-Verträgen, Rollen, Freigaben, Validator-Schlüsseln und Sicherungen kann Vermögen verborgen oder exponiert lassen.

Häufige Missverständnisse

Ist der Ableitungspfad ein Passwort oder Geheimnis?

Nein. Ein Pfad beschreibt normalerweise eine öffentliche Struktur und sollte als Wiederherstellungs-Metadaten beibehalten werden. Er ersetzt nicht das Mnemonic, die Passphrase, den Seed, den privaten Schlüssel oder die Wallet-Richtlinie. Die Veröffentlichung eines Pfades kann organisatorische Informationen offenbaren, aber der bloße Besitz des Pfades verleiht keine Signierberechtigung.

Stellt dieselbe mnemonische Phrase immer automatisch dieselbe Wallet wieder her?

Nein. Das Ergebnis hängt auch vom Mnemonik-Schema, der genauen Passphrase, der Seed-Verarbeitung, dem Ableitungsalgorithmus, dem Pfad, der Kurve, dem Netzwerk und der Adress- oder Skripterstellung ab. Wallet-Software kann unterschiedliche Standardeinstellungen wählen, selbst wenn sie dieselben Wörter akzeptiert.

Verhindert der Coin-Typ eine Schlüsselnutzung auf einer anderen Blockchain?

Nein. Münztyp ist ein Ableitungs-Namespace und Kompatibilitätskonvention, keine Protokollberechtigung. Software kann einen Schlüssel anderswo ableiten oder wiederverwenden, und EVM-Netzwerke geben üblicherweise dieselbe Kontoadresse für denselben privaten Schlüssel preis.

Beweist ein leeres wiederhergestelltes Konto den Verlust der Vermögenswerte?

Nein. Es beweist nur, dass die derzeit abgefragten bestimmten Adressen und Netzwerke kein ermitteltes Guthaben anzeigen. Falsche Pfade, Konten, Zweige, Skripttypen, Erkennungsgrenzen, Token-Indizierung oder Netzwerkauswahl können alle die beabsichtigte Historie verbergen.

Kann ein Wiederherstellungstool jeden möglichen Pfad sicher ausprobieren?

Nein. Der Suchraum kann groß sein, Wallet-Konventionen sind nicht vollständig universell, und das Offenlegen eines Root-Geheimnisses an ein nicht vertrauenswürdiges Tool ist selbst ein Verlustereignis. Verwenden Sie Herkunft, aufgezeichnete Fingerabdrücke und Adressen, begrenzte Offline-Entdeckung und verifizierte Software, um die Suche einzuschränken.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...