Lightning Address

Anna möchte Spenden für ihren Podcast empfangen. Statt jedem Zuhörer eine neue lange Rechnung zu schicken, veröffentlicht sie eine Lightning Address. Die Beispieladresse anna@example.com lässt sich leicht merken: Vor dem @ steht der Empfänger beim Dienst, dahinter die Domain, die der Wallet antwortet. Die Ähnlichkeit mit E-Mail ist beabsichtigt, das Geld wird aber nicht per E-Mail verschickt. Eine vorhandene E-Mail-Adresse ist nicht automatisch eine Lightning Address. Auch beweist der Name allein nicht, wem er gehört. Prüfen Sie ihn deshalb beim Urheber, den Sie unterstützen möchten. [1] [6]

Ein Zuhörer gibt den Namen in einer kompatiblen Wallet ein. Sie fragt beim Dienst eine Beschreibung und den erlaubten Betragsbereich ab. Sobald der Nutzer Domain, Beschreibung und gewählten Betrag geprüft hat, fordert sie eine konkrete BOLT 11-Rechnung an und kontrolliert deren Betrag vor der Zahlung. Eine abgerufene Rechnung ist noch keine Zahlung. Dieses Verfahren heißt LNURL-pay. Der Dienst liefert einen callback, also die Adresse zum Anfordern der Rechnung, metadata zur Beschreibung sowie die Grenzen minSendable und maxSendable. amount wird in msat angegeben, Tausendsteln eines satoshi: 1000 msat = 1 sat. Die Rechnung steht im Feld pr. [2] [3]

Anna kann einen Dienst nutzen, der ihre Wallet verwaltet, oder den Namen an ihren eigenen Lightning-Knoten anbinden, die Software für ihre Zahlungen. An der Adresse erkennt man den Unterschied nicht. Ein Web-endpoint, an dem der Server der Wallet antwortet, kann über einen Bridge-Server eine Rechnung vom Knoten anfordern. Dieser Vermittler ist nicht zwangsläufig Verwahrer; entscheidend sind Aufbau und Berechtigungen. Die Kontrolle über Serverantworten bleibt wichtig: Wer sie austauschen kann, kann dem Zahler eine andere Rechnung vorlegen. Eine eigene Domain allein garantiert keine self-custody, also die eigene Kontrolle über die Schlüssel. [3] [4]

Eine Wallet kann an eine Lightning Address zahlen, ohne ihrem Nutzer eine eigene Empfangsadresse zu geben. Zum Empfangen braucht es außerdem einen verfügbaren Webdienst, die Rechnungserstellung und die Möglichkeit, die Zahlung im Lightning Network anzunehmen. Zahlungen laufen durch Kanäle: Verbindungen zwischen Teilnehmern, in denen sich die Aufteilung des Guthabens auf beide Seiten ändert. Dazu gehört Inbound Liquidity: Guthaben auf der Gegenseite von Kanälen, das bei einer Zahlung zum Empfänger wechseln kann. Ein einprägsamer Name schafft diese Liquidität nicht. Wird die Adresse geladen, scheitert aber die Zahlung, muss der Name nicht die Ursache sein. Webantwort, abgerufene Rechnung und bestätigter Geldeingang sind verschiedene Schritte. [3] [5]

Mit einer eigenen Domain können Sie den zuständigen Zahlungsserver ändern und den Namen für Zuhörer behalten. Die BTCPay-Dokumentation zeigt eine Weiterleitung des endpoint per HTTP 301: Die Webanfrage geht an eine andere Stelle, ohne dass Bitcoins übertragen werden. Bei einem Namen auf einer fremden Domain fehlt Ihnen diese Kontrolle möglicherweise. Eine Seed Phrase, die Wiederherstellungswörter der Wallet, garantiert für sich allein nicht, dass sich der Zugang zum Dienstkonto wiederherstellen lässt. Sie sichert auch nicht die Domainverwaltung oder die Einstellungen von DNS, dem System zur Zuordnung des Domainziels. Prüfen Sie nach einem Wechsel die richtige Rechnung und eine tatsächlich empfangene Testzahlung, nicht nur das Laden der Adresse. Alte Kontakte erfahren einen neuen Namen nicht automatisch. [5] [3]

LUD-16 beschreibt, wie aus dem Namen eine GET-Webanfrage wird, also eine Anfrage nach Daten. Die Wallet ruft bei der Domain den Pfad /.well-known/lnurlp/username auf und ersetzt username durch den Nutzernamen. Im gewöhnlichen Web verwendet sie HTTPS, bei einer onion-Domain HTTP. Die Antwort payRequest führt zum Verfahren nach LUD-06. HTTPS schützt die Verbindung vor Manipulation unterwegs, beweist aber nicht die Vertrauenswürdigkeit des Dienstes selbst. Dieser verarbeitet die Anfragen und kennt den Rechnungsempfänger. Der lesbare Name allein schafft daher keine Anonymität. [1] [2]

LUD-16 erlaubt im Nutzernamen Kleinbuchstaben a-z, Ziffern 0-9 und -_.; normale E-Mail-Adressen erlauben mehr Zeichen. Die optionale Kurzform @domain bezeichnet den Standardempfänger _@domain am Pfad /.well-known/lnurlp/_. Wallet oder Dienst müssen sie nicht unterstützen. Auch +tag ist kein überall verfügbarer Zusatz. Ein unterstützender Dienst kann damit den Zweck einer Spende unterscheiden und ihn als text/tag angeben. Das ist weder ein neuer privater Schlüssel noch eine Datenschutzgarantie. Im Alltag übernehmen Sie am besten genau den veröffentlichten Namen des Empfängers. [1]

Metadaten sind Begleitangaben, die Wallet und Dienst im strukturierten Format JSON austauschen. Bei LNURL-pay enthalten sie text/plain, eine kurze Zahlungsbeschreibung. LUD-16 ergänzt text/identifier für die Zuordnung zum Namen oder text/email, wenn der Name einer tatsächlichen E-Mail-Adresse entspricht. Das hilft der Wallet, den Bezug der Zahlung anzuzeigen. Es bleiben jedoch Angaben des Dienstes und keine unabhängige Prüfung von Annas bürgerlicher Identität. Die ursprüngliche Adresse, die Domain und den Betrag zu prüfen, gehört deshalb weiterhin zum sorgfältigen Bezahlen. [1] [2]