LND ограничивает внешние оценки комиссий до 10,000 sat/vB в предрелизе

3 мин

Релиз-кандидат LND от 22 октября фокусируется на тихом риске кошельков: внешних оценках комиссий, которые софт принимает слишком доверчиво. Версия 0.21.5 вводит верхнюю границу для значений, получаемых из внешнего API комиссий, и включает исправления, влияющие на работу узла.

Кратко

Опубликованная сборка: v0.21.5-beta.rc1, предпросмотрная версия.
Изменение комиссий: ограничение экстремальных оценок, приходящих от внешнего сервиса.
Проверка vs тестирование: проверка подписей отличается от валидации поведения в рабочей среде.

Удалённым оценкам нужны пределы ещё до того, как они попадут в кошелёк

Release notes сообщают, что ранее внешние оценки обеспечивали только нижнюю границу. Исправление ограничивает оценку ещё до того, как она сможет повлиять на операции кошелька, чувствительные к комиссиям.

Изменение задаёт потолок в 10 000 сатоши за виртуальный байт и ограничивает минимально ретранслируемую комиссию, выдаваемую API. Этот лимит — страховка от запредельных значений, а не рекомендация по типичным или экономичным комиссиям.

Оценки комиссий — это входные данные для принятия решений, а не команды. Сервисы могут возвращать непригодные значения из‑за ошибок, изменений формата данных или компрометации зависимостей. Ограничение входных данных снижает влияние проблем «выше по цепочке» на кошелёк.

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

Кандидат в релизы всё ещё нуждается в подтверждении в своей рабочей среде

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

В заметках упомянуто исправление взаимоблокировки в нативном пуле подключений к SQL. Надёжность зависит от хранилища не меньше, чем от сети. Процесс, который «жив», но запросы перестают завершаться, всё равно приводит к сбоям в зависящих от него приложениях.

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

Операционный риск отличен от дизайна кастодиального решения. Это разделение применимо к Bitcoin‑кредитованию с shared-key, где защита права подписи отличается от поддержания работоспособности платёжного узла, и к схемам кастоди и восстановления, которые не заменяют сопровождение софта. Этот кандидат приносит конкретные изменения для оценки. Решение о финальном релизе и решение оператора о внедрении остаются отдельными этапами.