Lightning Address

Анна хоче отримувати внески за свій подкаст. Замість надсилати кожному слухачеві новий довгий рахунок вона публікує Lightning Address. Умовну anna@example.com легко запам’ятати: частина перед равликом позначає одержувача в сервісі, після нього — домен, що відповідає гаманцю. Схожість з електронною поштою навмисна, але гроші не надсилаються поштою. Наявна електронна адреса не стає автоматично Lightning Address, а саме ім’я не доводить, кому воно належить. Перевірте його в автора, якого хочете підтримати. [1] [6]

Слухач вводить ім’я в сумісному гаманці. Гаманець отримує від сервісу опис платежу й дозволений діапазон сум. Коли користувач перевірить домен, опис та обрану суму, гаманець запитає конкретний рахунок BOLT 11 і перевірить його суму перед оплатою. Отриманий рахунок — ще не платіж. Цей процес називається LNURL-pay. Сервіс повертає callback, адресу для запиту рахунку, metadata з описом і межі minSendable та maxSendable. amount передається в msat, тисячних частках satoshi: 1000 msat = 1 sat. Рахунок надходить у полі pr. [2] [3]

Анна може користуватися сервісом, що керує її гаманцем, або прив’язати ім’я до власного вузла Lightning — програми, яка обробляє її платежі. Вигляд адреси не видає різниці. Веб-endpoint, місце відповіді сервера гаманцю, може через сервер-посередник запитати рахунок у її вузла. Посередник не обов’язково зберігає кошти: це залежить від налаштувань і дозволів. Проте контроль відповідей важливий: той, хто може їх підмінити, здатен показати платнику інший рахунок. Власний домен сам собою не гарантує self-custody, тобто контролю власних ключів. [3] [4]

Гаманець може платити на Lightning Address, не надаючи користувачу власної адреси для приймання. Для приймання також потрібні доступний вебсервіс, створення рахунку й можливість отримати платіж у Lightning Network. Платежі проходять через канали — з’єднання між учасниками, у яких змінюється розподіл коштів між сторонами. Зокрема, потрібна Inbound Liquidity: кошти на іншому боці каналів, які під час платежу можуть перейти одержувачу. Зручне ім’я не створює цієї ліквідності. Якщо адреса завантажується, а платіж не проходить, причина не обов’язково в імені. Розрізняйте відповідь сайту, отриманий рахунок і підтверджене надходження грошей. [3] [5]

На власному домені можна змінити сервер платежів, зберігши знайоме слухачам ім’я. Документація BTCPay показує перенаправлення endpoint через HTTP 301: вебзапит іде в інше місце, але монети не переміщуються. Для імені на чужому домені такого контролю може не бути. Seed Phrase, слова відновлення гаманця, сама по собі не гарантує відновлення доступу до облікового запису сервісу. Вона також не зберігає доступ до керування доменом чи налаштування DNS — системи, яка визначає, куди веде домен. Після зміни перевірте правильність рахунку та фактичне отримання пробного платежу, а не лише відкриття адреси. Старі контакти не дізнаються нове ім’я автоматично. [5] [3]

LUD-16 описує перетворення імені на вебзапит GET, тобто запит даних. Гаманець звертається до домену за шляхом /.well-known/lnurlp/username, замінюючи username іменем користувача. У звичайному вебі він використовує HTTPS, для домену onion — HTTP. Відповідь payRequest продовжує процедуру LUD-06. HTTPS захищає передавання від підміни дорогою, але не доводить чесність самого сервісу. Сервіс обробляє запити та знає, для якого одержувача створює рахунок. Отже, читабельне ім’я саме собою не додає анонімності. [1] [2]

LUD-16 дозволяє в імені малі літери a-z, цифри 0-9 та -_.; звичайна електронна пошта допускає більше символів. Необов’язкова скорочена форма @domain позначає стандартного одержувача _@domain за шляхом /.well-known/lnurlp/_, але гаманець чи сервіс можуть її не підтримувати. Доповнення +tag також не універсальне. Сумісний сервіс може розрізняти призначення внеску й указати його як text/tag. Це не новий приватний ключ і не гарантія приватності. Для повсякденного використання копіюйте точне ім’я, яке опублікував одержувач. [1]

Метадані — це супровідна інформація, яку гаманець і сервіс передають у структурованому форматі JSON. У LNURL-pay вона містить text/plain, короткий опис платежу. LUD-16 додає text/identifier для прив’язки до імені або text/email, якщо ім’я відповідає справжній електронній адресі. Так гаманець може показати, чого стосується платіж. Однак ці відомості надає сервіс; це не незалежна перевірка особи Анни. Тому перевірка початково отриманої адреси, домену й суми залишається частиною обачної оплати. [1] [2]