Lightning Address — читаемое имя вида пользователь@домен, по которому совместимый кошелёк получает запрос на оплату в Lightning Network. Lightning используют для быстрых платежей в биткоинах; счёт в этой сети — запрос на оплату с данными, нужными кошельку для платежа. Имя можно использовать повторно, но для отдельного платежа кошелёк запрашивает конкретный счёт BOLT 11. Это не почтовый ящик и не биткоин-адрес для платежа непосредственно в блокчейне.
Анна хочет получать поддержку своего подкаста. Вместо нового длинного счёта для каждого слушателя она публикует 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]
Для полной картины прочитайте эту статью вместе с LNURL, BOLT 11, Lightning Network, Inbound Liquidity, Самостоятельное хранение, Приватность в Bitcoin. На эту статью также ссылаются LNURL, Inbound Liquidity, Confirmo, Strike.