Bitcoin Core 32.1 вышел 27 октября 2026 года: почему отозвали 32.0, три раскрытые уязвимости и новый оценщик комиссий

1. Что такое Bitcoin Core 32.1 и почему нет 32.0?

Bitcoin Core, эталонная реализация Bitcoin, представляет собой программу, которая валидирует блоки, ретранслирует транзакции и обслуживает кошелёк, стоящий за многими сервисами. Мажорная версия выходит примерно раз в полгода, поддерживаются три новейшие. Версия 32.1, опубликованная 27 октября 2026 года, стала первым публичным релизом линейки 32.x: новый оценщик комиссий, более высокие значения по умолчанию для соединений, более компактный индекс транзакций, PSBT версии 2 по умолчанию в RPC кошелька и пакет исправлений безопасности. Правила консенсуса она не меняет: блоки и транзакции, которые были валидны раньше, остаются валидными и после.

32.0 существует только как тег. Мейнтейнер fanquake поставил его 21 октября, а 26 октября написал в issue с расписанием релизов, что из-за проблем в последний момент 32.0 не будет ни анонсирована, ни выпущена и бинарники загружаться не будут; за ней последует 32.1 с тем же содержимым плюс дополнительные исправления. Pull request, завершивший 32.1, влитый во второй половине того же дня, бэкпортирует ровно три изменения Antoine Poinsot: единообразное отслеживание исключений сокетов в бэкендах poll и select, 20-минутный таймаут для пиров, чей буфер отправки никак не опустошается, и 64-битные позиции в файлах блоков и undo-файлах. Это и есть исправления трёх уязвимостей, раскрытых двумя днями позже и описанных в разделе 3. Больше о причинах проект ничего не сообщал.

2. Когда вышел релиз? Ключевые даты

Даты взяты из issue с расписанием релизов Bitcoin Core, с сервера загрузок bitcoincore.org и из постов с раскрытием уязвимостей. Статус на 1 ноября 2026 г..

3. Какие уязвимости исправлены и раскрыты?

Три, все опубликованы 28 октября 2026 года и все найдены одним путём: автоматическим сканированием кода большой языковой моделью, которое Elias Rohrer из Spiral ведёт под названием Project Loupe, при этом Gregory Sanders проверял каждую находку и сообщал о ней команде безопасности Bitcoin Core. Две из них независимо переоткрыли другие исследователи до выхода исправлений. Политика Bitcoin Core состоит в том, чтобы раскрывать ошибки, которые проект считает легко обнаружимыми, как только исправленные релизы существуют для каждой поддерживаемой ветки, поэтому разборы вышли на следующий день после 32.1.

CVE-2026-117349, средняя опасность: пир, который заявляет, что не поддерживает ping по BIP 31, никогда не отключается за их игнорирование, и если он к тому же очень медленно читает сообщения, нода без ограничений продолжает ставить в очередь для него анонсы транзакций. Пост оценивает рост примерно до 2 МБ в час для входящего пира и 5 МБ в час для исходящего; ноды с blocksonly подвержены гораздо меньше. Сообщено 15 сентября, исправлено в pull request #36667, который отключает приостановленный пир, не опустошивший буфер отправки за 20 минут.

CVE-2026-117350, средняя опасность, затрагивает только Windows, macOS и BSD: код сокетов на основе select проверял исключительные состояния даже тогда, когда чтение было приостановлено для сдерживания нагрузки (backpressure), поэтому пир, отправляющий срочные данные TCP, мог вынудить чтение в обход лимита памяти на пир, пока у ноды не закончится память. Linux использует poll и не затронут. Сообщено 23 октября, за три дня до слияния исправлений, исправлено в pull request #36665.

CVE-2026-117346, низкая опасность: позиции в файлах блоков и undo-файлах были 32-битными, поэтому, как только undo-файл превышал 4 ГиБ, новые данные перезаписывали старые, а последующая реорганизация цепочки, которой нужны эти данные, останавливала ноду до переиндексации на исправленной версии. В Windows и на 32-битных системах запись отказывает после 2 ГиБ. Пост называет эксплуатацию на 64-битных системах непрактичной: майнеру понадобились бы несколько тысяч блоков с нестандартными транзакциями, примерно месяц блоков, точно размещённых, плюс конкретная реорганизация на два блока. Впервые сообщено 8 июля, исправлено в pull request #36669, который хранит позиции как 64-битные целые без изменения формата на диске; 32-битные системы остаются затронутыми.

В release notes самой 32.1 перечислены и другие исправления, не получившие CVE: повторная попытка приватной трансляции (private broadcast), которая могла раскрыть IP отправителя, обойдя Tor-прокси, путь к выполнению команд через специально составленные имена кошельков при использовании walletnotify на системах, отличных от Windows, и лимиты в 10 000 транзакций в очереди приватной трансляции и 1 000 попыток отправки на каждую. В заметках также сказано, что через две недели проект раскроет три уязвимости средней и высокой опасности, исправленные в 30.0 (и ни одной низкой опасности в 32.1), так что ещё один пост с раскрытием ожидается около 10 ноября.

4. Как новый оценщик комиссий меняет комиссии, которые вы платите?

Если вы пользуетесь кошельком или сервисом, который запрашивает комиссию у ноды Bitcoin Core через estimatesmartfee, 32.1 меняет то, что он получает в ответ. До сих пор Core использовал только оценщик block policy, который смотрит назад, на ставки транзакций, подтверждённых в пределах целевого числа блоков. Он консервативен и медленно снижает оценку: после всплеска загруженности он ещё какое-то время предлагает высокие ставки, потому что история всё ещё говорит «высоко». 32.1 добавляет оценщик mempool policy, который смотрит на то, что ждёт в очереди прямо сейчас, и estimatesmartfee возвращает меньшее из двух. Оценщик по mempool может только снизить результат, но не повысить его, так что кошелёк на базе Core перестаёт переплачивать раньше, как только блоки разгружаются, и ведёт себя как раньше, когда mempool заполнен.

Та же идея лежит в основе ставок, которые показывает большинство обозревателей. На 1 ноября 2026 г. mempool.space, который оценивает только по mempool, даёт для цели в полчаса 1 sat/vB, то есть $0.11 за типичный перевод при цене BTC 77 731 $:

Комиссии Bitcoin прямо сейчас (mempool.space)

Для разработчиков RPC получает объект с опциями: fee_rate_estimator принимает auto (по умолчанию, комбинированный), block_policy (старое поведение) или mempool_policy, неизвестные значения отклоняются, verbosity 2 добавляет mempool_health_statistics, а в режиме auto ответ указывает, какой оценщик был использован. Данные block policy переезжают в fees/block_policy_estimates.dat и мигрируют при первом запуске. Собственный выбор монет в кошельке использует комбинированную оценку. Чего это не меняет: комиссию по-прежнему выбираете вы, replace-by-fee и child-pays-for-parent по-прежнему спасают транзакцию, которая заплатила слишком мало, а уровни sat/vB в нашем гиде по комиссиям обновляются каждую минуту по данным mempool.

5. Что меняется для операторов нод?

Обновитесь и проверьте, на какой ветке вы находитесь. 29.x достигла конца поддержки 27 октября 2026 года, а 29.5 от 28 октября стала её финальным релизом, так что нода на 29.x больше не получит исправлений; 30.x поддерживается до выхода 33.0, 31.x до 34.0, а 32.x до 35.0. Обновление с версии, снятой с поддержки, напрямую до 32.1 поддерживается, хотя миграция каталога данных может занять время. Поддерживаемые платформы: ядро Linux 3.17 и новее, macOS 14 и новее и Windows 10 версии 1903 и новее.

Два значения по умолчанию меняют нагрузку вашей ноды. maxconnections по умолчанию растёт со 125 до 200, а новая опция inboundrelaypercent (по умолчанию 50) ограничивает долю входящих слотов, отдаваемых пирам, которые ретранслируют транзакции; чтобы сохранить старое поведение, запускайте ноду с maxconnections=125 и inboundrelaypercent=100. Исходящая ретрансляция транзакций теперь ограничена по скорости с общей очередью отложенных транзакций (txsendrate, по умолчанию 14 транзакций в секунду, в 2,5 раза больше для исходящих пиров, плюс лимит трафика 12 МБ за 10 минут). Автоматически создаваемые скрытые сервисы Tor получают защиту на основе proof-of-work, если её поддерживает демон Tor. RPC-сервер больше не использует libevent, а новая опция rpcmaxconnections (по умолчанию 16) ограничивает число одновременных HTTP-клиентов.

Две опции экономят место на диске и время. Индекс транзакций хранит меньше данных: перестроенный txindex занимает меньше половины прежнего места, но экономию вы получите, только удалив indexes/txindex в каталоге данных и перезапустив ноду, а это может занять часы; txospenderindex уменьшается так же. Валидация блоков подгружает предыдущие выходы параллельно через prevoutfetchthreads: по умолчанию 8, максимум 16, 0 отключает. Устаревшие сессии ElGamal в I2P будут удалены к v34, а поддержка CJDNS пересматривается, так что операторам, которые полагаются на то или другое, стоит следить за следующими release notes.

6. Что меняется для разработчиков и кошельков?

Несовместимое изменение: PSBT версии 2. createpsbt, walletcreatefundedpsbt, converttopsbt и psbtbumpfee теперь по умолчанию создают PSBT версии 2; новый аргумент psbt_version выбирает версию 0 для инструментов, которые пока не умеют разбирать v2. Если подписывающее устройство, координатор или скрипт в вашем процессе не тестировались с PSBTv2, передавайте этот аргумент до обновления ноды, с которой они работают.

Несколько полей и опций объявлены устаревшими: vsize в RPC mempool и в getrawtransaction (используйте vsize_adjusted или vsize_bip141 для сырого размера по BIP 141), опция запуска walletrbf и ключ bip125-replaceable (ноды ретранслируют замены любой транзакции начиная с Core 28), а также RPC removeprunedfunds, которому теперь нужен deprecatedrpc=removeprunedfunds. Имена кошельков с элементами пути из точек или кошелёк, названный одной косой чертой, отклоняются.

Новое в наборе RPC: exportwatchonlywallet, addhdkey и derivehdkey; send и sendall больше не помечены как экспериментальные; getblockchaininfo сообщает прогресс фоновой валидации assumeutxo; getbalances получает баланс nonmempool; getnetworkinfo сообщает версию asmap; exportasmap и getopenrpcinfo; команда bitcoin-util getchainparams. Собственный HTTP-сервер строже относится к заголовкам, так что проверьте клиентов, которые отправляют необычные заголовки. Ничего из этого не затрагивает то, как транзакция собирается и транслируется, так что SDK, которые общаются с нодой по стандартному RPC, включая ChainGate, продолжают работать.

7. Нужно ли что-то делать пользователям Bitcoin?

Нет. 32.1 не меняет правил консенсуса, так что нет ни форка, ни новой монеты, ни миграции; ваши ключи, адреса и балансы остаются прежними. Если вы пользуетесь лёгким кошельком или держите монеты на бирже, обновление происходит на чужих машинах.

Заметить вы можете одно: кошелёк, подключённый к ноде Core, в часы после высокой нагрузки предлагает более низкие комиссии, поскольку оценщик теперь читает mempool. Если у вас своя нода, обновитесь; если вы на 29.x, то с 27 октября находитесь на ветке без поддержки. Любой, кто говорит вам перевести или «обновить» биткоины из-за релиза Core, занимается мошенничеством.

8. Что подтверждено, а что ещё открыто?

9. Что дальше?

Следующий пункт с датой: раскрытие трёх уязвимостей, исправленных в 30.0, которое release notes обещают через две недели после релиза, то есть около 10 ноября 2026 года. Мы добавим его сюда вместе с любым корректирующим релизом 32.x. Журнал обновлений ниже фиксирует, что и когда изменилось.

А пока гид по комиссиям Bitcoin показывает live-уровни sat/vB, которые догоняет новый оценщик, руководство по хешу транзакции объясняет, как следить за транзакцией в очереди, а материал о закрытии Binance Pool рассказывает, что будет с зависшими транзакциями, когда этот ускоритель закроется 10 ноября.

Обновления этой статьи

• 31 октября 2026: первая публикация. Даты взяты из issue с расписанием релизов Bitcoin Core, с сервера загрузок и страниц релизов bitcoincore.org; детали уязвимостей из трёх постов с раскрытием от 28 октября; состав релиза из release notes 32.1 и страницы жизненного цикла.

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