Glossar / Lightning und Layer 2
Onion-Routing
Auch bekannt als Sphinx.
- Was ist Onion-Routing?
- Onion-Routing ist die mehrschichtige Verschlüsselung, mit der Lightning eine Zahlung über mehrere Sprünge sendet und jedem Node nur die Anweisungen für die eigene Weiterleitung gibt und sonst nichts.
Jede Lightning-Zahlung reist in einem Paket fester Größe von 1.366 Byte, dessen Schichten eine nach der anderen abgezogen werden, sodass ein weiterleitender Node seinen Vorgänger und seinen Nachfolger erfährt, mehr nicht. Das Paket behält auf jedem Sprung dieselbe Größe und verbirgt damit die Länge der Route und Ihre Position darin. Ihre Privatsphäre gegenüber Fremden in der Mitte ist stark; gegenüber der Wallet oder der Börse an beiden Enden ist sie es nicht.
Wie es funktioniert
Onion-Routing verschlüsselt die Route in Schichten, eine pro Sprung, in umgekehrter Reihenfolge verpackt, sodass das Abziehen der äußersten Schicht die einzige Operation ist, die ein Node ausführen kann.
BOLT 4 nennt die Konstruktion Sphinx, erweitert um eine Nutzlast pro Sprung. Bevor die Zahlung sich bewegt, kennt Ihre Wallet den öffentlichen Schlüssel jedes Nodes auf der Route und verwendet ECDH gegen jeden einzelnen, um ein gemeinsames Geheimnis abzuleiten. Aus jedem gemeinsamen Geheimnis gehen vier Schlüssel hervor: rho erzeugt den Bytestrom, der das Paket verschleiert, mu berechnet den Integritäts-HMAC, der Schlüssel um authentifiziert Fehler auf dem Rückweg, und pad initialisiert die Füllung. Dieser Strom ist ChaCha20 über Nullen mit einem Null-Nonce von 96 Bit, hier nur deshalb sicher, weil kein Schlüssel jemals wiederverwendet wird.
Das Paket hat vier Felder und eine feste Größe: ein Versionsbyte, derzeit 0x00, einen komprimierten secp256k1-Punkt von 33 Byte, der als ephemerer Schlüssel dient, 1.300 Byte an Sprung-Nutzlasten und einen HMAC von 32 Byte. Das sind 1.366 Byte auf der Leitung, ohne Längenpräfix.
Die Montage läuft rückwärts. Der Bereich von 1.300 Byte beginnt als Zufallsbytes aus einem ChaCha20-Strom, und für jeden Sprung vom letzten bis zum ersten wird er nach rechts verschoben, um Platz zu schaffen, wodurch das ferne Ende über den Rand geschoben und verworfen wird. Bei einer Nutzlast unter 253 Byte ist die Verschiebung die Länge dieser Nutzlast plus 33: ein Längenbyte und 32 Byte HMAC. Auf jede Verschiebung folgt ein XOR gegen den rho-Strom des Sprungs, das die früheren Schichten erneut durchmischt.
Was ein Sprung liest, ist eine kurze Liste typisierter Felder: Typ 2 ist amt_to_forward in Millisatoshi, Typ 4 ist outgoing_cltv_value, die Zeitsperre, die er auf den HTLC setzen muss, den er als Nächstes anbietet, und Typ 6 ist short_channel_id, der den zu verwendenden Kanal benennt, wobei ein Node jedoch einen anderen Kanal zum selben Peer einsetzen kann. Anstelle dieser kurzen Kanal-ID erhält der letzte Node Typ 8, der ein Zahlungsgeheimnis von 32 Byte und den Gesamtbetrag trägt.
Ein weiterer Schritt hält aufeinanderfolgende Pakete unverknüpfbar. Jeder Sprung verändert den ephemeren Schlüssel vor der Weitergabe mit einem Blinding-Faktor, sodass dieselbe Onion auf jeder Strecke, die sie überquert, wie unzusammenhängende Bytes aussieht. BOLT 4 ist ehrlich über die Grenze: Die Verschleierung "does not preclude the possibility of packet association by an attacker via traffic analysis."
Warum das wichtig ist, wenn Sie Bitcoin kaufen
Onion-Routing schützt Sie vor den Fremden in der Mitte einer Route und vor niemandem an ihren beiden Enden, und das ist das am meisten missverstandene Thema bei der Privatsphäre von Lightning.
Der erste Sprung ist meist ein Dienst, mit dem Sie bereits eine Beziehung haben, und er sieht weit mehr als ein zufälliger Weiterleiter. Unsere Bewertung von Phoenix zitiert die FAQ von ACINQ selbst, ohne sie abzuschwächen: "The current version of Phoenix offers no advantage regarding privacy over existing, hosted, custodial wallets. We (ACINQ) know the final destination and amount of payments." Phoenix erreicht hier 4,0 und ist wirklich selbstverwahrend, ein echter Node auf dem Smartphone hinter einer Seed-Phrase aus 12 Wörtern. Verwahrung und Privatsphäre sind getrennte Fragen, und Phoenix beantwortet nur eine davon gut.
Das empfangende Ende ist nicht besser. Strike verwahrt die Gelder, solange sie in der App liegen, und verlangt eine Identitätsprüfung, sodass eine Lightning-Auszahlung an Ihre eigene Wallet Strike den Betrag, den Zeitpunkt und die bezahlte Rechnung verrät, ganz gleich, wie viele Sprünge die Onion überquert hat. Wallet of Satoshi trägt hier einen Warnstatus und eine Bewertung von 2,7, teilweise weil das Unternehmen die Schlüssel hält, und es hat seinen verwahrenden Lightning-Dienst bereits aus der Europäischen Union zurückgezogen.
Betrachten Sie Onion-Routing also nicht als Umgehung von Compliance. Es ändert nicht, welcher Legalitätsabschnitt eines Länderratgebers für Sie gilt, es verbirgt keinen Kauf vor der Börse, die ihn verkauft hat, und es nützt Ihnen nichts, wenn der Betreiber Ihrer Wallet einer der Endpunkte ist. Was es bietet, ist trotzdem erstrebenswert: Ein Routing-Node, von dem Sie nie gehört haben, kann keinen Graphen darüber erstellen, wer wem zahlt, kann nicht erkennen, ob Sie der Absender oder ein weiterer Sprung sind, und kann eine kurze Route nicht von einer langen unterscheiden.
Eine Rechnung von Strike über zwei Nodes bezahlen, von denen Sie nie gehört haben
Eine Rechnung von Strike über Lightning zu bezahlen zeigt, was jeder Node auf einer Route erfährt und was nicht.
Angenommen, Ihre Wallet wählt einen Pfad aus vier Nodes: Ihren eigenen Peer, zwei öffentliche Routing-Nodes und dann Strike. Das Paket wird von Strike aus rückwärts aufgebaut. Die Nutzlast von Strike erhält den Endbetrag und das Zahlungsgeheimnis. Jede mittlere Nutzlast erhält einen amt_to_forward, der noch die Gebühren aller nachfolgenden Nodes enthält, einen outgoing_cltv_value, der um das vom Node angegebene Delta verringert wurde, und die short_channel_id der zu verwendenden Verbindung.
Der zweite Routing-Node liest genau eine Nutzlast. Er erfährt, dass der Node vor ihm einen HTLC übergeben hat und dass er einen etwas kleineren weiter anbieten muss. Er erfährt nicht, dass Strike am Ende steht, erfährt nicht, dass Sie am Anfang stehen, und kann nicht sagen, ob der Pfad vier oder acht Sprünge hat, weil der Bereich, den er weitergibt, dieselben 1.300 Byte sind, die er empfangen hat.
Hat dieser Node keine Liquidität für die Weiterleitung, baut er ein Rückpaket: einen HMAC unter seinem um-Schlüssel, einen Fehlercode, eine Füllung, die so gewählt ist, dass die Fehlermeldung plus Füllung mindestens 256 Byte erreicht, und das Ergebnis per XOR mit einem Strom aus einem ammag-Schlüssel verknüpft. Jeder Sprung auf dem Rückweg verschleiert es erneut. Ihre Wallet entfernt die Schichten und entschlüsselt dann weiter, bis die Schleife 27 Mal durchlaufen wurde, die längste Route, die das TLV-Nutzlastformat zulässt, damit der fehlschlagende Node seine Position nicht durch die Zeitmessung eines wiederholten Versuchs ermitteln kann. Neuere Nodes hängen außerdem Attributionsdaten an: auf 4 Byte gekürzte HMACs, 210 davon für eine Route der Höchstgröße von 20 Sprüngen, und Haltezeiten in Einheiten von 100 Millisekunden.
Onion-Routing vs. Blinded Path
Onion-Routing verbirgt die Route vor den Nodes, die eine Zahlung transportieren, während ein Blinded Path das Ende der Route vor der zahlenden Person verbirgt.
Einfaches Onion-Routing verlangt, dass der Absender den echten öffentlichen Schlüssel jedes Nodes kennt, weil die gemeinsamen Geheimnisse aus ECDH gegen diese Schlüssel stammen. Route Blinding kehrt das für das letzte Teilstück um: Der Empfänger baut eine Kette veränderter Node-IDs, die Bob zu Bob prime und Carol zu Carol prime im eigenen Beispiel von BOLT 4 macht, und übergibt dem Absender dann einen Einstiegspunkt plus einen verschlüsselten Blob pro Sprung. Der Absender wickelt eine Onion um Blobs, die er nicht lesen kann. Die beiden ergänzen sich, statt zu konkurrieren: BOLT 4 verlangt, dass jede Onion-Nachricht Route Blinding verwendet, und eine Onion-Nachricht nutzt dieselbe Paketform wie eine Zahlungs-Onion.
Onion-Routing vs. HTLC
Onion-Routing trägt die Anweisungen und ein HTLC trägt das Geld, und eine Lightning-Zahlung braucht beides, weil jedes das andere prüft.
Die Onion sagt einem Sprung, wohin er weiterleiten soll und wie viel. Der HTLC ist die bedingte Zahlung, die tatsächlich auf dem Kanal angeboten wird. Weil der Nutzlastbereich von einem paketweiten HMAC abgedeckt wird, den nur der Absender und dieser Sprung erzeugen können, vergleicht ein Node den ihm angebotenen HTLC mit dem für ihn geschriebenen amt_to_forward und outgoing_cltv_value und lässt ihn scheitern, wenn sie nicht übereinstimmen, was einen vorgelagerten Node entlarvt, der den Betrag still kürzt. Sie können auch auseinanderfallen: Eine Onion-Nachricht, Typ 513, ist dieselbe Konstruktion ohne Geld, und von einem mittleren Sprung kommt für sie nie ein Fehler zurück.