Трохи більше тижня тому Метт Коралло запропонував BIP для координації здійснення платежів біткойнами. Здійснення платежів у біткойнах завжди представляло певну проблему з точки зору координації як у ланцюзі, так і поза ланцюгом із такими протоколами, як Lightning, з різних причин. Коли мова йде про цифрові системи, такі як електронна пошта, або платіжні системи, такі як Paypal, Cashapp тощо, люди дуже звикли до концепції єдиного статичного ідентифікатора. Якщо ви хочете надіслати Джону електронний лист, просто надішліть електронний лист «john@[вставити домен]». Якщо ви хочете надіслати Джону гроші на Cashapp, просто надішліть платіж @John на Cashapp.
Люди знайомі з таким користувальницьким досвідом, і коли мова йде про вкорінену поведінку та очікування користувачів щодо речей, неймовірно важко підштовхнути їх до суттєвих або різких змін у їхній поведінці. Якщо ви надасте їм інструмент, який цього вимагає, це створить значний рівень тертя і, швидше за все, просто перешкодить більшості людей використовувати цей інструмент.
Платежі в ланцюжку стикаються з проблемою з цим очікуванням не через неможливість мати статичний ідентифікатор (єдину адресу), а через наслідки для конфіденційності публікації єдиної адреси в ланцюзі та використання нею всіх, з ким ви взаємодієте. щоб заплатити вам. Уся ваша історія платежів і права власності на монети доступні для всіх. Якщо ви рідко отримуєте гроші знову й знову, наприклад, коли вам платять за роботу або розраховуються з людьми в барі, зовсім не складно просто відкрити свій гаманець і створити нову адресу для отримання. Однак якщо ви часто отримуєте гроші, особливо в тих випадках, коли ви безпосередньо не вимагаєте платіж, це становить серйозний тягар.
Ось чому були створені такі інструменти, як сервер BTCPay, щоб знизити бар’єр доступу для людей, щоб розгорнути необхідну інфраструктуру для автоматизації отримання коштів, не роблячи чогось наївного, як-от розміщення єдиної адреси для повторного використання для всіх, хто платить вам. Однак це вимагає запуску сервера, який постійно доступний в Інтернеті. Незважаючи на те, що проект різко знизив планку необхідного розуміння, це все ще велике навантаження для користувача, який просто хоче мати можливість пасивно отримувати гроші.
Те ж саме стосується Lightning, але гірше. Рахунок-фактура підходить лише для одноразового платежу. На відміну від адреси в ланцюжку, яку можна повторно використовувати, навіть якщо це жахлива практика, рахунок-фактуру Lightning використовувати не можна. Після того, як рахунок-фактура буде оплачено або термін дії закінчиться, відповідний вузол Lightning відхилить будь-які спроби оплатити його. Ця динаміка призвела до створення специфікації LNURL, а також адрес Lightning, побудованих на її основі. LNURL — це протокол для підключення до HTTP-сервера через статичну IP-адресу, якою можна поділитися один раз, щоб отримати фактичний рахунок-фактуру Lightning для оплати з сервера. Крім того, адреси Lightning — це схема іменування на основі LNURL, структурована подібно до адрес електронної пошти: John@[домен сервера LNURL].
Усі ці рішення мають недоліки. Вимога щодо запуску додаткового програмного забезпечення (HTTP-сервера), який постійно залишається онлайн, на додаток до вашого гаманця Bitcoin або вузла Lightning; під час виконання запиту до сервера BTCPay/LNURL IP-адреса відправника передається одержувачу; покладаючись на центри сертифікації TLS.
Просто використовуйте DNS
Інструмент HTTP-сервера, як-от LNURL, у поєднанні з Lightning Address використовує домени для вирішення підключення до HTTP-сервера. Подібним чином всі сервери BTCPay налаштовані з доменами, а не з використанням необроблених IP-адрес. Метт вважає, чому б просто не відмовитися від HTTP і використовувати саму систему доменних імен?
DNS дозволяє вам пов’язувати записи TXT із певним доменним іменем, створюючи невеликі записи, які можна прочитати людиною (або машиною), які можна запитувати з серверів DNS. У поєднанні з розширеннями безпеки системи доменних імен (DNSSEC) записи TXT DNS забезпечують механізм, який можна використовувати для запиту платіжної інформації без накладних витрат і тягаря роботи HTTP-сервера, а також пропонують трохи більше гнучкості та відкритості. DNSSEC надає ряд інструментів для криптографічного підпису записів DNS, включаючи записи TXT, з ключами DNS, властивими ієрархічній структурі DNS. Це забезпечує гарантію того, що запис TXT, який ви запитуєте, є записом, підписаним і розповсюдженим на DNS-сервери нижчого рівня з локального кореневого сервера/ключа.
Це приносить реальні переваги DNS як засобу для отримання платіжних даних: попрощайтеся з вимогою запуску HTTP-сервера. Запис TXT може кодувати біткойн-адресу в ланцюжку (хоча BIP спеціально рекомендує ПРОТИ цього, якщо ви не в змозі регулярно змінювати нові адреси, щоб запобігти повторному використанню адрес), але, що більш важливо, він також може містити пропозицію BOLT 12 Lightning.
Ці записи можна отримати з будь-якого DNS-сервера, вашого власного локального сервера, вашого інтернет-провайдера, навіть загальнодоступного сервера, як-от Google або Cloudflare. З цього базового пункту вирішено один недолік рішень на основі HTTP; ви більше не передаєте свою IP-адресу особі, якій намагаєтеся заплатити. Тепер, якщо ви використовуєте DNS вашого провайдера або загальнодоступний сервер, як-от Google або Cloudflare, без VPN або Tor, ви відкриваєте їм свою IP-адресу; BIP явно заохочує підтримку вирішення DNS через VPN або Tor саме з цієї причини.
Поєднання цієї пропозиції з BOLT 12 позбавляє від необхідності запускати допоміжне програмне забезпечення, яке представляє реальну проблему безпеки для недосвідчених користувачів, і дозволяє лише володіти доменом, щоб надати користувачам усе, що їм потрібно, щоб мати механізм для пошуку платіжної інформації за допомогою простої людини читабельний ідентифікатор. BOLT 12 не потребує HTTP-сервера, обробляє фактичну доставку рахунків-фактур через з’єднання, спрямовані на цибулину, безпосередньо через мережу Lightning, і підтримує пропозиції, статичний ідентифікатор, який можна використовувати для пошуку маршруту цибулини до цього вузла Lightning. Проблема полягає в тому, що Пропозиція закодована як масивний випадковий рядок, схожий на сам рахунок-фактуру, що робить його жахливим ідентифікатором, який можна прочитати/використати людиною, за винятком використання QR-кодів або копіювання та вставлення.
Зберігаючи пропозицію в записі TXT DNS, все, що потрібно користувачеві для здійснення платежу, — це чийсь домен, який потрібно ввести у свій гаманець, щоб він міг отримати запис TXT, отримати пропозицію BOLT 12 і потім здійснити платіж. Їм не потрібно розміщувати будь-який сервер або запускати будь-яке інше програмне забезпечення, окрім свого вузла Lightning, система DNS обробляє все за них, що стосується розміщення їхнього BOLT 12. Запропонуйте когось, кого зможуть знайти користувачі, які бажають їм заплатити.
Це абсолютно ненадійна система? Ні. Це набагато краще, ніж системи на основі HTTP? Абсолютно. Проблема з такими проблемами полягає в тому, що існує певне очікування щодо UX і поведінки більшості людей, оскільки цифрові системи повинні працювати в їхній свідомості. Без копіювання цього UX великі групи людей просто використовуватимуть альтернативи, які відповідають очікуванням UX. Враховуючи таку реальність, намагаючись вписати біткойн у рамки цих очікувань UX, мета дизайну повинна полягати в тому, щоб задовольнити потреби користувачів з мінімальною кількістю довіри, мінімальним обсягом тягаря, що покладається на користувачів, і мінімальним потенціалом для втрата конфіденційності новими способами. Я думаю, що Matt's BIP перевіряє всі ці поля в порівнянні з існуючими рішеннями.
Джерело: https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-payments