Komprimierter öffentlicher Schlüssel

Jeder Punkt auf secp256k1 hat für ein gegebenes x zwei mögliche y-Werte, sodass die Angabe, welcher davon gilt, ein einzelnes Byte statt 32 kostet. Wallets erzeugen standardmäßig komprimierte Schlüssel seit Bitcoin Core 0.6, veröffentlicht im März 2012, und die eingesparten Bytes gehen von der Größe jedes Inputs ab, den Sie später ausgeben. Günstigeres Ausgeben ist der ganze Nutzen, und im täglichen Gebrauch ist das Format unsichtbar.

So funktioniert es

Die Kompression öffentlicher Schlüssel ist Algebra und keine Datenkompression. Die Kurvengleichung, y zum Quadrat gleich x hoch drei plus 7, hat für jedes gegebene x höchstens zwei Lösungen für y, und diese beiden Lösungen sind immer eine gerade und eine ungerade Zahl. x plus ein Bit Information darüber zu speichern, welche Lösung gilt, reicht daher aus, damit jeder den Punkt exakt wiederherstellen kann, indem er die Gleichung löst und die Wurzel mit der richtigen Parität wählt.

Die Kodierung legt dieses Bit in das führende Byte. Ein Präfix von 0x02 bedeutet, dass der y-Wert gerade ist, 0x03 bedeutet, dass er ungerade ist, und die 32 folgenden Bytes sind die x-Koordinate. Gesamtlänge: 33 Bytes. Das alte Format kennzeichnet sich mit einem 0x04-Präfix und trägt beide Koordinaten vollständig, für 65 Bytes. Jede Software, die einen Schlüssel liest, kann die beiden allein am ersten Byte unterscheiden, und so blieben Wallets während des Übergangs kompatibel.

Die eingesparten 32 Bytes fallen je nach Ausgabetyp an unterschiedlichen Stellen an. In einem Legacy-Input sitzt der Schlüssel im Entsperrskript und wird mit vollem Gewicht berechnet, sodass 32 Bytes 32 vbytes kosten, etwa 640 Satoshi bei einer Gebühr von 20 sat/vB. In einem SegWit-Input sitzt der Schlüssel im Witness, der um den Faktor vier rabattiert wird, sodass dieselben 32 Bytes 8 vbytes kosten. Keine der beiden Zahlen ist für sich genommen dramatisch, und beide wiederholen sich bei jedem Input jeder Transaktion, die Sie jemals signieren.

Wo Sie es sehen

Komprimierte Schlüssel begegnen Ihnen in Rohdaten von Transaktionen. Öffnen Sie eine beliebige aktuelle Ausgabe in einem Block-Explorer, und der öffentliche Schlüssel im Witness oder im Skript beginnt mit 02 oder 03, gefolgt von 64 Hexadezimalzeichen. Schlüssel, die mit 04 beginnen, sind Überbleibsel.

Das Format entscheidet außerdem, wie eine Adresse aussieht. Das Hashing eines komprimierten Schlüssels ergibt ein anderes Ergebnis als das Hashing der unkomprimierten Version desselben Schlüssels, sodass ein privater Schlüssel zu zwei völlig getrennten Legacy-Adressen mit getrennten Beständen gehören kann. Wallets regeln das per Konvention und nicht per Cleverness: alles, was über BIP-32 abgeleitet wird, was jede Wallet mit Seed-Phrase im üblichen Gebrauch abdeckt, ist durchgehend komprimiert, und eine Zeichenkette im Wallet Import Format, die mit K oder L beginnt, zeigt an, dass der Schlüssel zur komprimierten Seite dieser Abspaltung gehört.

SegWit hat die Unklarheit endgültig beseitigt. BIP-143 verbietet unkomprimierte Schlüssel in Witness-Programmen der Version 0, sodass jede bc1q-Adresse per Regel komprimiert ist, und Taproot ging noch weiter, indem es x-only-Schlüssel von 32 Bytes definierte, die das Paritätsbyte ganz weglassen.

Komprimierter öffentlicher Schlüssel vs. unkomprimierter öffentlicher Schlüssel

Die komprimierte und die unkomprimierte Form kodieren denselben Punkt, und der Unterschied besteht nur darin, was aufgeschrieben werden muss. Die komprimierte Form behält x und leitet y bei Bedarf ab, was ein paar Mikrosekunden Rechenzeit kostet und für immer 32 Bytes spart. Die unkomprimierte Form speichert y direkt, was auf Hardware aus dem Jahr 2009 Rechenzeit sparte und heute nichts einbringt. Weil sich die beiden Byte-Zeichenketten unterscheiden, ergeben sie beim Hashing verschiedene Adressen, und diese Diskrepanz, nicht die Byte-Anzahl, ist der Grund, warum gelegentlich Mittel aus sehr alten Wallets feststecken.