Lightning Address — это идентификатор пользователь@домен, по которому кошелёк получает параметры LNURL-pay, а затем конкретный счёт BOLT 11. Деньги не отправляются по электронной почте, а само имя не хранит биткоины.
LUD-16 использует username и домен, но ограничивает имя строчными a-z, цифрами 0-9 и символами -_.; плюс допустим лишь при поддержке тегов сервисом. Обычный синтаксис почты шире. Поэтому ящик не гарантирует Lightning Address, а одинаковое имя не удостоверяет личность получателя. [Lightning Address — LUD-16] [Lightning Address — Project overview]
Кошелёк запрашивает через GET путь /.well-known/lnurlp/username на домене по HTTPS либо HTTP для onion-сервиса. Ответ представляет собой payRequest по LUD-06. Важны фактический домен и его сервис; часть перед собачкой не является открытым ключом узла. [Lightning Address — LUD-16]
Ответ содержит callback, metadata и пределы minSendable/maxSendable. Плательщик выбирает amount в msat; 1000 msat равны одному сатоши. Callback возвращает счёт в pr, и кошелёк проверяет совпадение суммы перед оплатой. Поиск адреса или получение счёта ещё не означают расчёт. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]
Более новая LUD-16 допускает необязательную запись @домен как сокращение _@домен с путём, заканчивающимся на /_. Ни сервис, ни кошелёк не обязаны её поддерживать. Поддерживаемый +tag передаётся в пути; сервис может использовать его как metadata text/tag. Тег не является новым ключом Bitcoin или автоматической защитой приватности. [Lightning Address — LUD-16]
LUD-16 требует text/identifier или text/email в metadata; text/email предназначен для настоящего адреса электронной почты. Также остаётся обязательным text/plain из LNURL-pay. Сверяйте показанные имя и описание с доменом и предполагаемым получателем. Утверждение сервиса не является независимой проверкой личности человека. [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. В чужом домене сохранение имени зависит от провайдера. Seed не восстанавливает контроль DNS, сертификаты или привязки аккаунтов. После смены сервиса снова проверьте поиск, целевой счёт и получение; не считайте старые контакты автоматически обновлёнными. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]
Для полной картины прочитайте эту статью вместе с LNURL, BOLT 11, Lightning Network, Inbound Liquidity, Самостоятельное хранение, Приватность в Bitcoin. На эту статью также ссылаются LNURL, Inbound Liquidity, Confirmo, Strike.