Lightning Address उपयोगकर्ता@डोमेन रूप का पहचानकर्ता है, जिससे वॉलेट LNURL-pay पैरामीटर और फिर एक निश्चित BOLT 11 चालान प्राप्त करता है। पैसे ईमेल से नहीं भेजे जाते और नाम स्वयं कोई बिटकॉइन नहीं रखता।
LUD-16 username और डोमेन का उपयोग करता है, लेकिन नाम को छोटे a-z, अंक 0-9 और -_. तक सीमित करता है; प्लस चिह्न तभी संभव है जब सेवा टैग का समर्थन करे। सामान्य ईमेल की वाक्यरचना अधिक व्यापक है। इसलिए मेलबॉक्स होना Lightning Address की गारंटी नहीं देता और समान नाम प्राप्तकर्ता की व्यक्तिगत पहचान प्रमाणित नहीं करता। [Lightning Address — LUD-16] [Lightning Address — Project overview]
वॉलेट डोमेन के /.well-known/lnurlp/username पथ को GET से प्राप्त करता है, HTTPS पर या onion सेवा के लिए HTTP पर। उत्तर LUD-06 के अनुसार payRequest होता है। वास्तविक डोमेन और उसकी सेवा महत्त्वपूर्ण हैं; @ से पहले का भाग नोड की सार्वजनिक कुंजी नहीं है। [Lightning Address — LUD-16]
उत्तर में callback, metadata और minSendable/maxSendable सीमाएँ होती हैं। भुगतानकर्ता msat में amount चुनता है; 1000 msat एक satoshi है। callback pr में चालान लौटाता है और वॉलेट भुगतान से पहले राशि का मिलान जाँचता है। पता खोजना या चालान मिलना निपटान नहीं है। [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]
नया LUD-16 वैकल्पिक रूप से @डोमेन को _@डोमेन का संक्षिप्त रूप मानता है, जिसका पथ /_ पर समाप्त होता है। सेवा या वॉलेट के लिए इसका समर्थन अनिवार्य नहीं है। समर्थित +tag पथ में भेजा जाता है; सेवा उसे text/tag मेटाडेटा के रूप में उपयोग कर सकती है। टैग न नई Bitcoin कुंजी है, न स्वतः गोपनीयता सुरक्षा। [Lightning Address — LUD-16]
LUD-16 metadata में text/identifier या text/email अनिवार्य करता है; text/email वास्तविक ईमेल पते के लिए है। LNURL-pay का text/plain भी अनिवार्य बना रहता है। दिखाए गए नाम और विवरण की तुलना डोमेन तथा इच्छित प्राप्तकर्ता से करें। सेवा का दावा किसी व्यक्ति की पहचान का स्वतंत्र सत्यापन नहीं है। [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]
सेवा अपने वॉलेट के चालान जारी कर सकती है या नोड से जुड़े ब्रिज सर्वर का उपयोग कर सकती है। इसलिए केवल प्रारूप से अभिरक्षा या स्व-अभिरक्षा तय नहीं होती। ब्रिज को अपने कार्य के लिए अनुमतियाँ चाहिए, स्वतः पूरे वॉलेट का असीमित नियंत्रण नहीं। endpoint नियंत्रित करने वाला पक्ष भुगतानकर्ता को मिलने वाले चालान को प्रभावित कर सकता है। [Lightning Address — Implementation guide] [Lightning Address — Bridge server]
वॉलेट उपयोगकर्ताओं को अपना पता दिए बिना भी Lightning Address पर भुगतान कर सकता है। प्राप्ति के लिए चालू वेब सेवा, चालान निर्माण और भुगतान स्वीकार करने की क्षमता चाहिए। पढ़ने योग्य नाम स्वयं आने वाली तरलता नहीं बनाता। बार-बार की खोज प्रदाता को प्राप्तकर्ता और समय की जानकारी दे सकती है। [Lightning Address — Implementation guide]
अपना डोमेन endpoint को दूसरे सर्वर पर पुनर्निर्देशित करने देता है; उदाहरण के लिए BTCPay HTTP 301 का वर्णन करता है। दूसरे के डोमेन पर नाम बनाए रखना प्रदाता पर निर्भर है। सीड DNS नियंत्रण, प्रमाणपत्र या खाते का मिलान बहाल नहीं करता। सेवा बदलने के बाद खोज, गंतव्य चालान और प्राप्ति दोबारा जाँचें; पुराने संपर्क स्वतः अद्यतन हो गए हैं, ऐसा न मानें। [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें LNURL, BOLT 11, Lightning Network, Inbound Liquidity, स्व-अभिरक्षा, Bitcoin में गोपनीयता. इस प्रविष्टि का उल्लेख यहाँ भी है LNURL, Inbound Liquidity, Confirmo, Strike.