Bitcoin Core виправив некоректні default у своєму OpenRPC-описі
Публікація джерела: 2026-09-19 · Редакційний аналіз опубліковано: 2026-09-21
Merged PR #36297 змінює два записи OpenRPC metadata, щоб generated clients отримували schema-valid defaults. Це зміна development tree, а не новий stable release чи зміна mining consensus.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Що змінилося
Bitcoin Core 19 вересня 2026 року merged pull request #36297. Patch виправляє два default, які повертає getopenrpcinfo. Необов’язковий аргумент getdeploymentinfo.blockhash тепер має DefaultHint, бо його fallback описано як current chain tip, а не як literal hash. Deprecated send.options.include_watching представлено boolean false замість рядка "false". Зміна коду мала, але важлива для інструментів, що сприймають OpenRPC як machine-readable schema.
Чому hint не є значенням
Schema default має бути фактичним значенням, яке відповідає declared type і може бути передане методу. Фраза "hash of current chain tip" пояснює runtime behaviour, але не є hexadecimal block hash. Позначення DefaultHint зберігає корисну документацію без твердження, що описовий текст — valid argument. Це робить contract яснішим для code generators, validators і documentation tools, яким раніше доводилося ігнорувати або окремо обробляти некоректний default.
Навіщо потрібен boolean false
Поле include_watching оголошено boolean. Запис default як тексту "false" створює type mismatch, хоча людині зміст зрозумілий. Patch використовує справжній boolean. Строгий OpenRPC consumer може відхилити документ, згенерувати string-valued option або провалити schema tests. Правильна metadata зменшує такі integration errors. Вона не змінює documented fact, що deprecated option більше не використовується RPC send.
Зв’язок із майнінгом
Pool software, payout systems, treasury automation і node monitoring часто працюють через обгортку Bitcoin Core RPC. OpenRPC може створювати typed clients, test fixtures та operator documentation для control plane. Чиста schema допомагає automation помічати справжні interface changes замість падіння на власних generated types. Patch не змінює proof of work, block templates, share difficulty, network difficulty, coinbase construction чи ASIC behaviour, тому це не зміна хешрейту або виплат.
Статус розгортання
Pull request merged у development repository Bitcoin Core. Це не доказ, що кожний public binary або запущена node вже містить зміну. Оператор має визначити фактичний release і прочитати його notes. Backport, склад release candidate і packaging дистрибутива — окремі рішення. Постачальнику software не варто заявляти підтримку лише за датою merge; треба протестувати getopenrpcinfo на точному Bitcoin Core build, який входить у продукт.
Як тестувати інтеграцію
Збережіть getopenrpcinfo з current production version і candidate build. Перевірте обидва документи одним OpenRPC validator, згенеруйте client у тимчасовому namespace та перегляньте diff. Підтвердьте, що blockhash лишається optional, а fallback задокументовано як current tip. Перевірте boolean type include_watching і відсутність string у request. Потім запустіть RPC integration tests. Metadata generation не має непомітно змінювати payout або wallet calls.
Дисципліна сумісності
Фіксуйте разом версію Bitcoin Core і generated-client artifact. Зберігайте hash source document, версію generator і code-review diff. Якщо validator після виправлення став строгішим, перевіряйте весь документ, не припускаючи, що інших проблем немає. У mining infrastructure розділяйте read-only credentials для monitoring та wallet/payout credentials, навіть коли clients походять з однієї schema. Краща metadata підвищує коректність, але не замінює authentication boundaries, rate limits і transaction review.
Практичний висновок
PR #36297 — точне metadata correction: описовий fallback стає DefaultHint, а текстовий false — boolean false. Головна користь для розробників, які генерують або перевіряють RPC clients. Зміна зменшує ambiguity і type errors, не зачіпаючи consensus чи mining economics. Наступний крок — перевірити exact build, регенерувати clients у staging і переглянути diff. Джерело не дає підстав терміново змінювати firmware майнерів або обіцяти більше блоків.
Джерело: Bitcoin Core ↗
Калькулятор майнінгу ↗
