BOLT 11

Анна покупает электронную книгу. Вместо банковских реквизитов магазин показывает Lightning-счёт, из которого кошелёк читает платёжные данные. Анне не нужно понимать длинную строку: перед подтверждением она проверяет сумму, назначение и комиссию. Некоторые счета оставляют сумму открытой, например для добровольной поддержки. Тогда её вводит плательщик; отсутствие суммы не означает нулевой платёж. Для любопытных: lnbc обозначает основную сеть, lntb — testnet, lntbs — signet, lnbcrt — regtest, то есть тестовые среды. Закодированная сумма указана в BTC, при необходимости с множителем m, u, n или p, а не непосредственно в satoshi. При p она должна оканчиваться цифрой 0, чтобы соответствовать целым millisatoshi: 1000 msat = 1 sat. [1]

Описание связывает технический запрос с человеческой целью, например с книгой Анны. Счёт содержит либо текст в поле d, либо его цифровой отпечаток в h. Отпечаток вычисляется с помощью SHA256; кошелёк должен проверить, что полученное отдельно описание даёт тот же результат. Такое короткое контрольное значение, вычисленное из текста, называют хешем. По одному отпечатку заказ не прочитать. Верная подпись связывает описание с ключом получателя, но не обещает, что продавец доставит книгу. Разработчикам следует помнить и другое: описание — чужой текст, который нужно безопасно показывать как данные, а не исполнять как код. [1]

Анна оставляет заказ открытым и возвращается позже. Если кошелёк сообщает об истёкшем счёте, нужно запросить новый. Конец срока определяется временем создания timestamp и длительностью x. Без x по умолчанию действует 3600 секунд, то есть час. Истечение срока не отменяет завершённый платёж. Поле c, технически min_final_cltv_expiry_delta, задаёт другое: временной запас последнего условного платежа HTLC на маршруте. HTLC ставит расчёт в зависимость от своевременного предъявления правильного секрета. Запас измеряется в блоках, не в секундах действия счёта; без c плательщик использует не менее 18 блоков. Эти сроки нельзя смешивать. [1]

Платёж Lightning проходит через платёжные каналы. В канале две стороны обновляют распределение средств, не записывая каждый обычный платёж в основной блокчейн Bitcoin. Для успешного платежа нужны доступный маршрут и достаточно средств на соответствующих сторонах каналов — ликвидность. Поле r может содержать routing hints, подсказки для последнего участка. Они помогают найти получателя, но не показывают доступную ёмкость в реальном времени. Кроме того, они могут раскрывать публичные ключи узлов, идентификаторы каналов и параметры комиссий. Поэтому полный счёт не следует считать приватным. Необязательное поле f может предлагать обычный Bitcoin-адрес как запасной вариант. Платёж на него идёт по основной цепочке, имеет собственные комиссии и требует подтверждений. Это не просто другая кнопка для того же способа доставки. [1] [2] [5]

Отсканированный QR и полученный счёт — не квитанция. После отправки проверьте результат в кошельке: ожидание отличается от завершения. Расчёт также подтверждается правильным preimage — секретным значением, хеш которого должен совпадать с платёжным хешем счёта. Оба можно сохранить как доказательства платежа, но не как гарантию доставки товара. Если приложение отключилось или потеряло ответ, сначала проверьте состояние исходного платежа. Немедленный запрос нового счёта или оплата запасного адреса могут привести к повторной оплате. Некоторые кошельки распознают повторные попытки, но сам формат не даёт универсальной защиты между приложениями и платёжными путями. [2] [4]

Длинная строка использует кодирование Bech32. Его контрольная сумма помогает обнаружить ошибки переписывания; это не шифрование и содержимое она не скрывает. Цифровая подпись ECDSA на secp256k1 решает другую задачу: проверяет связь платёжных данных с ключом получателя и отсутствие последующих изменений. Она не подтверждает личность по документам или честность владельца ключа. В отличие от Bitcoin-адресов Bech32, BOLT 11 может превышать 90 символов. Заглавные буквы удобны для QR, но правильная строка не должна смешивать верхний и нижний регистр. Человек обычно сканирует или копирует счёт, а проверки выполняет кошелёк. [1]

Payment hash — цифровой отпечаток секретного payment preimage, вычисленный с помощью SHA256 и записанный в p. При успешном расчёте плательщик узнаёт preimage и может проверить совпадение отпечатка. Поле s, напротив, содержит payment_secret. Плательщик читает его уже из счёта и передаёт получателю на последнем участке маршрута; это помогает защищать получателя от зондирования промежуточными узлами. Secret — не preimage и не seed кошелька. Прочитать его из QR не значит доказать оплату или получить возможность восстановить кошелёк. Текущий BOLT 11 требует p и s. За похожими названиями стоят разные задачи: распознать платёж, передать нужное значение и подтвердить расчёт. [1] [2]

Кошельки должны понимать, поддерживают ли они запрошенный платёж. Поле 9 содержит флаги возможностей. Неизвестный чётный бит означает обязательную функцию и требует отказа от платежа; неизвестный нечётный является необязательным и может игнорироваться. Известные зависимости между функциями тоже должны выполняться. Например, Basic MPP делит один платёж на части, которые объединяются у получателя. Применять его можно только при наличии basic_mpp в счёте. Разделение не создаёт несколько самостоятельных счетов и не даёт повода платить каждую часть заново. Для новичка вывод прост: не обходите сообщение о неподдерживаемой функции ручным редактированием счёта; сначала решите вопрос совместимости кошельков. [1] [3]