Патч private broadcast для Bitcoin Core 31.x получил новый отзыв и ждёт объединения
Публикация источника: 2026-10-09 · Редакционный анализ опубликован: 2026-10-11
9 октября опубликован новый отзыв на патч private broadcast для Bitcoin Core 31.x. При проверке 11 октября предложение оставалось открытым: отзыв, объединение кода и выпуск стабильного пакета — разные этапы.
Анализ и практические выводы
В этом разделе — наш анализ и условные расчёты, отдельно от сообщения источника.
Свежий обзор бэкпорта стабильной серии
9 октября разработчик davidgumberg оставил ACK для коммита 22ac577 в pull request 36358 проекта Bitcoin Core. Предложение предназначено для ветки 31.x и при нашей проверке 11 октября оставалось открытым с привязкой к этапу 31.2, без объявленной даты выпуска. Патч выводит соединения приватной трансляции из обычного механизма discouragement, сохраняя отключение таких узлов при некорректном поведении. Положительный отзыв не означает объединения кода, а номер этапа не является датой релиза.
Это важно для операторов, которые намеренно используют экспериментальную функцию широковещательной передачи транзакций и хотят знать, какой путь к программному обеспечению содержит исправления. В нашем отчете обзор рассматривается как новое событие, а предыдущая история развития рассматривается как контекст. Он не описывает новый файл прошивки ASIC и не утверждает, что изменение затрагивает каждый узел в стандартной конфигурации. Каталог оборудования и архив прошивки производителя отделены от программного обеспечения узла Bitcoin Core.
В каких ветках исправление уже объединено
Исходное изменение, pull request 36312, было добавлено в основную ветку разработки 25 сентября. Пакет резервного порта 32.x, pull request 36300, был объединен 1 октября и включает такое же исправление. Эти события репозитория устанавливают наличие кода в этих ветках. Они не устанавливают, что машина, на которой все еще работает более ранний стабильный двоичный файл, получила изменения или что где-либо была установлена новая финальная версия.
Метка версии должна быть привязана к фактическому исполняемому файлу и его источнику. Ветка может содержать исправление, а опубликованный пакет другой ветки может его ещё не содержать. И наоборот, дистрибьютор может применить перенос исправления, который изменяет код без использования той же метки выпуска исходной версии. Оператору следует сохранять происхождение пакета и точную информацию о сборке, а не рассматривать самый высокий номер версии, указанный в заголовке, как полную оценку безопасности.
Эта функция намеренно необязательна
В более ранних примечаниях к выпуску 31.0 приватная трансляция описывается как опция, влияющая на транзакции, отправляемые через sendrawtransaction, с использованием выделенных соединений через сети конфиденциальности. Отдельное изменение документации, pull request 36309, сужает требования к конфиденциальности и отмечает эту функцию как экспериментальную. По умолчанию он отключен. Эти уточнения актуальны, поскольку сообщаемый исправление касается конкретного необязательного широковещательного пути, а не каждого обычного соединения или каждой транзакции, наблюдаемой узлом.
Для майнингового бизнеса необходимо определить, действительно ли его собственное программное обеспечение передает транзакции по этому пути, прежде чем оценивать их эксплуатационную значимость. ASIC, взаимодействующий с пулом, — это не тот же сервис, что узел Bitcoin Core, транслирующий транзакцию кошелька. Перечисление служб и их зависимостей помогает избежать изменения конфигурации майнинга в ответ на исправление, принадлежащее другому компоненту. Заголовок не указывает на дефект сетевого интерфейса Antminer или WhatsMiner.
Наблюдаемая обработка соединений — это граница конфиденциальности
Описание патча указывает на поведение соединений, которое можно наблюдать извне. Предлагаемое изменение отделяет узлы приватной трансляции от обычного механизма discouragement, сохраняя отключение приватных узлов при некорректном поведении. По нашей интерпретации, это уменьшает возможный сигнал для сопоставления соединений. Исправление не обещает, что узел, кошелёк или человек станут неотслеживаемыми при любых сетевых условиях.
В качестве редакционного способа рассуждать о проблеме спросите, какие внешне видимые действия являются общими для предположительно отдельного рабочего процесса и обычного рабочего процесса. Если решение по одному пути меняет поведение другого, наблюдатель может узнать взаимосвязь, которую оператор не намеревался раскрывать. Это объяснение границ системы, а не новый тест на уязвимость. Мы не измеряли эксплуатацию в действующей сети и не оценивали какой-либо читательский узел.
Не путайте с более ранним исправлениеом 31.1.
Официальные заметки Bitcoin Core 31.1 описывают более раннее восстановление маршрутизации приватного соединения с использованием настроенного прокси-сервера во время повторного подключения. Этот предыдущий вопрос и нынешнее предложение об обработке сетевых узлов касаются разных механизмов. На официальной странице загрузки по-прежнему указана 31.1 как последняя стабильная версия, проверенная нами. Его присутствие является свидетельством доступного выпуска, а не свидетельством того, что открытое в настоящее время предложение 31.x уже включено в него.
Записи об обслуживании должны сопоставлять каждую соответствующую проблему с версией или пакетом, который фактически содержит ее исправление. Объединение нескольких заголовков, связанных с конфиденциальностью, в одно предполагаемое исправление может заставить оператора поверить в то, что более поздняя проблема решена, хотя была решена только предыдущая. Сохраняйте ссылки на исходный проект и даты просмотра в записи изменений. Обсуждение в репозитории будущей версии обслуживания не может заменить проверенное примечание к выпуску используемого двоичного файла.
Контролируемое обновление начинается с инвентаризации
Прежде чем планировать обновление узла, сохраните точную версию, источник пакета, соответствующую конфигурацию и службы, которые зависят от узла. Для пула или бизнес-кошелька укажите путь отправки транзакции и любую автоматизацию, ожидающую определенного поведения RPC. Эта инвентаризация позволяет решить, влияет ли конкретное изменение в исходной версии на установленную систему. Это также предотвращает применение общего процесса обслуживания встроенного ПО к программному обеспечению узла с различными требованиями к данным и доступности.
Практичный план проверки проверяет запуск службы, состояние синхронизации, необходимые вызовы RPC и поведение широковещательной передачи транзакций в соответствующей тестовой среде перед рабочим окном. Запишите результат и сохраните план восстановления соответствующей конфигурации и данных. Это редакционные рекомендации, а не инструкции по выпуску нового проекта или рекомендации по установке непроверенной ветки. Тестируемый кандидат и стабильный производственный пакет должны оставаться явно разными вариантами.
Статус выпуска необходимо проверять в момент использования.
Записанный статус представляет собой датированный снимок: предложение 31.x было открытым на момент рассмотрения 11 октября. Оно может измениться после публикации. Более позднее слияние станет еще одной важной вехой, но операторам все равно придется идентифицировать распределенную сборку, содержащую ее. Это различие имеет значение, когда окно обслуживания планируется через несколько дней после прочтения новости. Перепроверьте официальные записи проекта, прежде чем приписывать исправление установленной версии.
Независимый пример — парк из десяти экземпляров узлов, восемь из которых обновлены до проверенного пакета, а два остаются в более ранней сборке. Одно только объявление о выпуске не делает все десять обновленными. Отслеживайте фактический исполняемый файл и результат перезапуска для каждого экземпляра, а не конвертируйте доступность программного обеспечения в количество развертываний. Пример гипотетический; он не описывает уровень внедрения Bitcoin Core или исследуемый пул майнинга.
Что майнерам стоит взять из обновления
Непосредственной новостью является прогресс в проверке переноса исправления, при этом поставка стабильной серии все еще ожидает дальнейших шагов в проверенных записях. Это не меняет алгоритм доказательства работы Биткойна, номинальную скорость ASIC или потребление электроэнергии фермой. Полезным оперативным ответом является определение затронутой дополнительной службы и следование официальному пути выпуска, сохраняя разницу между проверкой кода, слиянием, упаковкой и установкой.
Две лицензированные архивные сетевые фотографии иллюстрируют сетевой контекст. На них не изображена атака, тестовая система разработчика или майнинговая компания, затронутая проблемой. Ниже приведены ссылки на первоисточник и подтверждающие записи проекта с указанием их дат. В этой статье сообщается о конкретном текущем событии проверки и объясняются его эксплуатационные ограничения; он не называет будущий выпуск доступным для загрузки и не устанавливает крайний срок для этапа 31.2.
Источник: Bitcoin Core / GitHub ↗ · Original private-broadcast patch ↗ · 32.x backport bundle ↗ · Experimental feature and qualified privacy claims ↗ · Official Bitcoin Core 31.0 notes ↗ · Official Bitcoin Core 31.1 notes ↗ · Current official stable download ↗
Калькулятор майнинга ↗
