BOLT12 (Offers) — это расширение Lightning Network, которое вводит повторно используемые платежные запросы (*offers*), приватные маршруты через *blinded paths* и обмен служебными сообщениями поверх сети (onion messages) без веб-серверов и сторонних API. В отличие от одноразовых счетов BOLT11, оффер — это «короткий дескриптор», который можно показывать как статический QR: кошелёк плательщика запрашивает у получателя уникальный инвойс и оплачивает его по Lightning.
Ключевые эффекты: - статический QR/строка → меньше трения в донатах, витринах, профилях; - приватность получателя через «защищённые маршруты» (blinded paths); - обмен служебными данными полностью внутри Lightning (без HTTP); - встроенные сценарии возвратов (refund) и рекуррентных платежей.
Зачем понадобился BOLT12
Проблемы BOLT11. Классический счёт (BOLT11) одноразовый: после оплаты он «исчерпан». Для донатов/витрин приходится генерировать новый счёт каждый раз (и где-то держать сервер). Кроме того, BOLT11 не решает приватность получателя «из коробки» и опирается на внешние методы для статических QR.
Альтернатива LNURL. LNURL дал статические коды через HTTP-запросы к серверу получателя. Это удобно, но требует домена/сайта и раскрывает сетевые метаданные.
Ответ Offers. BOLT12 перемещает «переговоры» внутрь Lightning: оффер — это компактное описание намерения «принять деньги», обмен деталями и выпуск «живого» счёта идут через onion messages; получатель может скрывать топологию своего узла через blinded paths.
Архитектура и поток сообщений
Базовый поток: - Offer — статический дескриптор получателя (показывается как QR/строка). - Invoice Request — кошелёк плательщика, считав оффер, отправляет *invoice_request* получателю (внутри Lightning). - Invoice — получатель отвечает одноразовым инвойсом с уникальным платежным хэшем; плательщик его оплачивает.
Такой трёхшаговый обмен делает оффер повторно используемым: один и тот же QR/строку можно показывать где угодно — каждый плательщик получит собственный инвойс и оплатит его обычным путём Lightning.
Важные элементы протокола: - Onion messages. Служебные сообщения передаются тем же луковым маршрутизационным слоем, что и платежи: не нужен веб-сервер, домен и прочая веб-инфра. - Blinded paths. Получатель публикует «ослеплённые» хвосты маршрута, скрывая свой реальный граф соединений/узел. Плательщик доставляет *invoice_request* и получает *invoice* через эти «занавешенные» пути. - Invoice negotiation. В оффере можно указать валюту/сеть, минимальную/максимальную сумму, требования к описанию и др.; итоговый инвойс содержит финальные условия оплаты.
Возможности, которых не было в BOLT11
Статические офферы и «вечные QR». Один оффер можно использовать многократно (донаты, «банка чаевых», подпись в профиле).
Возвраты (refund). Плательщик может идентифицировать себя специальным ключом (payer id) при *invoice_request*, что позволяет получателю оформить корректный возврат по связанному реквизиту без внеполосной переписки.
Рекуррентные платежи (recurrence). Оффер может описывать расписание (периодичность, окна), а кошельки — напоминать/инициировать оплату в нужные даты (подписки, регулярные пожертвования).
Приватность получателя. *Blinded paths* скрывают конечный узел/маршрут. В связке с onion messages это даёт оплату без раскрытия IP/домена.
Меньше зависимости от сторонних сервисов. Всё идёт поверх Lightning: вместо веб-запросов — луковые сообщения; это повышает устойчивость к блокировкам и цензуре.
Сравнение: BOLT11, LNURL и BOLT12
| Критерий | BOLT11 (инвойс) | LNURL (HTTP) | BOLT12 (Offers) |
|---|---|---|---|
| Статический QR | Нет (одноразовый счёт) | Да (сервер генерирует счёт) | Да (запрос инвойса внутри LN) |
| Веб-инфра | Не обяз., но часто нужна | Нужна (домен, сервер) | Не нужна (onion messages) |
| Приватность получателя | Базовая | Зависит от сервера | Blinded paths |
| Повторное использование | Нет | Да | Да |
| Возвраты | Нет «из коробки» | Зависит от сервиса | Встроенные сценарии |
| Рекуррентные платежи | Нет | Возможны на уровне сервиса | Встроены в оффер |
| Совместимость | Широкая | Зависит от кошельков | Растущая поддержка |
Как это выглядит для пользователя
Донаты и «банка чаевых». Вы публикуете один QR-код оффера — его можно сканировать сколько угодно раз (каждый увидит собственный счёт для оплаты).
Магазин/витрина. Страница товара может показывать оффер с параметрами (описание, валюта, пределы), кошелёк покупателя запросит инвойс на нужную сумму.
Подписки. Оффер с периодичностью → кошелёк напомнит и выполнит оплату по расписанию (с подтверждением пользователя).
Возвраты. При споре/отмене продавец оформит возврат прямо в Lightning, не спрашивая у клиента дополнительные реквизиты.
Приватность: как работают blinded paths
Вместо публикации реального конечного узла получатель даёт «зашифрованный хвост» маршрута. Плательщик прокладывает путь «до занавеса», а дальше пакет проходит по «ослеплённому» сегменту, не раскрывая карту сетевых связей. Это защищает топологию узла, снижает риски таргетинга и «выжигания» приватных каналов.
Практические заметки: - blinded paths не «магия»: они усложняют анализ, но не отменяют сетевые метаданные на ранних hop’ах; - кошельки должны уметь корректно подбирать маршруты с учётом «занавеса»; - для устойчивости офферы обычно включают несколько blinded paths.
Возвраты и контекст платежа
При *invoice_request* кошелёк плательщика может добавлять payer id/metadata. Ответный инвойс «привязывается» к этому контексту; если нужен refund, получатель может сформировать возврат на адрес/ключ плательщика по правилам BOLT12, не требуя внеполосных реквизитов.
Что это даёт: - возвраты в одном UX-контуре (без email/HTTP); - простую сверку «какому платежу соответствует возврат»; - меньше ошибок и фишинга с реквизитами.
Рекуррентные платежи
Оффер может указывать периодичность (например, «раз в месяц»), окно платежа и лимиты. Кошелёк хранит оффер, создаёт *invoice_request* по расписанию и получает инвойс для очередного списания (подтверждение пользователем — по политике кошелька). Это полезно для подписок и регулярных донатов.
Хорошая практика: показывать пользователю календарь предстоящих списаний, лимиты и быстрый «стоп»/паузу.
Интеграция и поддержка реализаций
Статус экосистемы (на 2025): - ряд узлов и SDK уже поддерживают Offers и работу с onion messages/blinded paths; - в части популярных имплементаций поддержка развивается поэтапно; в некоторых — через дополнительные компоненты/плагины; - UI-клиенты постепенно добавляют генерацию/оплату офферов, «банку чаевых», рекурренс и возвраты.
UX-паттерны для кошельков: - единая кнопка «Принять» → показать оффер (QR/строка), скопировать, поделиться; - «Оплатить» → распознать BOLT12/BOLT11/LNURL, корректно обработать оффер и запросить инвойс; - история платежей с «сшивкой» оффер ↔ инвойс ↔ возврат; - явные подсказки по приватности (blinded paths, отсутствие HTTP).
Ограничения и тонкости
Совместимость кошельков. Не все клиенты одинаково поддерживают Offers и все опции BOLT12 (refund, recurrence, blinded paths). В витринах полезны фолбэки: показывать оффер + BOLT11/LNURL при необходимости.
Маршрутизация и комиссии. Blinded paths немного усложняют выбор маршрута: кошельки должны учитывать скрытый хвост и прогнозировать вероятность успеха/стоимость.
Оповещения/доставляемость. Поскольку обмен сообщениями идёт по Lightning, а не по пуш-HTTP, UX может отличаться от «обычной» веб-модели: разработчикам стоит предусмотреть ретраи, кэширование и повторные попытки получения инвойса.
Безопасность QR. Оффер — «приглашение к переговорам». Храните приватные ключи узла в безопасности, а публичные офферы — верифицируйте в UI (показывайте человека-читаемое описание, сумму/лимиты).
Лучшие практики внедрения
* Давайте пользователю один статический QR (оффер) для «донатов» и профилей. * В товарных карточках используйте офферы с параметрами (описание, min/max, валютные подсказки). * Включайте несколько blinded paths на случай деградации маршрутов. * Поддержите refund и показывайте связь «платёж ↔ возврат». * Реализуйте recurrence как подписку с прозрачными лимитами и напоминаниями. * Делайте фолбэки на BOLT11/LNURL там, где экосистема ещё не дотянулась. * Логируйте и визуализируйте статусы: «offer считан → invoice_request отправлен → invoice получен → оплачен».
FAQ
Чем BOLT12 лучше статических LNURL? LNURL требует домена/сервера и раскрывает сетевые метаданные. BOLT12 делает всё внутри Lightning (onion messages) и добавляет приватность через blinded paths — без веб-инфры.
Можно ли одним оффером принимать бесконечно много платежей? Да. Оффер многократно переиспользуется, каждый раз рождая новый одноразовый инвойс.
Как работают возвраты? Плательщик при *invoice_request* предоставляет идентификатор (payer id/metadata). Получатель может оформить возврат по связанным данным, не запрашивая «внешние» реквизиты.
Поддерживается ли «подписка»? Да. Офферы поддерживают рекуррентные схемы (recurrence), кошельки могут инициировать запрос счёта по расписанию.
Это заменит BOLT11? Скорее дополнит. BOLT11 остаётся базовым счётом, а BOLT12 решает статичность, приватность и UX-сценарии (донаты, подписки, возвраты).