MSTR Cat

Blockchain/Niveau IV · Tiefer ins Protokoll/4.3 Verwahrung und Privatsphäre/Lektion 1

HD-Wallets (BIP32, BIP44, BIP84, BIP86)

Ableitung eines Schlüsselbaums aus einem einzigen Seed

MaterialienEine Wallet im Testmodus (Testnet oder Signet) – niemals ein echter SeedEine HD-Wallet oder ein Tool, das Ableitungspfade anzeigtEin Notizbuch

Neugier

  1. Wie kann ein einziger Seed eine praktisch unbegrenzte Anzahl einzigartiger, wiederherstellbarer privater Schlüssel erzeugen?
  2. Warum kann ein einziger geleakter privater Kindschlüssel zusammen mit dem erweiterten öffentlichen Schlüssel des Elternschlüssels jeden Schlüssel in einem nicht gehärteten Zweig offenlegen?
  3. Welcher strukturelle Unterschied trennt eine Legacy-P2PKH-Adresse hinsichtlich der Gebühreneffizienz von einer Native-SegWit- oder Taproot-Adresse?

Erkunden

  1. Vor BIP32, das 2012 von Pieter Wuille eingeführt wurde, erzeugten Wallets für jede neue Adresse zufällige Schlüsselpaare. Eine Wallet zu sichern bedeutete, jeden einzelnen privaten Schlüssel separat zu speichern; ging eine Sicherungsdatei verloren, waren genau diese Guthaben nicht mehr wiederherstellbar. BIP32 änderte dieses Modell, indem es aus einem einzigen Master-Seed einen deterministischen Schlüsselbaum ableitet. Die gesamte finanzielle Historie ist nun an diesen einen Seed gebunden, der in der Regel aus 128 oder 256 Bit Entropie erzeugt und als 12 oder 24 Wörter notiert wird.
  2. Der Ableitungspfad folgt der in BIP44 (2014) definierten Struktur: `m / purpose' / coin_type' / account' / change / index`. Der Apostroph kennzeichnet die gehärtete Ableitung. Sie ist ein entscheidender Sicherheitsmechanismus. Bei nicht gehärteter Ableitung kann ein Angreifer, der sowohl den erweiterten öffentlichen Schlüssel des Elternschlüssels (xpub) als auch einen beliebigen einzelnen privaten Kindschlüssel erlangt, den privaten Elternschlüssel mathematisch berechnen. Die gehärtete Ableitung durchbricht diese Verbindung; ein geleakter privater Kindschlüssel verrät zusammen mit dem xpub nichts über das Geheimnis des Elternschlüssels.
  3. BIP44 hat die ersten drei Ebenen standardisiert, um die Unterstützung mehrerer Währungen innerhalb einer einzigen Hierarchie zu ermöglichen. Die Ebene `purpose'` kennzeichnet den Standard (z. B. 44 für BIP44, 84 für BIP84). Die Ebene `coin_type'` unterscheidet die Assets; Bitcoin hat den Index 0. So kann ein einziger Seed verschiedene Kryptowährungen verwalten, ohne deren Schlüssel zu vermischen. Die Ebene `account'` ordnet Guthaben separaten Konten zu, jedes mit einer eigenen Change-Kette. Erweiterte öffentliche Schlüssel (xpubs) werden typischerweise auf dieser Ebene abgeleitet.
  4. BIP84 aktualisierte den Standard für Native-SegWit-Adressen, die mit `bc1q` beginnen. Er setzt den Purpose auf 84. Diese Adressen sind effizienter als Legacy-Formate, weil ihre Witness-Daten bei der Berechnung des Transaktionsgewichts rabattiert werden, was die Gebühren senkt. Der Ableitungspfad lautet `m / 84' / 0' / account' / change / index`. So wird beispielsweise die erste externe Adresse von Konto 0 unter `m/84'/0'/0'/0/0` abgeleitet. Diese Struktur ermöglicht es Servern, Empfangsadressen aus einem xpub zu erzeugen, ohne jemals einen privaten Schlüssel anzurühren.
  5. BIP86, ein eigenständiger Ableitungsstandard, den Ava Chow 2021 für Taproot verfasst hat, setzt den Purpose auf 86 und leitet Taproot-Adressen mit einem einzigen Schlüssel ab, die mit `bc1p` beginnen. BIP86 deckt Taproot-Outputs mit einem einzigen Schlüssel und ohne Skriptbaum ab. Da ein Taproot-Key-Path auch einen aggregierten Schlüssel enthalten kann, etwa einen MuSig2-Schlüssel, können die Outputs einer Multi-Party-Wallet on-chain genauso aussehen wie diese Single-Key-Outputs.
  6. Wallets scannen vorausschauend, um verwendete Adressen zu erkennen, und hören in der Regel nach einem „Gap Limit“ von 20 aufeinanderfolgenden ungenutzten Adressen in einer Kette auf. Werden in diesem Bereich keine Transaktionen gefunden, geht die Wallet davon aus, alle vorhandenen Schlüssel dieses Kontos gefunden zu haben. Um diesen Mechanismus zu überprüfen, öffnen Sie eine beliebige moderne HD-Wallet und suchen Sie die Einstellungen für den Ableitungspfad. Bestimmen Sie jede Ebene: Purpose, Coin-Typ, Konto, Change und Index. Leiten Sie aus demselben Seed zwei verschiedene Pfade ab, um zu bestätigen, dass sie unterschiedliche Schlüssel erzeugen und dennoch vollständig aus der ursprünglichen Mnemonic-Phrase wiederherstellbar bleiben.

Kernfakten

  • BIP32 erzeugt einen deterministischen Baum von Kindschlüsseln aus einem einzigen Master-Seed.
  • Die gehärtete Ableitung (markiert mit `'`) verhindert, dass der Elternschlüssel preisgegeben wird, wenn ein privater Kindschlüssel und der xpub kompromittiert sind.
  • Die BIP44-Pfadstruktur lautet `m / purpose' / coin_type' / account' / change / index`.
  • Purpose 84 entspricht Native-SegWit-Adressen (`bc1q`), die gebühreneffizienter sind als Legacy-Formate.
  • Purpose 86 entspricht Taproot-Adressen mit einem einzigen Schlüssel (`bc1p`).
  • Wallets hören in der Regel nach 20 aufeinanderfolgenden ungenutzten Adressen mit dem Scannen auf (das Gap Limit).

Übung neun, sechs, drei, eins

9SammelnListen Sie 9 Ableitungspfade aus verschiedenen Wallets oder Standards auf. Notieren Sie jeweils Purpose, Coin-Typ und Adressformat.
6GruppierenGruppieren Sie die 9 nach ihrem Skripttyp in 6 Kategorien: Legacy P2PKH, Nested SegWit, Native SegWit, Taproot, Multi-Währung oder Sonstiges.
3VerdichtenReduzieren Sie die 6 auf 3 Gründe, warum ein Wallet-Entwickler einen Ableitungspfad einem anderen vorziehen würde.
1KristallisierenSchreiben Sie 1 Satz, der erklärt, wie die gehärtete Ableitung einen Master-Schlüssel davor schützt, über Kindschlüssel offengelegt zu werden.

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

In der interaktiven Akademie öffnen →

EN PT ES ZH JA KO RU FR MS