Extended Public Key (xpub)

Anna nutzt eine Hardware-Wallet und möchte auf dem Handy prüfen, ob ein Kunde bezahlt hat. Dazu überträgt sie die öffentliche Konfiguration des gewählten Kontos mitsamt xpub auf das Handy, aber keine privaten Schlüssel. Das Handy arbeitet dann als Watch-only Wallet: Es beobachtet die zugehörigen Adressen, bereitet neue vor und erstellt unsignierte Transaktionen. Zum Ausgeben braucht es weiterhin die Signatur des Geräts mit den geheimen Schlüsseln. Ebenso kann ein Shop unterschiedliche Empfangsadressen für Bestellungen erzeugen, ohne Ausgabeschlüssel auf seinem Server zu speichern. Das begrenzt die Folgen eines Servereinbruchs, löst aber nicht alles: Ein Angreifer könnte Kunden für neue Zahlungen seine eigene Adresse anzeigen. [1] [5]

Eine gewöhnliche Bitcoin-Adresse gibst du jemandem, der dich bezahlen soll. Ein xpub eröffnet einen deutlich größeren Einblick. Wer den xpub eines Kontos und dessen Adressregeln kennt, kann Empfangs- und Wechselgeldadressen berechnen und ihre Historien und Guthaben verknüpfen. Das betrifft den ableitbaren Zweig, nicht automatisch jedes Konto der Wallet. Gibst du den xpub einem Buchhaltungsdienst oder fremden Block-Explorer, kann dieser eine Kopie behalten und spätere Zahlungen beobachten. Das Trennen der App-Verbindung widerruft eine bereits weitergegebene Kopie nicht. Für eine einzelne Zahlung reicht normalerweise eine Adresse; gewähre weitergehenden Einblick nur mit gutem Grund. [1] [5]

Eine BIP32-Wallet erzeugt aus einem Ausgangspunkt einen Schlüsselbaum. Ein Zweig meint hier eine Gruppe abgeleiteter Schlüssel, keinen Teil des Netzwerks oder der Blockchain. Ein xpub kann nur über sogenannte non-hardened Schritte nach unten weitergeführt werden. Die andere Art, Hardened Derivation, benötigt private Daten und bildet eine Grenze, die der xpub allein nicht überschreiten kann. Ein übliches BIP44-Schema setzt diese Grenze vor die einzelnen Konten. Der Export eines Konto-xpub legt daher nicht von sich aus andere Konten offen. Auch die Exporttiefe zählt: Ein xpub nur des Empfangszweigs erlaubt weniger Einblick als der des ganzen Kontos, der üblicherweise auch Wechselgeld erfasst. [1] [6]

Aus denselben öffentlichen Schlüsseln können nach unterschiedlichen Regeln verschiedene Bitcoin-Adressen entstehen. Ein Transaktionsausgang hält einen Betrag und die Bedingungen fest, unter denen er später ausgegeben werden kann. Die Anwendung muss deshalb den Typ des Transaktionsausgangs der Wallet kennen, etwa Native SegWit oder Taproot, sowie den abzuleitenden Zweig und dessen laufende Nummern. Präfixe wie ypub und zpub nach SLIP-0132 können den Adresstyp andeuten, beschreiben aber nicht die gesamte Wallet. Präziser ist ein Output Descriptor: ein Text, der Schlüssel und Regeln für Adressen und Ausgabebedingungen festhält. Er kann Schlüsselherkunft, Ableitungspfad und eine Prüfsumme gegen Tippfehler enthalten. Diese prüft den Text, nicht die Vertrauenswürdigkeit seines Absenders. Nicht jeder Descriptor enthält nur öffentliche Daten: Manche enthalten private Schlüssel. Das musst du vor dem Teilen unterscheiden. [2] [3] [4]

Prüfe zuerst Netzwerk, ausgewähltes Konto, Adresstyp und Ableitungspfad, also die Anweisungen zur Position des Schlüssels im Baum. Vergleiche mehrere Empfangsadressen mit der ursprünglichen Wallet und nutze bei einer Hardware-Wallet deren vertrauenswürdiges Display nach Herstelleranleitung. Ein übereinstimmender Kontoname reicht nicht. Ein Nullsaldo nach dem Import bedeutet nicht unbedingt verlorenes Geld: Vielleicht beobachtest du ein anderes Konto, einen anderen Adresstyp oder einen zu kleinen Bereich von Adressindizes. Gib deshalb keine Wiederherstellungswörter auf einer beliebigen Website ein. Für einen reinen Überblick brauchst du den Export der öffentlichen Konfiguration, keine Seed Phrase und keinen xprv, also keinen erweiterten privaten Schlüssel. [4] [5]

Ein xpub allein ist kein Signierschlüssel. BIP32 enthält aber einen wichtigen Zusammenhang: Ein übergeordneter xpub, in der Dokumentation parent xpub genannt, zusammen mit dem privaten Schlüssel eines non-hardened Nachkommen erlaubt die Berechnung des übergeordneten privaten Schlüssels. Bei einem weiter entfernten Nachkommen dürfen dazwischen nur non-hardened Schritte liegen; der zugehörige Pfad muss für die Berechnung bekannt sein. Es geht nicht um Diebstahl allein durch Kenntnis einer Adresse. Gefährlich ist die Kombination aus offengelegtem öffentlichen Einblick und einem geleakten geheimen Schlüssel desselben Zweigs. So kann ein Angreifer auch die weiteren Schlüssel unter diesem Elternschlüssel erhalten. Hardened-Grenzen trennen Konten, schützen aber keinen bereits offengelegten privaten Schlüssel. [1]

Eine Multisig-Wallet kann beispielsweise zwei Signaturen von drei Schlüsseln verlangen. Es genügt aber nicht zu wissen, welche zwei Schlüssel du wiederherstellen kannst. Um die richtigen Ausgabebedingungen nachzubilden, brauchst du auch die öffentlichen Daten der übrigen beteiligten Schlüssel, ihre Anordnung, die erforderliche Signaturzahl und die Ableitungsregeln. Bewahre deshalb neben geheimen Backups die Wallet-Konfiguration auf, etwa einen öffentlichen Descriptor mit allen benötigten xpubs. Er erlaubt keine Ausgabe, kann für die Wiederherstellung aber unerlässlich sein. Der Master Fingerprint, acht Hexadezimalzeichen zur Kennzeichnung des Ausgangsschlüssels, hilft bei der Zuordnung. Er ist kein eindeutiger Identitätsnachweis: Verschiedene Schlüssel können denselben Fingerprint haben. [4] [5]

Mit einem öffentlichen Schlüssel werden Signaturen geprüft, die mit dem passenden privaten Schlüssel erstellt wurden. BIP32 ergänzt einen chain code, einen 32-Byte-Wert zum Ableiten weiterer Schlüssel. Zusammen bilden sie den erweiterten öffentlichen Schlüssel. Seine übertragbare Darstellung enthält außerdem Version und Position im Baum: Tiefe, Fingerprint des unmittelbaren Elternschlüssels und Nummer des Kindes. Das ist nicht der vollständige Pfad vom ersten Schlüssel der Wallet aus. Ein xpub ist daher weder eine einzelne Empfangsadresse noch ein Kontopasswort und enthält keine Transaktionsliste. Die beobachtende Wallet sucht diese für die entsprechenden Adressen auf der Blockchain heraus. [1]

Die BIP32-Funktion CKDpub nimmt den öffentlichen Elternschlüssel, seinen chain code und einen Kindindex. HMAC-SHA512, eine kryptografische Berechnung mit diesen Eingaben, liefert Daten für einen weiteren öffentlichen Schlüssel und einen neuen chain code. Öffentlich ableitbare Indizes reichen von 0 bis 2³¹−1. Hardened-Indizes beginnen bei 2³¹ und werden in Pfaden meist durch Apostroph oder h markiert; CKDpub aus einem xpub genügt dafür nicht. Wiederholte erlaubte Schritte erzeugen Nachkommen, keine Geschwister oder Vorfahren des exportierten Schlüssels. Tritt ein in BIP32 beschriebener seltener ungültiger Wert auf, geht die Implementierung zum nächsten Index weiter. Nutzer müssen das nicht selbst berechnen; entscheidend ist die korrekte Übertragung der Konfiguration. [1]

Vor der Textkodierung umfasst der BIP32-Datensatz 78 Byte: Version 4, Tiefe 1, Eltern-Fingerprint 4, Kindnummer 4, chain code 32 und Schlüsseldaten 33. Base58Check ergänzt eine Prüfsumme und wandelt den Datensatz in 111 Zeichen um. Die öffentliche Version für das Bitcoin-Hauptnetz beginnt mit xpub, die Testversion mit tpub; die privaten Gegenstücke beginnen mit xprv und tprv. Tpub bedeutet nicht Taproot. Das Präfix entsteht aus den Versionsbytes und beschreibt nicht sämtliche Adressregeln. Beim Import muss die Software auch den öffentlichen Schlüssel validieren, nicht nur dessen erste Buchstaben oder Länge prüfen. [1] [3]