Lightning Address

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]