Rusty Russell

Великі проєкти часто починаються непомітно. Огляд Blockstream від 9 червня 2026 року згадує перший коміт Russell від 26 травня 2015 року: маленький інструмент для створення повідомлення про відкриття каналу. Коміт — це записана зміна в історії коду. З раннього експерименту виріс Core Lightning; Russell працював над програмою, тестами й навчанням інших розробників. Стаття також описує його відхід після одинадцяти років. Вона не оголошує завершення всіх майбутніх внесків у відкриті проєкти й не перетворює колишню керівну роль на постійну владу над мережею. [1]

Уявіть кав’ярню та покупця з різними програмами. Платіж не повинен залежати від вибору одного постачальника. Потрібні спільні правила для повідомлень та їхнього значення. Цю взаємодію в Lightning описують специфікації BOLT. Russell координував їхню спільну розробку та підтримував інтероперабельність — здатність різних реалізацій працювати разом. Публічний репозиторій приймає пропозиції й зауваження. Навіть вагомий учасник не може сам нав’язати зміну всім вузлам: правила мають утілитися в реальному програмному забезпеченні та його використанні. [1] [2]

Дві програми можуть по-різному зрозуміти той самий абзац. Створений Russell lnprototest пропонує інструменти мовою Python для написання сценаріїв і перевірки відповідей на повідомлення протоколу. README, вступна документація проєкту, розрізняє імітаційний запуск і тестування справжньої реалізації. Імітація допомагає підготувати тест, але її успіх не доводить поведінки реального вузла. Важливо знати, що саме запускали та які ситуації перевірили. Навіть успішний набір сценаріїв не є повним аудитом усіх можливих помилок. [3]

За BOLT 12 кав’ярня може опублікувати багаторазову пропозицію, наприклад QR-код. Гаманець покупця надсилає на її основі invoice_request і отримує окремий рахунок — платіжний запит із даними конкретної оплати. Лише потім відбувається платіж. Покупці можуть повторно використовувати пропозицію, щоразу отримуючи окремі рахунки. Це не означає, що вже використаний рахунок стає новим запитом для кожної покупки. Розділення пропозиції, запиту й рахунку спрощує оплату, не змішуючи різні операції. [4]

Core Lightning робить це розділення помітним. Команда fetchinvoice звертається до автора пропозиції та отримує рахунок. Поле changes може показувати відмінності від пропозиції, наприклад в описі чи сумі. Успішна відповідь не переказує гроші. Це схоже на отримання рахунку в кав’ярні: спочатку перевіряєте, за що й скільки треба сплатити. Гаманець має опрацювати повернуті умови й окремо почати платіж. Завершене завантаження запиту не слід плутати із завершеною оплатою. [5]

Документація pay розрізняє complete, pending і failed: завершено, очікується та невдача. Очікування не підтверджує оплату. Також amount_msat означає суму для отримувача, а amount_sent_msat — загальну надіслану суму з комісіями. msat — це millisatoshi, тисячна частка satoshi. Отже, покупець може витратити на комісію більше, ніж отримає кав’ярня. Документація вже позначає pay як застарілий інтерфейс і описує перехід на xpay. Тут пояснено стани й суми, а не встановлення певної версії; результати слід тлумачити за програмою, яку справді використовують. [6]

Повертаючи гроші, кав’ярня не прокручує початковий платіж назад. BOLT 12 описує і зворотний напрямок: продавець повідомляє суму до переказу, покупець надає рахунок, а продавець перевіряє invoice_node_id — ідентифікатор вузла, якому слід платити. Потім іде новий платіж покупцеві. Це не скасовує початковий переказ і не створює автоматичного права на повернення. Протокол дає спосіб його виконати; причину й умови учасники мають узгодити окремо. [4]

Під час спору важливо знати, що саме підтверджує доказ. BOLT 12 пояснює, що preimage — секретне значення, яке відповідає хешу платіжного запиту, — може довести оплату рахунку. Однак після оприлюднення його може показати й інша людина; саме по собі воно не визначає, хто надіслав гроші. Ключ у запиті дає змогу довести, хто запросив рахунок, але не встановлює автоматично офіційну особу людини. Оплачений рахунок, контроль над ключем і особа покупця — різні відомості. [4]