Bitcoin Core исправляет ошибку bitcoin-cli с неограниченным таймаутом на macOS
Публикация источника: 2026-10-07 · Редакционный анализ опубликован: 2026-10-07
PR №36340 принят 7 октября. Он ограничивает ожидание сокета для -rpcclienttimeout=0; наличие исправления в готовом релизе или стабильной ветке нужно проверять отдельно.
Анализ и практические выводы
В этом разделе — наш анализ и условные расчёты, отдельно от сообщения источника.
Сегодняшнее слияние устраняет операционную проблему на стороне клиента
Объединенный запрос на вытягивание Bitcoin Core № 36340 от 7 октября в 07:27:37 UTC, согласно официальному API GitHub. Изменение устраняет сбой соединения с macOS, связанный с bitcoin-cli с -rpcclienttimeout=0. Мы проверили текущее состояние API и изменили файлы, поскольку кэшированная веб-страница по-прежнему имела более старый статус открытия. Объединенное изменение разработки является подтвержденным событием. Он не устанавливает, что конкретный пакетный выпуск, репозиторий операционной системы или прошивка майнера уже содержат исправления.
Для инфраструктуры майнинга важным является клиент командной строки, используемый для связи с узлом. Неудачная команда может нарушить мониторинг или административный рабочий процесс, даже когда сам узел работает. Наша интерпретация заключается в том, что эта новость относится к надежности программного обеспечения, а ее сфера не связана с производительностью майнинга. Это не новый режим настройки ASIC, изменение алгоритма доказательства работы или заявление о том, что устройства будут отправлять больше принятых хэшей после установки. Затронутый компонент и фактический путь к коду должны оставаться явными.
Ноль на одном уровне может стать большим числом на другом.
В запросе на включение объясняется, что документированная настройка клиента без тайм-аута внутренне представлена очень большой продолжительностью. Затем это значение достигает реализации сокета-ожидания. Наш анализ заключается в том, что это граница между опцией, ориентированной на пользователя, и примитивом операционной системы, который ее реализует. Опция, описанная как неограниченная, все же может быть переведена в конечное значение с помощью программного обеспечения. Если API нижнего уровня не может принять это значение, команда может завершиться неудачно по причинам, которые не очевидны из видимого имени параметра.
Это различие помогает объяснить, почему ошибка соединения не всегда доказывает, что узел находится в автономном режиме или его учетные данные неверны. Программа может отклонить локальный параметр до завершения ожидаемого обмена. При интерпретации ошибки операторам следует различать разрешение имен, установление соединения, аутентификацию, обработку запроса и ожидание ответа. Это общие диагностические границы, а не отчет о том, что все они дефектны в Bitcoin Core. Здесь источник определяет слишком большое значение ожидания, поэтому анализ остается сосредоточенным на этом механизме.
Последний патч ограничивает основное ожидание
Текущее свидетельство об изменении файла показывает ограничение, примененное в Sock::WaitMany, и функциональную проверку для опции клиента с нулевым тайм-аутом. В коде используется максимальное значение Signed-Int в миллисекундах, примерно 24,8 дня, для отдельного ограниченного ожидания. Это не следует переписывать как недавно реализованное встроенное бесконечное ожидание. Ранее при обсуждении рассматривался отдельный подход, но проверенное окончательное изменение сохраняет ограничение. Наше освещение следует фактическому объединенному коду, а не промежуточному предложению в разговоре.
Преобразование единиц измерения важно: миллисекунды и секунды различаются в 1000 раз. Значение тайм-аута, передаваемое через несколько уровней, может иметь разные ограничения в зависимости от представления, которое принимает каждый уровень. Это проблема программного интерфейса, а не расчета электроэнергии или хешрейта сети. Наша интерпретация заключается в том, что использование представимой продолжительности предотвращает немедленный сбой, указанный в отчете, оставляя при этом более широкую семантику тайм-аута в качестве отдельной темы. Читатели не должны делать вывод о неограниченной гарантии эксплуатации на основе приблизительной длины колпачка.
Статус репозитория и выпущенное ПО — это отдельные факты.
При слиянии регистрируется, что репозиторий разработки принял изменение. Распространение среди пользователей может осуществляться через выпуск, перенос исправления в стабильную ветку или обновление пакета, каждое из которых имеет свои собственные сроки. Наш анализ не относит исправление к пронумерованному загружаемому выпуску без проверки его содержимого. Основной API предоставляет фиксацию слияния, которую можно использовать для отслеживания изменений. Пользователь, принимающий решение об обновлении, должен сравнить фактическую установленную версию и соответствующую информацию о выпуске, а не полагаться только на дату этой статьи.
Это различие особенно полезно для инфраструктуры, которая намеренно остается в стабильной ветке. Исправление в ветке разработки не означает, что изменились все стабильные пакеты. Ярлык или обсуждение бэкпорта также не доказывают, что бэкпорт был объединен и отправлен. Поэтому в нашем освещении запланированное последующее наблюдение рассматривается отдельно от подтвержденного включения. Следующим полезным свидетельством является соответствующая документация о фиксации или выпуске ветки, с четким указанием того, какая сборка понадобится оператору для получения исправления.
Соответствующее более раннее исправление касалось другой части клиента.
ASIC.tools ранее рассматривал изменения в пустых ответах и обработке тайм-аута клиента RPC в другом pull request. Новый элемент представляет собой отдельную объединенную коррекцию большого значения, переданного в ожидание сокета, а не повторную копию этого более раннего события. Мы считаем, что эти два уровня могут влиять на один и тот же рабочий процесс пользователя, обращаясь к разным механизмам. Запись запроса на включение и даты слияния позволяет идентифицировать новую разработку и позволяет избежать представления старых примечаний к выпуску как свежего объявления.
Для сопровождающих такое разделение делает отчет о регрессии более точным. Признак, который сохраняется после одного обновления, может потребовать проверки реализации ожидания нижнего уровня, а не предположения, что предыдущее исправление никогда не устанавливалось. Это также позволяет избежать приписывания каждой ошибки на стороне клиента одному патчу. Практический обзор посвящен ошибке, предоставленной опции, операционной системе и точному двоичному файлу. Эти детали более информативны, чем общее заявление о том, что RPC был исправлен, что может подразумевать более широкую область применения, чем фактически имеет любое отдельное изменение.
Локальная проверка должна установить поведение без изменения настроек майнинга.
Для оператора, затронутого этой проблемой, контролируемый клиентский запрос только для чтения может помочь отличить сбой локального клиента от проблемы узла. Точный тест должен соответствовать установленной версии и авторизованной конфигурации узла. Наш анализ предпочитает фиксировать результат команды, версию клиента и наблюдаемую ошибку перед изменением несвязанных настроек. Тест подключения не требует изменения кошелька, конечной точки пула, частоты устройства или конфигурации охлаждения, и это изменение кода не свидетельствует о том, что эти изменения позволят устранить выявленную границу тайм-аута.
Успешный короткий запрос показывает, что конкретный обмен завершился в проверенных условиях. Это не доказывает, что каждый долго выполняющийся запрос будет оставаться работоспособным бесконечно. Мониторинг должен по-прежнему фиксировать прерывания и поведение при восстановлении. Это независимые эксплуатационные соображения, а не заявления о тестировании, проведенном ASIC.tools на всех поддерживаемых платформах. Мы проверили исходный код и окончательный результат; мы не воспроизвели ошибку во всех выпусках macOS и не опубликовали независимо сертифицированную матрицу совместимости.
Увеличение количества повторных попыток может скрыть причину сбоя запроса.
Система автоматизации может повторить неудавшийся запрос, но повторная попытка не заменяет идентификацию уровня ошибки. Повторная отправка одного и того же локально недопустимого параметра ожидания может привести к повторным сбоям. Наша интерпретация заключается в том, что оператору следует отличать сбои до того, как запрос будет принят, от неопределенных результатов после подачи. Это различие имеет значение, выходящее за рамки этой конкретной ошибки, поскольку некоторые административные вызовы RPC меняют состояние, а другие только читают его. Неопределенный результат должен быть согласован перед повторением действия по изменению состояния.
В этой статье не утверждается, что объединенная коррекция тайм-аута меняет политику транзакций или делает каждый вызов RPC безопасным для повторения. Он касается одного поведения соединения. Общий урок эксплуатации заключается в том, чтобы зарегистрировать достаточно информации, чтобы решить, достиг ли запрос сервера и известен ли его результат. Диагностика, доступная только для чтения, может предоставить доказательства без выполнения дублирующих операций. Сохранение такой дисциплины в инструментах мониторинга и администрирования делает небольшое исправление надежности клиента более полезным, чем рассмотрение его как повода для увеличения количества повторных попыток без расследования.
Что изменится для читателей ASIC.tools
Подтвержденное обновление представляет собой объединенное исправление на стороне клиента, поддерживаемое API официального репозитория и проверяющее измененные файлы. Его дата — это сегодняшняя дата слияния, отличная от более старой даты, когда был открыт запрос на включение. На основании этой новости ни один двоичный файл ASIC не был переназначен. Источник Bitcoin Core доступен для читателей, которые хотят проверить окончательное изменение, а сохраненная запись исследования включает в себя доказательства API, используемые для устранения устаревшего статуса, отображаемого на веб-странице.
Практический вывод — при расследовании сбоя мониторинга следует разделять поведение клиента, состояние узла и конфигурацию майнинг-устройства. Операторы, сталкивающиеся именно с этой проблемой с опцией macOS, могут просмотреть данные выпуска или переноса исправления в стабильную ветку, прежде чем выбирать обновление, а затем проверить поведение фактического установленного двоичного файла. В статье избегаются обещания увеличения хэшрейта или заявления о том, что слияние разработки уже реализовано. Его фотографии представляют собой контекстные иллюстрации вычислений и инфраструктуры, а не скриншоты, предлагаемые в качестве доказательства поведения исправленного программного обеспечения.
Источник: Bitcoin Core / GitHub ↗
Калькулятор майнинга ↗
