BIP48 erklärt: der Ableitungspfad hinter SSP

Bisher in dieser Serie haben wir behandelt, was Multisig ist und welche Schwelle zu wählen ist. Beide Artikel beschrieben das Verhalten einer Multisig-Wallet — m von n Schlüsseln signieren, die Chain prüft die Schwelle, Geld bewegt sich. Keiner sagte viel darüber, wie die Wallet tatsächlich darunter zusammengesetzt ist. Das ist dieser Artikel.

Die Kurzfassung: Wenn SSP eine Wallet für dich anlegt, generiert es nicht einfach zwei zufällige Schlüssel und ruft die Sache fertig. Es generiert sie auf eine Weise, die einem dokumentierten Standard namens BIP48 folgt, sodass die resultierende Wallet interoperabel, in anderer Software als SSP wiederherstellbar und on-chain vorhersehbar prüfbar ist. Das ist der Artikel, der erklärt, was BIP48 ist, warum es existiert und warum „diese Wallet nutzt BIP48" einer der langweiligsten und wichtigsten Sätze in Multisig ist.

TL;DR

• Ein Ableitungspfad ist der Weg von einer einzelnen Seed Phrase zu einem bestimmten Schlüssel (und einer Adresse) in einer Wallet. Standardisierte Pfade wie BIP44 / BIP48 lassen verschiedene Wallet-Software aus derselben Seed bei denselben Schlüsseln ankommen.
• BIP48 ist die Spezifikation speziell für Multisig-Wallets. Sie sagt: hier ist der kanonische Ableitungspfad für die m Schlüssel, die eine 2-of-3-, 3-of-5- usw. Wallet quer durch die wichtigsten Output-Skripttypen ausmachen.
• SSP nutzt BIP48. Das heißt, die beiden Seeds, die deine SSP-Wallet erzeugt hat, sind aus jeder anderen BIP48-kompatiblen Wallet (Sparrow, Electrum, die Descriptors von Bitcoin Core) nutzbar — nicht nur aus SSP.
• BIP48 behebt ein Problem, das die ältere Multisig-Spec (BIP45) hatte: sie trennt die Schlüssel für unterschiedliche Skripttypen (legacy, P2SH-wrapped SegWit, native SegWit, Taproot) sauber, sodass eine Seed Phrase sie alle ohne Kollision halten kann.
• Du musst dich nicht händisch mit Ableitungspfaden befassen, um SSP zu nutzen. Du solltest wissen, dass es sie gibt, damit „Wallet-Wiederherstellung" sich nicht wie Magie anfühlt — und damit du verstehst, worauf deine Seed eigentlich abgebildet wird.

Ein 30-Sekunden-Rundgang durch Ableitungspfade

Bevor BIP48 irgendeine Bedeutung haben konnte, musste die darunterliegende Maschinerie existieren. Diese Maschinerie ist BIP32: hierarchical deterministic (HD) Wallets. Die Kernidee ist, dass ein Master-Key — abgeleitet aus einer Seed Phrase — einen unendlichen Baum aus Kindschlüsseln deterministisch erzeugen kann. Gehst du einen bestimmten Pfad durch den Baum, landest du immer beim selben Kindschlüssel. Gehst du einen anderen, landest du bei einem anderen.

Pfade sehen so aus:

m / purpose' / coin_type' / account' / change / index

Zum Beispiel erreicht der BIP44-Pfad m / 44' / 0' / 0' / 0 / 0 die erste Empfangsadresse des ersten Kontos von Bitcoin unter BIP44-Regeln. Ändere coin_type auf 60' und du bist im Ethereum-Raum; ändere purpose auf 84' und du bist im BIP84- (native SegWit) Raum; und so weiter. Das Hochkomma (') ist hardened-Ableitung — das Kind lässt sich nicht zurück zur Eltern invertieren. Jeder Abschnitt nach dem Master ist eine 32-Bit-Zahl, per Konvention partitioniert.

Das ist der Teil, der gerne übersprungen wird: der Pfad ist Metadaten, kein Geheimnis. Wer deinen Pfad und deinen privaten Schlüssel (oder erweiterten Schlüssel) kennt, kann dieselben Adressen ableiten. Der Pfad sagt der Wallet wo nachschauen. Die Seed sagt ihr was dort liegt.

Für eine freundliche Auffrischung, was die Seed selbst ist, ist Seed Phrase Best Practices Voraussetzung.

Was BIP48 spezifiziert

BIP48 sitzt bei m / 48' / coin_type' / account' / script_type' / change / index. Die interessante Ergänzung ist script_type' — der vorletzte Abschnitt.

Dieser Abschnitt kodiert, welcher Typ von Multisig-Output für den Pfad gilt:

• 0' → P2SH (Legacy-Multisig)
• 1' → P2SH-wrapped SegWit (P2WSH-in-P2SH)
• 2' → native SegWit (P2WSH)
• 3' → Taproot-äquivalentes Multisig (per BIP48-Ergänzungen)

Das ist wichtig, weil in der Praxis dieselbe m-of-n-Cosigner-Menge unterschiedliche On-Chain-Adressen erzeugt, je nachdem, welches Output-Skript verwendet wird. Ohne BIP48 könnte eine Wallet stillschweigend einen Typ verwenden, die Recovery-Software einen anderen annehmen, und das Ergebnis sind zwei Wallets, die aussehen, als sollten sie dieselben Coins ableiten — aber das tun sie nicht, weil sie unterschiedliche Adressen berechnen.

BIP48 fixiert auch den purpose'-Abschnitt auf 48', sodass Multisig-Pfade nicht mit Single-Sig-Pfaden BIP44/BIP49/BIP84 kollidieren können. Eine Seed kann eine Single-Sig-Wallet unter BIP84 und eine 2-of-2-Multisig-Wallet unter BIP48 halten, ohne Interferenz. Jede lebt in ihrem eigenen Teilbaum.

Über den Pfad hinaus spezifiziert BIP48, wie die öffentlichen Cosigner-Schlüssel („xpubs") beim Bau des Multisig-Outputs sortiert werden müssen. Die kanonische Regel ist lexikographische Sortierung der Public Keys, bevor sie in das Redeem-Skript gehen. Das beseitigt Mehrdeutigkeit — jede BIP48-konforme Wallet, die aus denselben xpubs baut, berechnet dieselbe Adresse. Ohne diese Regel könnten zwei Wallets dieselben Keys in unterschiedlichen Reihenfolgen kombinieren und mit derselben Redeem-Regel bei unterschiedlichen Adressen landen.

Wenn du die Spec wortwörtlich lesen willst, sie lebt im Bitcoin-BIPs-Repo (bips/bip-0048.mediawiki).

Wie SSP BIP48 in der Praxis nutzt

Wenn du eine SSP-Wallet einrichtest, werden zwei Seed Phrases erzeugt — eine in der Browser-Erweiterung, eine in der mobilen App SSP Key. Jede Seed Phrase entspricht einem Master-Privatschlüssel. Aus jedem Master leitet SSP den BIP48-Pfad für die jeweilige Chain ab (Bitcoin, Ethereum, Flux und der Rest des SSP-unterstützten Sets) bei script_type' = 2' (native SegWit bei Bitcoin; entsprechende kanonische Formen auf den anderen Chains, wo zutreffend).

Die xpubs beider Signierer werden dann ausgetauscht. Jede Seite hat nun denselben Satz von zwei xpubs, lexikographisch nach BIP48 geordnet. Aus diesem Paar berechnet jede Seite unabhängig dieselbe Adresse. Die beiden Hälften teilen nie einen privaten Schlüssel — nur Public Keys wandern zwischen Geräten.

Wenn du Geld erhältst, ist die dir angezeigte Adresse die nach BIP48 abgeleitete Adresse, berechnet aus beiden xpubs. Wenn du ausgibst, signiert jedes Gerät dieselbe Transaktion unter seinem eigenen Privatschlüssel. Das Redeem-Skript on-chain verweist auf beide Public Keys; das Netzwerk prüft beide Signaturen. Das ist das gesamte Protokoll.

Der Grund, warum das in einem Recovery-Szenario zählt: würde SSP als Produkt morgen verschwinden, hieltest du immer noch zwei BIP48-konforme Seed Phrases. Beide in Sparrow zu laden (oder in jede andere multisig-fähige Wallet, die die von SSP verwendeten BIP48-Pfade unterstützt) rekonstruiert dieselbe Wallet, an denselben Adressen, mit voller Ausgabefähigkeit. Die Wallet lebt nicht in SSP — sie lebt on-chain, und die Seeds plus die BIP48-Spec reichen, um sie von überall zu erreichen.

Diese Eigenschaft ist ein großer Grund dafür, dass das Stück self-custody-without-cold-storage eine 2-of-2 SSP-Wallet als ernsthafte Wallet behandelt und nicht als custodial-getönte Kuriosität. Sie ist aus offenen Standards rekonstruierbar.

Warum BIP48 statt BIP45 (und nicht BIP44)

Die ältere Multisig-Spec war BIP45. Sie war ein ehrlicher erster Versuch: m / 45' / cosigner_index' / change / index, wobei cosigner_index' kodiert, welcher Cosigner du in der Wallet bist. Im Rückblick hatte sie zwei Probleme.

Erstens, cosigner_index' backte eine Reihenfolge in den Pfad selbst ein. Das hieß, die Reihenfolge, in der Signierer hinzugefügt wurden, beeinflusste die Ableitung, was den gemeinsamen Setup brüchig machte — falsche Reihenfolge, und du leitest andere Adressen ab als dein Cosigner. BIP48 löst das, indem es den Cosigner-Index vollständig aus dem Pfad nimmt und die lexikographische Sortierung der Public Keys das übernehmen lässt.

Zweitens, BIP45 trennte nicht nach Skripttyp. Derselbe Pfad würde wiederverwendet, egal ob die Wallet Legacy-P2SH-Multisig oder SegWit-wrapped Multisig nutzt. Das erzeugte dasselbe Problem von Adresskollisionen-die-eigentlich-nicht-dieselben-Coins-sind wie oben beschrieben.

BIP44, die allgemeinere HD-Spec, behauptete nie, Multisig abzudecken. Den Versuch, BIP44 mit Multisig-Pfaden zu überlasten, schuf eigene Konflikte. BIP48 war die explizite Korrektur: eine dedizierte Purpose-Nummer, ein expliziter Script-Type-Slot und eine deterministische Schlüsselsortierung. Heute konvergieren die meisten modernen Multisig-Wallets darauf; es ist der De-facto-Standard.

Für die tiefere Geschichte, wie das ans nächste Kapitel des Multisig anknüpft — Schnorr-Aggregation, bei der mehrere Signaturen zu einer komprimiert werden — der nächste Artikel dieser Serie, Schnorr signatures and multisig aggregation, nimmt den Faden auf.

Was das für die Interoperabilität bedeutet

Der sauberste Test für „ist diese Multisig-Wallet wirklich self-custodial?" ist: kann ich sie ohne die Wallet-Software wiederherstellen? Wenn die Antwort ja ist — mit dokumentierten Seeds, einem dokumentierten Ableitungspfad und Standard-Tools — gehört die Wallet wirklich dir. Wenn die Antwort nein ist, hat die Wallet versteckte custodial Elemente.

SSPs BIP48-Konformität ist, was uns erlaubt, ja zu antworten. Die Seed Phrases sind BIP39 (Standard-Mnemonic), die Ableitung ist BIP48, der Adressaufbau ist BIP48-kanonisch. Jede Wallet, die dieselben Standards spricht, kann die Wallet rekonstruieren.

Deshalb rahmt die Einführung Meet SSP Wallet SSP als „Self-Custody mit 2-of-2-Multisig" anstatt als verwalteten Dienst. Die Standards darunter sind der Grund, warum dieser Rahmen ehrlich ist.

Was das für dich bedeutet

Drei Kernpunkte:

1. Du musst Pfade nicht auswendig lernen, um SSP zu nutzen. Die Zahl m/48'/0'/0'/2'/0/0 ist nichts, was ein normaler Nutzer je tippen sollte. Aber zu wissen, dass es sie gibt, ist, was „ich kann diese Wallet ohne SSP wiederherstellen" zu einer echten Aussage statt zu Marketing macht.
2. Deine beiden Seeds sind interoperabel. Falls du je in eine Drittanbieter-Multisig-Wallet wiederherstellen musst, ist BIP48 plus deine zwei BIP39-Seeds plus der coin_type der Chain das Rezept. Die Self-Custody-Checkliste nennt das aus gutem Grund als Übungsschritt.
3. Eine Multisig-Wallet, die kein BIP48 (oder Ähnliches) nutzt, ist es wert, hinterfragt zu werden. Wenn ein Produkt dir nicht genau sagen kann, wie Adressen aus deinen Schlüsseln abgeleitet werden, ist das keine Self-Custody — das ist Custody mit zusätzlichen Schritten. Standards-Konformität ist, was „deine Schlüssel, deine Coins" überprüfbar macht.