BOLT 12 — протокол согласования платежа Lightning через offer, invoice_request и invoice. Предложение многоразовое, но каждый платёж имеет собственные условия и результат для проверки.
Получатель публикует offer; плательщик отправляет invoice_request и получает новую invoice. Только затем возможна оплата. Предложение может служить разным людям или повторным платежам. Получение счёта, например через fetchinvoice, не оплачивает его; публичный QR не является постоянным разрешением на списание. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]
BOLT 12 хранит поля как TLV. Текстовые предложения имеют префикс lno, запросы lnr; алфавит похож на Bech32, но без конечной контрольной суммы. Сама offer не подписана. Подписи Schnorr BIP340 в запросах и счетах проверяют корень Merkle полей, не личность продавца. [BOLT 12 — Negotiation protocol]
Кошелёк сравнивает скопированные поля invoice_request с invoice, суммой, сетью и подписью. invoice_node_id должен соответствовать offer_issuer_id или нужному конечному blinded_node_id. Корректной посторонней подписи недостаточно. Структура Merkle допускает выборочные доказательства полей, не произвольное изменение подписанных условий. [BOLT 12 — Negotiation protocol]
Bitcoin invoice_amount задаётся в msat; 1000 msat — один satoshi. offer_currency может указывать другую валюту по ISO 4217; USD использует центы. На цену влияют количество и пересчёт при выставлении счёта. Если задано invreq_amount, счёт должен совпадать; иначе проверяется разрешённый диапазон. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
offer_paths ведёт сообщение с запросом, invoice_paths — платёж. Текущая invoice должна содержать blinded paths и соответствующий invoice_blindedpay, даже при прямом пути к получателю. Ослепление ограничивает раскрытие топологии, но не гарантирует полной анонимности, доступности или ликвидности. Запрос счёта не требует обычного платёжного HTTPS сервера. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]
offer_absolute_expiry ограничивает предложение. invoice_created_at вместе с invoice_relative_expiry ограничивает конкретный счёт; без второго поля действуют 7200 секунд. Многоразовость не даёт счетам бесконечного срока. Неизвестные чётные обязательные биты отклоняют, неизвестные нечётные игнорируют. [BOLT 12 — Negotiation protocol]
При возврате желающий отправить деньги может опубликовать invoice_request без offer. Получатель денег отвечает собственной invoice; плательщик обязан проверить нужного получателя, при необходимости вне протокола. Это новый платёж, не отмена старого. Само сканирование не доказывает право на деньги или одобрение оплаты. [BOLT 12 — Negotiation protocol]
Храните invoice, состояние платежа и соответствующий preimage. Preimage доказывает расчёт по счёту, но сам не определяет человека-плательщика. Потеряв ответ, проверьте состояние перед новой оплатой. Поддержка предложений не означает всех расширений или автоматических регулярных платежей; отдельно проверяйте приём, отправку и права приложения. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
Для полной картины прочитайте эту статью вместе с BOLT 11, Lightning Network, Lightning Routing, Приватность в Bitcoin, Satoshi, LNURL. На эту статью также ссылаются BOLT 11, LNURL.