Как принять платёж в Lightning без собственного узла

Принять платёж в Lightning без собственного узла можно, потому что канал за вас держит посредник. Вариантов два: кастодиальный сервис, где ключи принадлежат оператору, и некастодиальный кошелёк, который работает с поставщиком услуг — тот открывает канал и обеспечивает входящую ёмкость. Контроль над средствами в этих схемах разный, комиссия берётся по-разному, а при недоступности посредника последствия тоже разные. Ниже — механика, цена и слабые места.

Почему приём без своего узла вообще возможен

Платёж в Lightning идёт по цепочке каналов. Канал — запись в сети биткоина, созданная двумя сторонами, и получать средства можно лишь в пределах той части ёмкости, которая находится на стороне отправителя. Новый кошелёк такой ёмкости не имеет. Отсюда и задача: кто-то должен открыть канал в вашу сторону и держать в нём средства.

Собственный узел решает её сам. Без узла роль второй стороны берёт на себя посредник. Платит за это получатель.

Спецификации этой роли описаны отдельно. Группа работ LSPS0, LSPS1 и LSPS2 переведена в статус предложений по улучшению Lightning и опубликована как bLIP-50, bLIP-51 и bLIP-52; исходный репозиторий группы переведён в архив 10 января 2025 года, текст проверен 16 октября 2026 года. Последний документ описывает схему, при которой канал открывается в момент прихода первого платежа.

Кто держит канал и что это меняет в контроле

Различие между второй и третьей строкой таблицы существеннее, чем кажется из интерфейса, потому что внешне обе схемы выглядят одинаково: остаток, кнопка приёма, код для оплаты — и ничто в этом наборе не подсказывает, кому принадлежит ключ. В некастодиальной схеме у кошелька есть собственные ключи и возможность закрыть канал в сети биткоина без согласия поставщика. В кастодиальной такой возможности нет: вывод средств — операция, которую выполняет оператор по вашей заявке, и её исполнение зависит от его работоспособности и правил.

Как принять платёж в Lightning без собственного узла: порядок действий

1. Определитесь со схемой хранения до первого платежа. Поменять её задним числом сложнее, чем выбрать осознанно.
2. Проверьте доступную входящую ёмкость. Если её нет, первый платёж вызовет открытие канала со стороны поставщика.
3. Выставьте счёт. Формат BOLT 11, проверенный 16 октября 2026 года, требует поля с хешем платежа и секретом платежа, а срок действия по умолчанию равен 3600 секундам, если он не указан явно.
4. Убедитесь, что счёт содержит подсказки маршрута. Спецификация требует их, когда у получателя нет публичного канала — а у кошелька без узла его обычно нет.
5. Примите платёж и сверьте зачисленную сумму с выставленной: разница и есть удержанная плата.
6. Решите, что делать с остатком — оставить в канале для будущих платежей или вывести в сеть биткоина.

Для регулярного приёма удобнее многоразовая форма. Спецификация BOLT 12 вводит предложение об оплате, из которого плательщик запрашивает отдельный счёт для себя; такое предложение живёт дольше конкретного счёта и подходит для статичного кода на витрине. Для разового перевода достаточно обычного счёта. Выбор зависит от потока.

Сколько это стоит: лимиты и комиссии посредника

Плата поставщика услуг в схеме с открытием канала по первому платежу устроена из двух частей: фиксированного минимума и доли от суммы платежа в миллионных долях. Берётся большее из двух значений. Результат удерживается из первого поступления. Конкретные ставки у разных поставщиков различаются и меняются — сверяйте их в условиях сервиса на дату подключения.

Вместе со ставками согласуются и границы. Спецификация предусматривает минимальный и максимальный размер платежа, при котором поставщик берётся открыть канал, срок действия предложенных условий, а также минимальное время жизни канала, которое поставщик обещает выдержать. Эти параметры стоит прочитать до первого платежа: платёж меньше минимального размера не пройдёт, а канал с коротким обещанным сроком придётся переоткрывать.

Третья статья расходов — ончейн-комиссия. Открытие и закрытие канала — транзакции в сети биткоина, и их стоимость зависит от загруженности сети в момент операции. Выбирать момент помогает статистика: методика разобрана в материале о том, как оценить нагрузку сети по историческим данным. Если транзакция закрытия застряла с низкой комиссией, применяются те же приёмы, что и при попытке ускорить зависшую транзакцию через повышение комиссии, с поправкой на механику конкретной сети.

Что происходит при недоступности посредника

• Кошелёк не в сети в момент платежа. Спецификация предписывает поставщику отклонить входящие части платежа с временной ошибкой канала и вернуться к ожиданию. Платёж не теряется, он не проходит; отправителю возвращается временная ошибка, и повторить оплату он сможет тогда, когда кошелёк получателя снова окажется на связи с поставщиком услуг.
• Поставщик услуг недоступен. Новые счета не оплачиваются, средства в уже открытом канале остаются вашими, но движения по нему нет до восстановления связи.
• Поставщик прекратил работу. Некастодиальный кошелёк закрывает канал в одностороннем порядке; средства возвращаются в сеть биткоина с задержкой, предусмотренной параметрами канала.
• Кастодиальный сервис недоступен. Доступа к средствам нет вовсе: остаток существует как запись в его учёте, а не как ваш ключ.

Разница между третьим и четвёртым пунктом и есть главный довод в пользу некастодиальной схемы. Доверие посреднику здесь устроено так же, как в переводах через мост между сетями: средства проходят через чужую инфраструктуру, и важно понимать, в какой момент они перестают зависеть от неё. Сопоставление вариантов такого рода приведено в разборе про мосты в сеть Base.

Ошибки, из-за которых приём срывается

• Счёт выставлен без проверки входящей ёмкости. Плательщик видит ошибку маршрута и уходит.
• Сумма ниже минимального размера платежа у поставщика. Канал не открывается.
• Срок счёта оставлен по умолчанию при оплате с задержкой в сутки.
• Кошелёк без резервной копии состояния канала. При утрате устройства возврат средств усложняется.
• Кастодиальный сервис выбран для хранения, а не для расчётов. Остаток на нём — обязательство оператора.
• Учёт поступлений ведётся по сумме счёта, а не по зачислению. Удержанная плата выпадает из отчётности.

Последний пункт заметен у тех, кто принимает много мелких платежей. Сверять приходится каждую строку. Сумма счёта, фактическое зачисление, удержание — три числа вместо одного. Для ончейн-операций похожую задачу решает разбор о том, как отследить пакет переводов одной операцией.

Итог

• Схема хранения выбрана осознанно: ключи у вас или у оператора.
• Входящая ёмкость проверена до выставления счёта.
• Минимальный и максимальный размер платежа у поставщика известны.
• Срок действия счёта задан явно, а не оставлен по умолчанию.
• Обещанное время жизни канала прочитано в условиях.
• Резервная копия состояния кошелька сделана и проверена.

Частые вопросы