Bitcoin Core виправляє помилку bitcoin-cli з необмеженим таймаутом на macOS
Публікація джерела: 2026-10-07 · Редакційний аналіз опубліковано: 2026-10-07
PR №36340 прийнято 7 жовтня. Виправлення обмежує очікування сокета для -rpcclienttimeout=0; наявність у готовому релізі чи стабільній гілці потрібно перевіряти окремо.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Сьогоднішня зміна стосується клієнта
Bitcoin Core прийняв pull request №36340 7 жовтня о 07:27:37 UTC — це підтверджує офіційний GitHub API. Зміна виправляє помилку підключення bitcoin-cli на macOS із параметром -rpcclienttimeout=0. Ми перевірили актуальний стан API та остаточні змінені файли, оскільки кешована вебсторінка ще показувала відкритий запит. Підтверджена подія — прийняття коду в гілку розробки. Це не підтверджує наявність виправлення в конкретному готовому пакеті чи прошивці майнера.
Для інфраструктури майнінгу важливий клієнт командного рядка, який звертається до вузла. Невдала команда може порушити моніторинг або адміністративний процес, навіть якщо сам вузол працює. Ми розглядаємо новину як виправлення надійності програмного забезпечення. Це не новий режим налаштування ASIC, не зміна proof-of-work і не обіцянка зростання прийнятого хешрейту. Важливо зберігати точний опис компонента та шляху виконання, якого стосується зміна.
Нуль у налаштуванні перетворюється на велику тривалість
Автор запиту пояснює: клієнт представляє задокументоване налаштування без таймауту як дуже довгу тривалість, що передається реалізації очікування сокета. Це межа між користувацькою опцією та механізмом операційної системи. Позначення «без обмеження» не означає, що програма передає нескінченне очікування на кожному рівні. Якщо нижчий API не підтримує числове значення, команда може завершитися помилкою, причина якої неочевидна з назви параметра.
Тому повідомлення про помилку підключення не завжди доводить вимкнення вузла або неправильний пароль. Програма може відхилити локальний параметр до завершення очікуваного обміну. Під час діагностики слід розрізняти визначення адреси, встановлення з’єднання, автентифікацію, обробку запиту й очікування відповіді. Це загальні етапи перевірки, а не перелік дефектів Bitcoin Core. У цьому випадку першоджерело вказує на завелику тривалість очікування.
Остаточний код обмежує очікування сокета
Перевірений остаточний перелік змін показує обмеження в Sock::WaitMany і функціональну перевірку параметра нульового таймауту. Для окремого очікування використовується максимальне значення знакового int у мілісекундах — приблизно 24,8 дня. Це не слід описувати як нове нативне нескінченне очікування. В обговоренні розглядали інший підхід, але прийнята зміна залишає обмеження. Наш матеріал спирається на остаточний код, а не проміжну пропозицію.
Мілісекунди та секунди відрізняються у 1000 разів. Значення, яке проходить через кілька програмних рівнів, може стикатися з різними обмеженнями типів. Це питання програмного інтерфейсу, а не електроенергії чи хешрейту. На нашу думку, підтримувана числова тривалість усуває описану негайну помилку, тоді як загальна семантика таймаутів залишається окремим питанням. Приблизна величина обмеження не є гарантією необмеженої роботи з’єднання.
Прийнятий код і випущений пакет — різні етапи
Прийняття зміни підтверджує її наявність у репозиторії розробки. До користувачів вона може потрапити через реліз, перенесення у стабільну гілку або оновлення пакета — із власними строками. Ми не приписуємо виправлення конкретному завантажуваному релізу без перевірки складу. API містить commit прийняття, за яким можна відстежити код. Перед оновленням потрібно звірити встановлену версію та відповідні примітки до релізу, а не покладатися лише на дату статті.
Це особливо важливо для інфраструктури, що свідомо залишається на стабільній гілці. Зміна в розробці не оновлює автоматично всі стабільні пакети. Позначка про необхідність перенесення чи обговорення також не підтверджують завершеного перенесення та випуску. Наступним корисним доказом буде commit відповідної гілки або документація релізу з чітким зазначенням збірки, у якій користувач отримає виправлення.
Попереднє виправлення стосувалося іншого рівня
ASIC.tools раніше писав про виправлення порожніх відповідей і обробки таймауту клієнта в іншому pull request. Сьогоднішня зміна окремо виправляє велике значення, передане очікуванню сокета, тому не дублює попередню подію. Два рівні можуть впливати на той самий робочий процес, але мати різні механізми. Номер запиту й дата прийняття дозволяють однозначно ідентифікувати новину та не видавати стару примітку за новий анонс.
Якщо симптом зберігається після одного оновлення, варто перевірити нижчий рівень очікування, а не відразу припускати відсутність попередньої зміни. Не слід також приписувати всі помилки клієнта одному виправленню. Практична перевірка враховує текст помилки, параметри, операційну систему й конкретний виконуваний файл. Це точніше за загальну фразу «RPC виправлено», яка може створити враження значно ширшого обсягу змін.
Перевірка підключення без зміни майнінгу
Для користувача з цією помилкою контрольний запит лише на читання допоможе відділити збій клієнта від проблеми вузла. Перевірка має відповідати встановленій версії та дозволеній конфігурації вузла. Варто зафіксувати результат, версію клієнта й текст помилки до зміни сторонніх налаштувань. Для перевірки підключення не потрібно змінювати гаманець, адресу пулу, частоту ASIC або охолодження. Прийнятий код не дає підстав вважати такі зміни рішенням цієї проблеми.
Успішний короткий запит підтверджує завершення конкретного обміну за перевірених умов. Він не гарантує безперервного виконання будь-якого довгого запиту. Моніторинг має й надалі фіксувати перерви та відновлення. Це наші операційні міркування, а не твердження про випробування ASIC.tools на всіх платформах. Ми перевірили першоджерело й остаточні зміни, але не відтворювали помилку на кожному випуску macOS і не створювали сертифіковану матрицю сумісності.
Повторення запиту не замінює діагностику
Автоматизація може повторити невдалий запит, але це не визначає рівень помилки. Повторне передавання некоректної локальної тривалості може знову завершитися невдачею. Важливо розрізняти збій до приймання запиту та невідомий результат після його надсилання. Частина адміністративних RPC змінює стан, частина тільки читає його. За невідомого результату потрібно спочатку звірити стан, а не автоматично повторювати дію, що може створити дубль.
Ми не стверджуємо, що виправлення змінює політику транзакцій або робить кожен RPC безпечним для повторення. Воно стосується одного механізму підключення. Загальний практичний висновок — журналювати достатньо даних, щоб визначити, чи запит дійшов до сервера та чи відомий результат. Діагностичний запит на читання дає підтвердження без дублювання операцій. Така дисципліна корисніша за безумовне збільшення кількості повторних спроб.
Що підтверджено для читача ASIC.tools
Підтверджена подія — прийняте клієнтське виправлення з доказами офіційного API та остаточних змінених файлів. Дата новини відповідає сьогоднішньому прийняттю, а не старішій даті відкриття pull request. На цій підставі ми не призначали нові прошивки ASIC. Посилання веде на репозиторій Bitcoin Core, а журнал дослідження містить API-доказ, використаний для уточнення застарілого стану кешованої вебсторінки.
Практичний висновок — окремо перевіряти поведінку клієнта, стан вузла та конфігурацію майнера. Користувачам macOS із цією конкретною помилкою варто стежити за включенням зміни в реліз або стабільну гілку й перевіряти встановлений файл після оновлення. Стаття не обіцяє зростання хешрейту та не видає прийнятий код за вже випущений пакет. Фото є тематичними ілюстраціями обчислень та інфраструктури, а не доказом роботи виправленого програмного забезпечення.
Джерело: Bitcoin Core / GitHub ↗
Калькулятор майнінгу ↗
