Rusty Russell — разработчик открытого программного обеспечения, внёсший значительный вклад в Core Lightning, программу для работы узла Lightning Network. Он также работал над общими спецификациями BOLT и продвигал BOLT 12, позволяющий получать новые платёжные запросы из многоразового предложения. Lightning передаёт платежи в bitcoin через платёжные каналы.
Большие проекты часто начинаются незаметно. Ретроспектива Blockstream от 9 июня 2026 года вспоминает первый коммит Russell от 26 мая 2015 года: небольшой инструмент для создания сообщения об открытии канала. Коммит — записанное изменение в истории кода. Ранний эксперимент вырос в Core Lightning; Russell работал над программой, тестами и обучением других разработчиков. Статья также описывает его уход после одиннадцати лет. Она не объявляет конец всех будущих вкладов в открытые проекты и не превращает прежнюю руководящую роль в постоянную власть над сетью. [1]
Представьте кафе и покупателя с разными программами. Платёж не должен зависеть от выбора одного поставщика. Нужны общие правила для сообщений и их смысла. Спецификации BOLT описывают это взаимодействие в Lightning. 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]
Для полной картины прочитайте эту статью вместе с Andrew Poelstra, Tadge Dryja, Lightning Network. На эту статью также ссылаются Andrew Poelstra, Tadge Dryja.