Bitcoin Optech Newsletter #429

Silent payments for multiparty wallets

Bitcoin Optech выделяет протокол, представленный Олександром Курбатовым, который позволяет выполнять тихие платежи из кошельков, использующих схемы мультиподписей, такие как FROST и MuSig2. Дизайн позволяет координатору собрать взвешенные ECDH‑доли от каждого подписанта, а затем агрегировать доказательство AggDLEQ, удовлетворяющее BIP374. Поскольку обмен доказательством остаётся внутри канала координации кошелька, новые поля PSBT или изменения BIP не требуются. Курбатов отмечает, что статья с формальными доказательствами безопасности находится на внутреннем рассмотрении, но ключевое утверждение — что скомпрометированные подписанты и координатор не могут подделать доказательство — зависит от предположения, сложность которого пока остаётся открытым вопросом.

Core Lightning denial‑of‑service vulnerability

В выпуске также описывается ошибка самореферентного объявления канала, обнаруженная Нишантом Банслом в Core Lightning (CLN) версиях 25.02‑26.04. Программное обеспечение не проверяло различие идентификаторов узлов в объявлении канала, позволяя создать специально сформированное объявление, которое сохранялось на диск и приводило к падению узла при каждом перезапуске. Для эксплуатации требовался лишь финансируемый 2‑of‑2‑вывод и минимальные комиссии в цепочке. Проблема была ответственно раскрыта, исправлена в CLN 26.04.1 и отражена в BOLT 7 требованием #1333. Операторам, использующим уязвимые версии, настоятельно рекомендуется как можно быстрее обновиться.

Updated Bitcoin Core security policy

Антуан Пуансо объявил об изменении подхода Bitcoin Core к обработке уязвимостей «легко обнаруживаемых» — тех, которые можно найти с помощью простых запросов к большим языковым моделям или базового fuzz‑тестирования. Вместо ожидания крупного релиза проект теперь переносит исправления во все поддерживаемые ветки, быстро выпускает точечные обновления и публикует advisory‑сообщения вместе с ними. Три упомянутые уязвимости (Core #36665, #36667, #36669) были исправлены в рамках этой новой политики, из‑за чего помеченный релиз 32.0 был пропущен в пользу 32.1, который также добавил оценку комиссии на основе mempool, значения по умолчанию для PSBTv2 и ускоренную проверку блоков.

Caveats and implications

Хотя протокол тихих платежей совместим с существующими стандартами, его безопасность основана на непроверенном предположении, поэтому разработчикам следует рассматривать его как экспериментальный, пока не появятся рецензируемые доказательства. Ошибка в CLN демонстрирует, как тонкие проверки на уровне протокола могут привести к системным сбоям, подчёркивая важность своевременных обновлений. Сдвиг политики Bitcoin Core отражает растущее влияние AI‑ассистированного анализа кода и необходимость быстрой реакции на низкосерьёзные, но широко эксплуатируемые проблемы.

What readers should do

Разработчикам кошельков рекомендуется экспериментировать с подходом AggDLEQ в тестовых средах, но следить за предстоящими аудитами безопасности перед внедрением в продакшн. Операторам узлов следует убедиться, что они используют CLN ≥ 26.04.1 и Bitcoin Core ≥ 32.1, а также применить рекомендованные точечные обновления для старых веток. Поддержание актуальности снижает риск как новых протокольных атак, так и растущего класса легко обнаруживаемых багов.