Glossar / Adressen und Schlüssel
BIP-86-Ableitung
- Was ist die BIP-86-Ableitung?
- Die BIP-86-Ableitung legt Taproot-Konten mit einem einzigen Schlüssel auf m/86'/0'/0' und passt dann jeden abgeleiteten Schlüssel mit seinem eigenen Hash an, sodass die Adresse sich auf einen nicht ausgebbaren Skriptpfad festlegt.
Spezifiziert im BIP-86.
BIP-86 betrifft Wallets, die Taproot-Ausgaben für einen einzigen Unterzeichner verwahren, und verwendet das Kontoschema von BIP-44 mit 86' auf der Zweckebene wieder. BIP-49 und BIP-84 definieren ebenfalls einen zweiten Adressschritt, aber nur BIP-86 ändert den Schlüssel selbst: der 32 Byte große Wert in Ihrer Adresse ist der Schlüssel, den Sie abgeleitet haben, angepasst mit einem Hash seiner selbst. Stellen Sie Ihre Wörter in Software wieder her, die nur BIP-84 durchsucht, und Ihr bc1p-Guthaben zeigt null an.
Wie es funktioniert
Die BIP-86-Ableitung erfolgt in zwei Schritten, und nur der erste ist der vertraute Gang einen Schlüsselbaum hinunter.
Schritt eins ist der Pfad. Die Vorlage ist m / purpose' / coin_type' / account' / change / address_index, mit 86' an der Stelle des Zwecks und jeder Ebene darunter unverändert verwendet, sodass ein erstes Bitcoin-Konto auf m/86'/0'/0' liegt und sein erster Empfangsschlüssel auf m/86'/0'/0'/0/0.
Schritt zwei ist der Punkt, an dem sich BIP-86 von seinen Vorgängern trennt. BIP-49 und BIP-84 definieren ebenfalls einen zweiten Schritt, doch bei ihnen wird der abgeleitete Schlüssel in ein Skript eingebettet und der Witness offenbart weiterhin den Schlüssel, den der Pfad erzeugt hat. BIP-86 ersetzt den Schlüssel. Es zitiert BIP-341 zu der Regel, die es erfüllen muss: "If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path." Der abgeleitete Schlüssel wird also über lift_x als interner Schlüssel gelesen, und was in die Chain gelangt, ist dieser interne Schlüssel plus int(HashTapTweak(bytes(internal_key)))G. Das Ergebnis ist ein einzelner 32 Byte langer Push hinter OP_1, geschrieben als 0x5120 gefolgt vom angepassten Schlüssel, und für die Ausgabe genügt eine Signatur im Witness mit einem leeren scriptSig.
Die veröffentlichten Testvektoren zeigen die Lücke. Auf m/86'/0'/0'/0/0 ist der aus dem Seed abgeleitete interne Schlüssel cc8a4bc64d897bddc5fbc2f670f7a8ba0b386779106cf1223c6fc5d7cd6fc115, während der Schlüssel, den das Netzwerk sieht, a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c lautet, kodiert als bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr. Eine Implementierung, die Schritt zwei überspringt, veröffentlicht stattdessen den ersten Wert und liefert Ihnen damit plausibel aussehende Adressen, die eine konforme Wallet, die denselben Seed wiederherstellt, niemals finden wird.
Ava Chow schrieb das Dokument, das am 22. Juni 2021 zugewiesen wurde und heute den Status Deployed trägt.
Wo Sie es sehen
Die BIP-86-Ableitung steckt hinter den meisten Wallets mit einer einzigen Signatur, die Ihnen eine bc1p-Adresse aushändigen, ohne zu fragen, welches Format Sie möchten. Bitcoin Core machte Deskriptor-Wallets in Version 23.0 zur Voreinstellung, und die Versionshinweise zu dieser Version sagen, eine neu erstellte Deskriptor-Wallet enthalte einen automatisch erzeugten tr()-Deskriptor, "which allows for creating single key Taproot receiving addresses".
Die Hardware holte mit sehr unterschiedlicher Geschwindigkeit auf. Unsere Bewertung von KeepKey datiert die Unterstützung von Taproot-Ausgaben bei diesem Gerät auf Firmware 7.10.0 im Februar 2025, sodass ein günstiger Unterzeichner einen Seed verwahren kann, dessen 86'-Zweig er Ihnen nicht zeigt, während andere Software, die dieselben Wörter liest, diese Bitcoin normal ausgibt.
Die Spezifikation ist ungewöhnlich offen damit, warum ein fester Pfad weiterhin nötig ist. Ihr Abschnitt zur Motivation räumt ein, dass "there are now solutions which obviate the need for fixed derivation paths for specific script types", also Deskriptoren, und nennt dann, warum sie die Frage nicht klären: viele Software-Wallets und Hardware-Unterzeichner sichern weiterhin nur einen Seed, ohne Aufzeichnung des Pfads oder Skripttyps daneben. Ein Deskriptor trägt diese Information; eine Wortliste nicht, also trägt stattdessen die Zahl 86 sie.
BIP-86-Ableitung vs. P2TR
Die BIP-86-Ableitung ist ein Rezept zum Füllen einer P2TR-Ausgabe, nicht deren Definition. P2TR ist Witness-Version 1 und akzeptiert jeden beliebigen 32 Byte langen Ausgabeschlüssel, einschließlich eines aus mehreren Unterzeichnern unter MuSig2 aggregierten Schlüssels und eines Schlüssels, der sich auf einen Baum tatsächlich nutzbarer Skripte festlegt. BIP-86 betrifft den engsten Fall in diesem Bereich: einen Unterzeichner, einen Seed und einen Skriptpfad, der absichtlich nicht ausgebbar bleibt, damit sich nichts hinter dem Schlüssel verbirgt. Jede Adresse, die BIP-86 erzeugt, ist eine P2TR-Ausgabe, und das meiste, was P2TR ausdrücken kann, liegt völlig außerhalb seines Umfangs, sodass eine Wallet, die Taproot-Unterstützung anpreist, einen Multisig- oder zeitgesperrten Zweig im selben Adressformat dennoch ablehnen kann.