Glossar / Lightning und Layer 2
Keysend
- Was ist Keysend?
- Keysend sendet eine Lightning-Zahlung ohne Rechnung: Der Zahlende erzeugt die 32 Byte große Preimage, hasht sie zum Payment Hash und schickt das Geheimnis in der Zwiebel mit.
Keysend kehrt den normalen Lightning-Ablauf um, bei dem der Empfänger ein Geheimnis wählt und dessen Hash in einer Rechnung veröffentlicht. Das Geheimnis des Senders reist im benutzerdefinierten TLV-Datensatz 5482373484, einer geraden Zahl, die BOLT 1 einen Node, der Keysend nicht kennt, zurückweisen lässt statt sie zu ignorieren. Sie können einen reinen Node-Pubkey ohne Rückfrage bezahlen, und Sie verzichten auf den kryptografischen Beleg, den eine Rechnung hinterlassen hätte.
So funktioniert es
Keysend beruht auf der strengeren Hälfte einer Regel von BOLT 1: Ein Leser verwirft einen unbekannten TLV-Datensatz mit ungeradem Typ und macht weiter, bei einem unbekannten geraden Typ muss er jedoch den gesamten Stream scheitern lassen.
Typkennungen unterhalb von 2^16 sind für die BOLTs reserviert, und alles ab 2^16 steht für benutzerdefinierte Datensätze frei, und BOLT 1 sagt, eine ungerade Zahl zu wählen, wenn gewöhnliche Nodes die Daten ignorieren sollen, eine gerade, wenn sie sie zurückweisen sollen. bLIP-3 hält fest, dass 5482373484 von der ursprünglichen lnd-Implementierung zufällig gewählt wurde, und die Zahl endet auf eine Vier, also landete Keysend auf der zurückweisenden Seite. Deshalb braucht es ein Feature-Bit: bereitwillige Nodes werben mit 54/55, benannt keysend, das von var_onion_optin abhängt, und bLIP-3 sagt, Sender sollten danach Ausschau halten, statt blind zu senden und das Scheitern zu beobachten.
Die Aufgabe des Senders, dargelegt in bLIP-3, ist kurz. Erzeugen Sie einen kryptografisch sicheren Zufallswert von 32 Byte, legen Sie ihn in diesen Datensatz und setzen Sie den payment_hash in update_add_htlc auf dessen SHA-256. Verwenden Sie niemals eine Preimage erneut, und niemals eine aus einer bereits bezahlten Rechnung. Das Paket wird bei jedem Hop verschleiert, sodass ein Hop nur die Adresse des nächsten zurückgewinnt und niemand dazwischen den Datensatz sieht. Der letzte Node hasht den gefundenen Wert, prüft ihn gegen den Hash, den er annehmen sollte, und wickelt die Zahlung ab.
Die Ablehnung erfolgt bewusst still. BOLT 4 hat eine wörtliche Antwort für eine Nutzlast, die ein Node nicht verstanden hat, PERM|22 invalid_onion_payload, die sogar den beanstandeten TLV-Typ nennen kann. bLIP-3 bittet Empfänger, stattdessen PERM|15 incorrect_or_unknown_payment_details zurückzugeben, sodass ein abgelehnter Keysend nicht von einem Payment Hash zu unterscheiden ist, den der Node nie ausgegeben hat.
Wo Sie es sehen
Keysend ist das Innenleben hinter Podcast-Boosts.
bLIP-10 definiert einen zweiten Datensatz, Typ 7629169, ursprünglich von Breez gewählt, der ein flaches JSON-Objekt an die Keysend-Zahlung anhängt: den Podcast-Titel, die Episode, ts für die Wiedergabeposition in Sekunden, action auf boost oder stream gesetzt und ein optionales message, das ein Boostagram ausmacht. Beim Streaming pro Minute wird seconds_back auf 60 gesetzt. Dieser Datensatz ist ungerade, weshalb bLIP-10 auf Abwärtskompatibilität verzichtet: Ein Host, der die Metadaten ignoriert, behält die Sats trotzdem. Er existiert, weil ein Keysend für sich genommen dem Empfänger nichts sagt, sodass eine App die Sendung selbst benennen muss.
Dieselbe Lücke hält Keysend aus dem Kaufweg heraus. Eine Auszahlung von einer Börse übergibt Ihnen entweder eine Rechnung oder verlangt eine von Ihnen, weil die Plattform die Zahlung an Ihr Konto binden muss, und das Wort kommt in keinem der 63 Börsen-Datensätze oder 41 Wallet-Bewertungen auf dieser Website vor. bLIP-3 benennt den Tausch ehrlich: Es erwartet, dass Keysend einem besser gestalteten spontanen Zahlungsweg weicht, nennt Offers und AMP und listet auf, was Sie derweil aufgeben, den Zahlungsnachweis und jedes Mitspracherecht des Zahlungsempfängers beim endgültigen CLTV-Ablauf.
Keysend vs. Lightning-Adresse
Keysend und eine Lightning-Adresse lassen Sie beide jemanden bezahlen, der Ihnen nie eine Rechnung ausgehändigt hat, und nur einer von beiden überspringt die Rechnung wirklich. Die Eingabe von user@example.com schickt Ihre Wallet auf eine HTTPS-Abfrage, die eine frische BOLT11-Rechnung zurückgibt, sodass der Empfänger die Preimage weiterhin gewählt hat und Sie am Ende einen Beleg mit seiner Signatur halten. Keysend braucht keine Webanfrage und keinen Server, nur den 33 Byte großen Node-Pubkey und eine Route dorthin, und es lässt Ihnen danach nichts, womit Sie etwas beweisen könnten, weil das Geheimnis von Anfang an Ihres war. Wenn Sie jemals belegen müssen, dass Sie gezahlt haben, nehmen Sie die Rechnung.