LNURL

Stell dir vor, Anna scannt erst einen Code, um einen Autor zu unterstützen, dann einen zum Einlösen eines Gutscheins und schließlich einen zur Anmeldung auf einer Website. Sie bedient ihr Telefon gleich, gibt aber jedes Mal etwas anderes frei. LNURL unterscheidet diese Aufgaben: payRequest steht für Bezahlen, withdrawRequest für Auszahlen und login für Anmelden. Die einzelnen Verfahren sind in LUD-Dokumenten beschrieben. Es sind freiwillige Vereinbarungen zwischen Anwendungen, keine Änderungen der Bitcoin-Regeln. Unterstützt eine Wallet ein Verfahren, muss sie die anderen noch lange nicht beherrschen. [1] [7]

Bei payRequest liefert der Dienst eine Beschreibung und einen zulässigen Betragsbereich. Anna prüft die Domain, also die Webadresse des Dienstes, liest die Beschreibung und wählt ihren Beitrag. Nach ihrer Zustimmung fordert die Wallet eine konkrete BOLT-11-Lightning-Rechnung an und prüft vor dem Bezahlen, ob deren Betrag stimmt. Technisch nutzt sie die Adresse callback, die Grenzen minSendable und maxSendable sowie die Beschreibung metadata. Der gewählte Betrag heißt amount, die zurückgelieferte Rechnung steht in pr. Beträge sind in msat angegeben, Tausendsteln eines Satoshi: 1000 msat = 1 sat. Derselbe öffentliche QR-Code kann weiteren Menschen dienen; sein Einscannen bestätigt aber noch keine Zahlung. [3]

Bei withdrawRequest läuft es andersherum. Anna will ein Guthaben vom Dienst abheben, nicht an ihn zahlen. Ihre Wallet erstellt daher eine Empfangsrechnung, die der Dienst bezahlen soll. Er liefert die Kennung k1, die Adresse callback und die Grenzen minWithdrawable und maxWithdrawable in msat; nach der Zustimmung übermittelt die Wallet ihre Rechnung als pr. OK bedeutet, dass der Dienst die Anfrage angenommen hat, nicht dass Anna das Geld schon erhalten hat. Die Wallet wartet weiter auf den Zahlungseingang. Ein Auszahlungscode kann wie ein Gutschein für seinen jeweiligen Besitzer wirken. Veröffentliche ihn deshalb nicht wie eine gewöhnliche Empfangsadresse. [4]

Auf einer anderen Website wählt Anna LNURL-auth. Die Wallet zeigt die Domain und den Zweck der Anfrage mit dem tag login. Mit Annas Zustimmung signiert sie eine einmalige Prüfanfrage k1 mit dem domainspezifischen privaten Schlüssel linkingPrivKey. Sie sendet dem Dienst die Signatur und den zugehörigen öffentlichen linkingKey, mit dem sich die Signatur prüfen lässt. Den privaten Schlüssel gibt sie nicht weiter. Der Dienst kann den wiederkehrenden Schlüsselinhaber erkennen, erfährt dadurch allein aber nicht dessen tatsächliche Identität. Die Wallet übermittelt weder ihren Seed, den geheimen Ausgangswert für die Ableitung von Schlüsseln, noch die Seed Phrase, also die Wiederherstellungswörter. Technisch kommt eine ECDSA-Signatur auf secp256k1 zum Einsatz. Das Feld action kann Registrierung, Anmeldung, Kontoverknüpfung oder eine andere Freigabe bedeuten. Deshalb sollte man die ganze Bestätigung lesen. Das Signieren dieser Prüfanfrage ist für sich genommen keine Bitcoin-Zahlung. [5]

Eine Anfrage, die Antwort des Dienstes und der tatsächliche Geldfluss sind unterschiedliche Schritte. Verliert Anna die Verbindung, prüft sie zuerst die ursprüngliche Zahlung in ihrer Wallet. Ein weiterer Versuch mit einer neuen Rechnung kann zu einer weiteren Zahlung führen. Das optionale LUD-21 liefert eine verify-Adresse zur Prüfung einer bestimmten Rechnung: settled true meldet die Begleichung, settled false eine noch nicht beglichene Rechnung. OK allein genügt nicht. Die Antwort kann ein preimage enthalten, den ursprünglichen geheimen Wert zu dieser Zahlung. Die Wallet berechnet daraus einen Hash, also einen Prüfwert, und vergleicht ihn mit dem Zahlungshash der richtigen Rechnung. Ein beliebiger geheimer Wert genügt nicht: Er muss zu genau dieser Zahlung passen. Eine Ergebnisprüfung schafft weder einen erreichbaren Dienst noch eingehende Liquidität, also Kapazität für den Zahlungsweg in die empfangende Wallet. [6] [3] [4]

HTTPS schützt die Übertragung zwischen Wallet und Dienst, nicht vor dem Dienst selbst. Dieser kann Anfragen, deren Zeitpunkt und wiederholte Nutzung beobachten. Bei der Anmeldung zählt zudem der vollständige Domainname: Eine andere Subdomain kann einen anderen linkingKey ergeben, sodass die Website einen anderen Nutzer sieht. Auch eine neue Wallet stellt dieselbe Anmeldung nicht unbedingt wieder her, weil Anwendungen Schlüssel unterschiedlich ableiten. Prüfe daher vor einer wichtigen Umstellung die Wiederherstellung des jeweiligen Kontozugangs. LNURL bestimmt nicht, wer die Bitcoin-Schlüssel hält; das hängt von Wallet und Dienst ab. [2] [5]

Das grundlegende LUD-01 stellt eine HTTPS- oder onion-URL in Bech32 dar. Das ist eine Kodierung, keine Verschlüsselung der Adresse und keine BOLT-11-Rechnung. Die Wallet liest den tag direkt aus dem Link oder ruft Daten per GET ab und entnimmt die gewünschte Operation einer JSON-Antwort. JSON versieht Daten mit Namen und Struktur, damit Anwendungen sie lesen können. Ein QR-Bild belegt deshalb nicht die Identität des Empfängers. Entscheidend sind der Linkinhalt und die anschließend gezeigte Domain, Handlung und Bedingungen. [2]

Beim Bezahlen ist metadata eine Zeichenkette, die ein JSON-Array enthält. Darin muss eine Beschreibung vom Typ text/plain vorkommen; weitere Typen sind optional. Die Wallet soll die Beschreibung mit Domain und Betrag anzeigen, damit klar ist, was freigegeben wird. Das grundlegende LNURL interpretiert den JSON-Antwortinhalt, nicht allein den HTTP-Statuscode. Ein erreichbarer Server bedeutet daher nicht zwingend eine erfolgreiche Anfrage: Die Antwort kann ERROR enthalten. Ebenso ist eine in pr empfangene Rechnung noch nicht bezahlt. Eine Anwendung sollte diese verschiedenen Informationen nicht zu einem einzigen grünen Häkchen zusammenziehen. [2] [3]