Виправлення приватної трансляції Bitcoin Core для 31.x отримало новий відгук
Публікація джерела: 2026-10-09 · Редакційний аналіз опубліковано: 2026-10-11
9 жовтня рецензент підтвердив перевірку виправлення private broadcast для Bitcoin Core 31.x. На момент перевірки пропозицію ще не об’єднано: схвалення коду, його включення до гілки та стабільний випуск — окремі етапи.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Новий відгук щодо перенесення виправлення
9 жовтня davidgumberg залишив ACK для коміту 22ac577 у pull request Bitcoin Core №36358. Пропозиція призначена для гілки 31.x; під час перевірки 11 жовтня вона залишалася відкритою з цільовим випуском 31.2. Виправлення відокремлює з’єднання private broadcast від звичайного механізму обмеження взаємодії з вузлами, зберігаючи від’єднання вузлів, які порушують правила. ACK не означає об’єднання коду, а цільова версія не визначає дату релізу.
Оновлення стосується операторів, які свідомо використовують експериментальну функцію приватного поширення транзакцій. Новою подією тут є відгук рецензента; попередня історія розробки наведена для контексту. Це не нова прошивка ASIC і не твердження про проблему кожного вузла за стандартних налаштувань. Каталог обладнання та архів прошивок виробників відокремлені від програмного забезпечення Bitcoin Core.
У яких гілках код уже є
Початкове виправлення №36312 включили до основної гілки розробки 25 вересня. Пакет перенесень №36300 для 32.x об’єднали 1 жовтня; він містить це виправлення. Ці події підтверджують наявність коду у відповідних гілках. Вони не доводять, що зміна вже потрапила на комп’ютер із попереднім стабільним виконуваним файлом або що новий остаточний випуск десь установлено.
Номер версії потрібно пов’язувати з конкретним виконуваним файлом і його походженням. В одній гілці виправлення може бути, а в пакеті з іншої — ще ні. Постачальник пакета також може перенести зміну без такого самого номера upstream-релізу. Тому слід зберігати джерело пакета й точну інформацію про збірку, а не оцінювати захист лише за найвищим номером версії в заголовку.
Функцію вмикають окремо
Примітки до 31.0 описують private broadcast як опцію для транзакцій, поданих через sendrawtransaction, із виділеними з’єднаннями через мережі приватності. Зміна документації №36309 уточнює межі тверджень про приватність і позначає функцію як експериментальну. За замовчуванням її вимкнено. Йдеться про окремий необов’язковий шлях трансляції, а не всі звичайні з’єднання чи кожну транзакцію вузла.
Майнінговій компанії спочатку потрібно з’ясувати, чи її програми справді використовують цей шлях. З’єднання ASIC із пулом і трансляція транзакції гаманця вузлом Bitcoin Core — різні служби. Перелік компонентів і залежностей допомагає не змінювати налаштування майнера через патч для іншої системи. Повідомлення не встановлює дефект мережевого інтерфейсу Antminer або WhatsMiner.
Що може побачити зовнішній спостерігач
Опис патча вказує на ефект обробки з’єднань, помітний ззовні. З’єднання приватної трансляції відокремлюють від звичайного механізму discouragement; вузли private broadcast, що порушують правила, все одно від’єднують. За нашою інтерпретацією, це зменшує можливий сигнал для зіставлення з’єднань. Зміна не обіцяє повну невідстежуваність вузла, гаманця чи людини за будь-яких мережевих умов.
Для пояснення межі системи варто запитати, які зовнішні дії спільні для окремого і звичайного процесів. Якщо рішення в одному процесі змінює поведінку іншого, спостерігач може виявити небажаний зв’язок. Це редакційне пояснення, а не новий тест вразливості. Ми не вимірювали експлуатацію проблеми в робочій мережі й не оцінювали вузли читачів.
Відмінність від попереднього виправлення 31.1
Офіційні примітки до Bitcoin Core 31.1 описують ранішу зміну маршрутизації private broadcast: використання налаштованого проксі під час повторного підключення. Та проблема і поточна пропозиція щодо обробки вузлів стосуються різних механізмів. Під час перевірки офіційна сторінка завантаження вказувала 31.1 як останню стабільну версію. Це не доводить, що відкрита пропозиція для 31.x уже ввійшла до неї.
У журналі обслуговування кожну проблему варто зіставляти з пакетом, який справді містить її виправлення. Кілька заголовків про приватність не означають один патч: попередня зміна могла усунути інший механізм. Зберігайте посилання на розробників і дати перевірок. Обговорення майбутнього випуску в репозиторії не замінює підтверджених приміток до встановленого виконуваного файлу.
Оновлення починається з обліку компонентів
Перед оновленням вузла збережіть точну версію, джерело пакета, налаштування та перелік залежних служб. Для пулу чи робочого гаманця також потрібні шлях подання транзакцій і автоматизація, яка очікує певної поведінки RPC. Це дозволяє визначити, чи конкретна зміна upstream впливає на систему. Загальний процес оновлення прошивки майнера не слід механічно переносити на вузол із іншими вимогами до даних і доступності.
План перевірки може охоплювати запуск служби, синхронізацію, необхідні RPC-виклики та поведінку трансляції в належному тестовому середовищі до виробничого вікна. Результати й план відновлення конфігурації та даних слід зберегти. Це редакційні поради з експлуатації, а не нові інструкції проєкту або рекомендація встановлювати неперевірену гілку. Тестовий кандидат і стабільний пакет мають залишатися різними варіантами.
Статус потрібно перевіряти перед використанням
Статус у статті прив’язаний до дати: 11 жовтня пропозиція для 31.x була відкритою. Після публікації це може змінитися. Подальше об’єднання буде новим етапом, але оператору ще потрібно знайти поширювану збірку з виправленням. Якщо обслуговування заплановано на кілька днів пізніше, слід повторно перевірити офіційні записи перед тим, як приписувати зміну встановленій версії.
Умовний приклад: із десяти екземплярів вузла вісім оновлено до перевіреного пакета, а два працюють із попередньою збіркою. Сам анонс релізу не оновлює всі десять. Для кожного екземпляра потрібно перевірити виконуваний файл і результат перезапуску. Це вигадана ілюстрація обліку розгортань, а не статистика поширення Bitcoin Core чи дані дослідженого майнінг-пулу.
Значення для операторів майнінгу
Підтверджена новина — поступ у перевірці перенесення патча; його випуск для стабільної серії ще потребує наступних етапів у перевірених записах. Це не змінює алгоритм Proof of Work Bitcoin, номінальний хешрейт 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 ↗
Калькулятор майнінгу ↗
