LNURL — це родина процедур, за якими Lightning-гаманець і вебсервіс обмінюються даними для певного завдання. Lightning використовують для швидких платежів у біткоїнах; рахунок у цій мережі — це запит на оплату з даними, потрібними гаманцю для платежу. З посилання гаманець дізнається, чи потрібно підготувати платіж, отримати виведені кошти або підтвердити вхід. Саме посилання ще не є рахунком чи доказом надходження грошей.
Уявіть Анну, яка спершу сканує код, щоб підтримати автора, потім — щоб використати ваучер, а далі — щоб увійти на сайт. Телефоном вона користується однаково, але щоразу погоджується на іншу дію. LNURL розрізняє ці завдання: payRequest означає оплату, withdrawRequest — виведення коштів, login — вхід. Окремі процедури описані в документах LUD. Це необов’язкові домовленості між застосунками, а не зміна правил Bitcoin. Підтримка однієї процедури не означає, що гаманець підтримує всі інші. [1] [7]
Для payRequest сервіс повертає опис і допустимий діапазон сум. Анна перевіряє домен — вебадресу сервісу, читає опис і вибирає внесок. Після погодження умов гаманець запитує конкретний Lightning-рахунок BOLT 11 та перед оплатою звіряє його суму з вибраною. Для цього використовуються адреса callback, межі minSendable і maxSendable та опис metadata; суму передають у полі amount, а рахунок отримують у pr. Суми виражені в msat, тисячних частках satoshi: 1000 msat = 1 sat. Той самий публічний QR можуть використовувати інші люди, але його сканування не підтверджує платіж. [3]
У withdrawRequest напрямок протилежний. Анна хоче вивести залишок із сервісу, а не заплатити йому. Тому її гаманець створює рахунок на отримання коштів, який має оплатити сервіс. Той надає ідентифікатор k1, адресу callback і межі minWithdrawable та maxWithdrawable у msat; після згоди гаманець передає рахунок у pr. Відповідь OK означає, що сервіс прийняв запит, а не що Анна вже отримала гроші. Гаманець усе ще чекає на надходження. Код виведення може діяти як ваучер для того, хто ним володіє, тому не публікуйте його як звичайний контакт для приймання платежів. [4]
На іншому сайті Анна вибирає LNURL-auth. Гаманець показує домен і мету запиту з tag login. За її згодою він підписує одноразовий перевірочний запит k1 приватним ключем для цього домену, linkingPrivKey. Сервіс отримує підпис і відповідний публічний ключ linkingKey, за допомогою якого можна перевірити підпис. Приватний ключ гаманець не передає. Сервіс може впізнати власника ключа під час наступного входу, але сама перевірка не встановлює його особу в реальному світі. Гаманець не передає сервісу seed — початкове секретне значення для виведення ключів — чи Seed Phrase, тобто слова відновлення. Технічно використовується підпис ECDSA на кривій secp256k1. Поле action може означати реєстрацію, вхід, прив’язування облікового запису або іншу авторизацію, тому варто читати підтвердження повністю. Підпис цього виклику сам по собі не є платежем у Bitcoin. [5]
Запит, відповідь сервісу та справжній рух коштів — різні етапи. Втративши зв’язок, Анна спершу перевіряє початковий платіж у гаманці. Повторна спроба з новим рахунком може спричинити ще один платіж. Необов’язкова процедура LUD-21 додає адресу verify для перевірки конкретного рахунку: settled true повідомляє про розрахунок, settled false — про ще не сплачений рахунок. Самого OK недостатньо. Відповідь може містити preimage — початкове секретне значення, пов’язане з платежем. Гаманець обчислює з нього хеш, тобто контрольне значення, і порівнює його з платіжним хешем у потрібному рахунку. Отримати довільне секретне значення недостатньо: воно має відповідати саме цьому платежу. Перевірка результату не забезпечує ані доступності сервісу, ані вхідної ліквідності — можливості спрямувати кошти до гаманця одержувача. [6] [3] [4]
HTTPS захищає передавання між гаманцем і сервісом, але не від самого сервісу. Він може спостерігати за запитами, їхнім часом і повторним використанням. Для входу також важлива повна назва домену: зміна піддомену може створити інший linkingKey, і сайт побачить іншого користувача. Перехід до іншого гаманця теж не гарантує відновлення того самого входу, бо застосунки по-різному виводять ключі. Перед важливою зміною перевірте відновлення доступу саме до цього облікового запису. LNURL не визначає, хто тримає ключі для розпоряджання біткоїнами; це залежить від гаманця та сервісу. [2] [5]
Базова процедура LUD-01 подає HTTPS або onion URL у форматі Bech32. Це кодування, а не шифрування адреси й не рахунок BOLT 11. Гаманець читає tag безпосередньо з посилання або виконує вебзапит GET для отримання даних і визначає дію з відповіді JSON. Цей формат надає даним назви та структуру, зрозумілі застосунку. Отже, саме зображення QR не підтверджує особу одержувача. Важливі вміст посилання та домен, дія й умови, які згодом покаже гаманець. [2]
У процедурі оплати metadata — це текстовий рядок із масивом JSON. Він має містити опис text/plain; інші типи необов’язкові. Гаманець повинен показати опис разом із доменом і сумою, щоб людина розуміла свою згоду. Базовий LNURL тлумачить JSON-тіло відповіді, а не лише код стану HTTP. Доступний сервер тому ще не означає успішного запиту: відповідь може містити ERROR. Так само рахунок, отриманий у pr, ще не оплачений. Застосунок не повинен зводити ці різні відомості до однієї зеленої позначки. [2] [3]
Для повної картини прочитайте також BOLT 11, BOLT 12, Lightning Network, Lightning Address, Приватність у Bitcoin, Satoshi. На цю статтю також посилаються BOLT 12, Lightning Address, Confirmo.