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

2 мин

Кандидат на релиз LND от 22 октября сосредоточен на защите кошельков от некорректных внешних оценок комиссий и повышении надежности узлов. Сборка v0.21.5-beta.rc1 ограничивает удаленные входные данные по комиссиям и исправляет взаимную блокировку в пуле подключений SQL. Это предварительный релиз, который требует тестирования с учетом конкретной среды разворачивания; проверка бинарников не заменяет операционную валидацию.

Итого

Сборка: предварительный релиз v0.21.5-beta.rc1.
Комиссии: добавлена верхняя граница для внешних оценок; ограничена также минимальная оценка relay в API.
Операции: миграции БД нет; включено исправление взаимной блокировки пула подключений SQL; проверяйте загрузки и отдельно тестируйте поведение.

Внешние оценки комиссий теперь имеют верхние пределы до попадания в кошелек

Примечания к релизу указывают, что ранее у внешних оценок комиссий был только нижний предел. Это изменение добавляет потолок в 10 000 сатоши за виртуальный байт и ограничивает минимальную оценку relay в API. Так создается предохранитель от экстремальных значений, чтобы нерабочие параметры из-за ошибок, изменений формата или компрометации зависимостей не попадали в операции кошелька, чувствительные к комиссиям. Обновление соответствует потребности, отраженной в пересмотренном процессе раскрытия уязвимостей в Bitcoin Core, в своевременном обнаружении проблем и путях их оперативного исправления в софте, работающем с деньгами.

Статус предварительного релиза и операционная надежность

Страница релиза на GitHub помечает сборку как предварительную и отмечает, что миграция базы данных не требуется. В нее включены подписи и шаги проверки бинарников, которые подтверждают целостность загрузки, но не поведение в разных конфигурациях узлов. В примечаниях также задокументировано исправление нативной взаимной блокировки в пуле подключений SQL, подчеркивая, что надежность узла зависит как от подсистемы хранения, так и от сетевого ввода-вывода. Тестирование должно проверять реальные нагрузки: обработку запросов, доступ к хранилищу, обработку сбоев и корректные перезапуски. Отсутствие миграции исключает одну категорию изменений, но не гарантирует неизменные взаимодействия с существующими данными. Для платежных провайдеров вопросы кастодиальных договоренностей и безопасности ключей отделены от поддержания работоспособности платежного узла; обслуживание и тестирование по-прежнему необходимы.