Blinded Path

Der Empfänger baut den Pfad und gibt ihn heraus, sodass der Zahler nur bis zu einem öffentlichen Einstiegspunkt weiterleitet. Eine BOLT-12-Rechnung wird abgelehnt, wenn sie keinen geblindeten Pfad enthält, und die geblindeten Hops teilen sich die feste Nutzlast von 1300 Bytes der Zwiebel mit dem Rest der Route. Wenn Sie ein Lightning-Ziel veröffentlichen, hält die Blindierung Ihre Node-ID davon fern.

Wie es funktioniert

Ein geblindeter Pfad wird rückwärts aufgebaut, von dem Node, der erreicht werden möchte, und nicht von dem Node, der zahlt.

Der Empfänger beginnt mit einer echten Route zu sich selbst und einem zufälligen ephemeren Schlüssel, aus dem er eine Kette von Pfadschlüsseln ableitet, die so angeordnet sind, dass jeder Hop den nächsten berechnen kann, ohne dass er ihm genannt wird. Jeder Hop teilt am Ende ein ECDH-Geheimnis mit dem Empfänger, und aus diesem Geheimnis ergeben sich zwei Dinge. Das erste ist ein Blindierungsfaktor, der HMAC der Zeichenkette blinded_node_id unter dem geteilten Geheimnis, den der Empfänger in den öffentlichen Schlüssel dieses Hops einmultipliziert. Der Hop kann weiterhin für das Ergebnis signieren, weil er denselben Faktor ableitet und auf seinen eigenen privaten Schlüssel anwendet, aber niemand sonst kann diesen Schlüssel mit dem veröffentlichten Graphen abgleichen. Das zweite ist ein Verschlüsselungsschlüssel, mit dem ein kleiner Anweisungsblock für diesen Hop mit ChaCha20-Poly1305 unter einem Nonce aus lauter Nullen versiegelt wird.

Veröffentlicht wird wenig: der Einstiegspunkt im Klartext, ein erster Pfadschlüssel und dann eine Liste angepasster Schlüssel, jeder mit seinem versiegelten Block. In einem Block stehen die Felder, die dieser Hop liest: short_channel_id oder next_node_id für die Stelle, an die die Zahlung weitergeht, payment_relay für die Gebühr und das CLTV-Delta, das er anwenden muss, payment_constraints für eine maximale Ablaufzeit und eine minimale HTLC-Größe, Padding und auf dem letzten Hop eine path_id.

Drei dieser Entscheidungen sind defensiv statt funktional. Der Empfänger, nicht der Zahler, legt die Gebühr und die Zeitsperre für jeden geblindeten Hop fest, sodass ein Zwischen-Node seinen Preis nicht mitten auf der Route erhöhen und beobachten kann, welche Zahlungen fehlschlagen. Er füllt jeden Block auf eine Länge auf und kann Dummy-Hops anhängen, die er verwirft, sodass die echte Länge nicht an der Form ablesbar ist. Und die path_id enthält private Daten, zum Beispiel das Preimage, damit der Empfänger einen von ihm gebauten Pfad bestätigen kann, statt einen anzunehmen, den ein Angreifer auf jeden Node abgefeuert hat, den er verdächtigt.

BOLT 12 fügt ein letztes Stück Tarnung hinzu. Statt einer Gebühr pro geblindetem Hop trägt eine Rechnung genau ein blinded_payinfo pro Pfad: eine Grundgebühr in Millisatoshi, einen proportionalen Satz in Millionsteln, ein aggregiertes CLTV-Delta, eine minimale und maximale HTLC-Größe und einen Feature-Vektor. Der angegebene Grund ist, dass eine Angabe pro Hop trivialerweise eine Ungleichmäßigkeit verraten würde, die den Pfad unterscheidet.

Warum das wichtig ist, wenn Sie Bitcoin kaufen

Geblindete Pfade ändern, was die Mitte des Lightning-Netzwerks über Sie erfährt, und ändern nichts daran, was Ihr eigener erster Hop erfährt.

Route Blinding verbirgt die Hops nach dem Einstiegspunkt und sagt nichts über den Node, über den sich Ihre Wallet verbindet, also denjenigen, der Ihre Beträge und Ziele sieht. Phoenix, die diese Website mit 4,0 unter ihren 41 Wallet-Bewertungen einstuft, ist dabei ungewöhnlich ehrlich: Die FAQ von ACINQ selbst sagt, dass die Wallet keinen Datenschutzvorteil gegenüber einer verwahrenden Wallet mit Hosting bietet und dass ACINQ das endgültige Ziel und den Betrag von Zahlungen kennt. Ein geblindeter Pfad in einem Angebot, das Sie bezahlen, ändert daran nichts.

Die Verwahrung erübrigt die Frage vollständig. Wallet of Satoshi, die diese Website mit 2,7 bewertet und mit einem Hinweis kennzeichnet, hält die Schlüssel in ihrem verwahrenden Modus, sodass beide Enden einer Zahlung deren Aufzeichnungen sind; sie bediente US-Kunden ab dem 23. November 2023 nicht mehr und hat seitdem den verwahrenden Dienst in der gesamten Europäischen Union eingestellt. Nichts von Ihnen wird geblindet, wenn die Zahlung die Bücher des Anbieters nie verlässt.

Etwas bringen würde Ihnen die Blindierung bei der Auszahlung selbst. Strike, die am höchsten bewertete Lightning-First-Plattform dieser Website mit 4,6, erhebt keine eigene Gebühr auf Überweisungen und zahlt an ein Lightning-Ziel aus, das Sie angeben. Übergeben Sie eine BOLT-11-Rechnung, übergeben Sie Ihren Node: Die Signatur trägt eine Recovery-ID, sodass der Schlüssel des Zahlungsempfängers daraus wiederhergestellt werden kann. Ein Angebot setzt stattdessen einen Einstiegspunkt dorthin, wo der Zahler einen unterstützt.

Der Preis dafür ist die Diagnose. Hops innerhalb eines geblindeten Pfads geben Fehler ohne Zuordnungsdaten zurück, und dem Einstiegspunkt wird gesagt, eine zufällige Verzögerung einzufügen, bevor er einen Fehler weiterreicht, sodass Sondierungen nicht messen können, wie weit der Empfänger entfernt ist. Eine Auszahlung, die an ein geblindetes Ziel fehlschlägt, sagt Ihnen daher fast nichts, also testen Sie sie aus einer Wallet, die Sie selbst verwalten, bevor Sie die Plattform verantwortlich machen.

Dave übergibt Alice einen Pfad über Bob und Carol

Die Lightning-Spezifikation arbeitet die Idee des geblindeten Pfads mit vier Namen durch, was schneller zu verfolgen ist als die Algebra.

Dave möchte bezahlt werden, ohne dass Alice weiß, dass er es ist. Er wählt eine Route zu sich selbst über zwei öffentliche Nodes, zuerst Bob, dann Carol, und baut die Kette von Pfadschlüsseln so, dass alle drei ihren eigenen ableiten. Dann versiegelt er drei Blöcke: einen, der Bob anweist, an Carol weiterzuleiten, einen, der Carol anweist, an ihn weiterzuleiten, und einen für sich selbst mit Metadaten und der path_id. Schließlich leitet er die Faktoren ab, die Bob zu Bob prime, Carol zu Carol prime und Dave zu Dave prime machen.

Alice erhält drei Zeilen: Der erste Node ist Bob, hier ist der erste Pfadschlüssel, und hier ist die Folge Bob prime, Carol prime, Dave prime mit einem versiegelten Block zu jedem. Sie erreicht Bob über den gewöhnlichen öffentlichen Graphen, und das ist beabsichtigt: Die Spezifikation empfiehlt einen ungeblindeten Abschnitt bis zum Einstiegspunkt, weil er keine Unterstützung durch die Nodes dazwischen benötigt und Fehler zurückgibt, die lesbar sind. Bob entsiegelt seine Anweisung, erfährt nur, dass Carol als Nächstes kommt, und reicht den abgeleiteten Pfadschlüssel zusammen mit der Zwiebel weiter. Carol verwendet diesen Schlüssel zweimal, einmal zum Anpassen der Zwiebel, die Alice für Carol prime statt für Carol verschlüsselt hat, und einmal zum Entsiegeln ihrer eigenen Anweisung. Dave erhält sie zuletzt und prüft die path_id, bevor er annimmt.

Zählen Sie, was jeder von ihnen am Ende weiß. Alice kennt Bob. Bob weiß, dass er ein Einstiegspunkt ist und dass Carol als Nächstes kommt. Carol weiß, dass eine geblindete Zahlung sie durchlaufen hat, und kann nicht erkennen, ob Dave der Empfänger oder ein weiterer Weiterleitungsknoten ist. Dave weiß alles, weil er der Einzige ist, der den Pfad gebaut hat.

Geblindeter Pfad vs. Route Hint

Ein geblindeter Pfad und ein Route Hint beantworten dieselbe Frage, wie ein Node zu erreichen ist, den der öffentliche Graph nicht sehen kann, und geben dabei gegensätzliche Mengen preis.

Ein Route Hint ist das Feld r einer BOLT-11-Rechnung, und es ist Klartext. Jeder Eintrag trägt einen öffentlichen Schlüssel mit 264 Bits, eine kurze Kanal-ID mit 64 Bits, eine Grundgebühr, einen proportionalen Satz und ein CLTV-Delta, alles im Klartext, sodass jeder, der die Rechnung hat, weiß, an welchem gut vernetzten Node Sie hängen. Ein geblindeter Pfad nennt den Einstiegspunkt und wird danach dunkel: Jeder spätere Hop ist ein angepasster Schlüssel, der zu nichts im Graphen passt, und die Gebühren kommen aggregiert statt aufgeschlüsselt an. Geblindete Pfade übernehmen zudem eine Aufgabe, die Route Hints nie hatten, und treten an die Stelle der Felder payment_secret und payment_metadata einer BOLT-11-Rechnung.

Geblindeter Pfad vs. Onion-Routing

Onion-Routing verbirgt den Zahler vor den Hops; ein geblindeter Pfad verbirgt den Zahlungsempfänger vor dem Zahler.

Beim einfachen Onion-Routing wählt der Absender jeden Hop aus dem öffentlichen Graphen und wickelt eine Verschlüsselungsschicht pro Hop darum, sodass kein weiterleitender Node erfährt, wer zahlt oder an welcher Stelle der Route er sitzt. Der Absender kennt weiterhin die ganze Route einschließlich der echten Node-ID des Ziels, was zum Bezahlen in einem Shop in Ordnung und zum Veröffentlichen eines wiederverwendbaren Ziels nutzlos ist. Route Blinding liefert die fehlende Hälfte, ohne etwas zu ersetzen: Eine Zahlung über einen geblindeten Pfad ist weiterhin eine Zwiebel, und die Blindierung ist eine Schlüsselanpassung, die obenauf liegt. Beides ist so weit trennbar, dass ein Empfänger, der den Datenschutz nicht möchte, einen Pfad mit einem einzigen Hop bauen kann, der nur ihn selbst enthält, und seine Node-ID trotzdem preisgibt.