Lightning Address ist eine Kennung benutzer@domain, über die eine Wallet LNURL-pay-Parameter und anschließend eine konkrete BOLT 11-Rechnung erhält. Geld wird nicht per E-Mail versendet; der Name selbst enthält keine Bitcoins.
LUD-16 verwendet Benutzername und Domain, beschränkt den Namen aber auf kleine a-z, Ziffern 0-9 und -_.; Plus ist nur bei Tag-Unterstützung des Dienstes möglich. Die gewöhnliche E-Mail-Syntax ist umfassender. Ein Postfach garantiert daher keine Lightning Address, und derselbe Name bestätigt nicht die Person des Empfängers. [Lightning Address — LUD-16] [Lightning Address — Project overview]
Die Wallet ruft per GET den Pfad /.well-known/lnurlp/username auf der Domain ab, über HTTPS beziehungsweise HTTP bei einem Onion-Dienst. Die Antwort ist ein payRequest nach LUD-06. Entscheidend sind die tatsächliche Domain und ihr Dienst; der Teil vor dem At-Zeichen ist kein öffentlicher Knotenschlüssel. [Lightning Address — LUD-16]
Die Antwort liefert callback, metadata und die Grenzen minSendable/maxSendable. Der Zahler wählt amount in msat; 1000 msat entsprechen einem Satoshi. Der Callback gibt eine Rechnung in pr zurück, und die Wallet prüft vor dem Bezahlen die Übereinstimmung des Betrags. Adressabfrage und Rechnungsempfang sind noch keine Abwicklung. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]
Die neuere LUD-16 erlaubt optional @domain als Kurzform von _@domain mit einem Pfad, der auf /_ endet. Weder Dienst noch Wallet müssen dies unterstützen. Unterstützte +tag werden im Pfad übermittelt; der Dienst kann sie als Metadaten text/tag verwenden. Ein Tag ist weder ein neuer Bitcoin-Schlüssel noch ein automatischer Schutz der Privatsphäre. [Lightning Address — LUD-16]
LUD-16 verlangt text/identifier oder text/email in metadata; text/email gehört zu einer tatsächlichen E-Mail-Adresse. Auch text/plain aus LNURL-pay bleibt erforderlich. Vergleichen Sie angezeigten Namen und Beschreibung mit Domain und beabsichtigtem Empfänger. Die Aussage eines Dienstes ist keine unabhängige Überprüfung einer menschlichen Identität. [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]
Der Dienst kann Rechnungen seiner Wallet ausstellen oder einen mit einem Knoten verbundenen Bridge-Server verwenden. Das Format allein bedeutet daher weder Verwahrung noch Selbstverwahrung. Eine Bridge benötigt Berechtigungen für ihre Funktion, nicht automatisch uneingeschränkte Wallet-Kontrolle. Wer den Endpoint kontrolliert, kann beeinflussen, welche Rechnung der Zahler erhält. [Lightning Address — Implementation guide] [Lightning Address — Bridge server]
Eine Wallet kann an eine Lightning Address zahlen, ohne Nutzern eine eigene Adresse anzubieten. Empfang erfordert einen funktionierenden Webdienst, Rechnungserstellung und die Fähigkeit, die Zahlung anzunehmen. Der lesbare Name erzeugt selbst keine eingehende Liquidität. Wiederholte Abfragen können dem Anbieter Empfänger und Zeitabläufe offenlegen. [Lightning Address — Implementation guide]
Eine eigene Domain erlaubt die Weiterleitung des Endpoints an einen anderen Server; BTCPay beschreibt etwa HTTP 301. Bei einer fremden Domain hängt der Erhalt des Namens vom Anbieter ab. Ein Seed stellt weder DNS-Kontrolle noch Zertifikat oder Kontozuordnung wieder her. Prüfen Sie nach einem Dienstwechsel erneut Abfrage, Zielrechnung und Empfang; nehmen Sie keine automatische Aktualisierung alter Kontakte an. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit LNURL, BOLT 11, Lightning Network, Inbound Liquidity, Selbstverwahrung, Bitcoin-Privatsphäre. Auf diesen Eintrag verweisen außerdem LNURL, Inbound Liquidity, Strike, Satsback.