Информационный бюллетень Bitcoin Optech № 430

В новостной рассылке на этой неделе подведены итоги продолжающегося обсуждения использования технологии «TCP hole punching» для обеспечения доступности узлов, расположенных за домашними маршрутизаторами, а также описан проект BIP, направленный на стандартизацию политик расходования средств, которые соподписанты применяют при эмуляции ковенантов. Также в выпуске представлены наши регулярные рубрики, в которых подводятся итоги предложений и обсуждений об изменении правил консенсуса в Bitcoin, объявляются новые версии и кандидатские версии, а также описываются значимые изменения в популярном программном обеспечении инфраструктуры Bitcoin.

Новости

● Продолжение обсуждения пробивания дырок в TCP для домашних узлов: Вслед за

нашим майским обзором ветки 0xB10C «Delving Bitcoin», посвящённой использованию «пробивания портов» для того, чтобы узлы, находящиеся за домашними маршрутизаторами, могли принимать соединения друг от друга, 0xB10C сообщил, что работа над спецификацией и экспериментальной реализацией в Bitcoin Core возобновилась. Домашние узлы обычно могут устанавливать только исходящие соединения, и включение сопоставления портов NAT-PMP по умолчанию в Bitcoin Core 30.0 не сделало гораздо больше из них доступными, как надеялись. «Пробивание дыр», при котором два домашних узла открывают соединения друг с другом одновременно, чтобы каждый маршрутизатор пропускал трафик другого, стало бы оптимальным дополнением к перенаправлению портов. Большее количество доступных честных узлов затруднило бы задачу злоумышленникам, узлы которых легче доступны, заполнить слоты исходящих соединений узла.

0xB10C подвёл итоги по четырём рассмотренным до сих пор проектам и предложил новый вариант, не требующий координатора: узел объявляет свой адрес, доступный для «пробивания», и временный открытый ключ в новом типе addr v2, а каждая пара узлов выводит один и тот же список кандидатов и время «пробивания» на основе своего общего секрета и каждого нового блока. В ответ на возражение Энтони Таунса о том, что злоумышленник может затопить схему реальными адресами, а также после того, как позже выяснилось, что недоступные узлы получают такие объявления гораздо менее надёжно, чем прослушивающие узлы, он набросал альтернативный вариант в виде «доски объявлений», в котором прослушивающие узлы хранят проверенные адреса домашних узлов, ищущих партнёра.

Таунс усомнился в том, помогают ли случайные входящие соединения домашним узлам вообще, и утверждал, что пробивание дыр облегчает злоумышленнику прямой доступ к честным узлам, при этом практически не гарантируя соединение с честным узлом. Он подсчитал, что злоумышленник, объявляющий около 10 000 адресов, быстро будет обнаружен большинством честных узлов, и предложил в качестве альтернативы с меньшим риском использовать кратковременные соединения со случайными пирами. Джонатан Харви-Бушель привёл данные, показывающие, что честные узлы менее доступны, чем узлы, контролируемые злоумышленниками, и высказался в пользу координации через собственный Tor-сервис узла. Позже Таунс спросил, не делают ли недавние уязвимости TCP и протоколов отказ от принятия входящих соединений более безопасным вариантом по умолчанию для домашних пользователей. Обсуждение продолжается.

● Проект BIP по стандартизации политик расходования средств соподписантами: Люк Карриер

опубликовал на сайте Delving Bitcoin своё предложение по стандартизации политик расходования средств, применяемых соподписантами при эмуляции соглашений. Несколько недавних проектов, включая проект Йохана Халсета, касающиеся заслепленных соподписантов и делегирования цепочки кода, каждый из которых определяет свою собственную политику, поэтому кошелек, созданный для одного проекта, не может использовать соподписанта или оракул, разработанные для другого. Карриер не просит присвоить этому проекту номер BIP и спросил, является ли это подходящим уровнем для стандартизации.

Проект следует нескольким принципам проектирования:

Всё, что может быть обеспечено с помощью скрипта Bitcoin, должно обеспечиваться именно там, а политики соподписантов должны определять только то, что скрипт не может.

Всегда должен быть доступен

по крайней мере один путь расходования, не требующий соподписанта.

Способ проверки расхода соподписантом и гарантии его честности представляют собой

настраиваемые профили, выбираемые в соответствии с политикой.

Соподписанты должны принимать подтверждения оракулов в формате

DLC, чтобы уже имеющиеся оракулы можно было повторно использовать без каких-либо модификаций.

Политика состоит из пяти частей. Выход определяет дескриптор Taproot, в котором хранятся средства; группа соподписантов группа указывает, какие соподписанты принимают участие и сколько из них должны подписать, шаблоны перечисляют транзакции, которые соподписанты могут подписать с их точными выходами, условия определяют, что должно быть выполнено, прежде чем каждый шаблон сможет быть подписан, а профили определяют режим проверки, форматы доказательств и любую схему подотчётности. Некоторые вопросы остаются открытыми, например, использовать ли JSON или TLV для сериализации, следует ли указывать «слепую» верификацию сейчас или подождать, пока накоплен больший опыт реализации, следует ли указывать формат заверения заявлений в предложении или в спецификациях DLC, и должен ли резервный путь быть заблокирован по времени.

В ходе последовавшей дискуссии PREDGE указала, что в одном из профилей доказательств, называемом `statement-v0`, не имеет флага окончательности, а это означает, что соподписант может действовать на основании предварительного заверения, которое позже будет исправлено. Кроме того, tehiyadu заявил, что хеш политики должен строго соответствовать семантике верификатора, чтобы предотвратить ситуацию, при которой разные реализации принимают одни и те же байты, но при этом применяют разные условия. Carriere согласился с обоими пунктами и сказал, что добавит флаг окончательности и точно определит правила верификатора.

Изменение консенсуса

*Ежемесячный раздел, в котором подводятся итоги предложений и обсуждений об изменении правил консенсуса Биткойна.*

● Продолжение обсуждения BIP54: Антуан Риар (Antoine Riard) опубликовал в

списке рассылки Bitcoin-Dev своё мнение о состоянии дел с софт-форком по очистке консенсуса (BIP54). Запрет на транзакции, размер которых без свидетельства составляет ровно 64 байта, по-прежнему остаётся самым спорным правилом. Реализация в Bitcoin Core находится на стадии рассмотрения и тестирования и является эталонной реализацией, ссылка на которую приведена в BIP (Bitcoin Core #35793). Этот PR включает новые правила в regtest без активации в основной сети. Он также указал на работу по обеспечению взаимодействия в btcd (btcd #2537) и отметил, что ему не известно ни об одной реализации libbitcoin. По его мнению, остаётся провести дополнительную экспертизу и тестирование, подготовить документацию, чтобы кошельки знали о предлагаемом ограничении в 2 500 операций подписи в скрипте до SegWit и о правиле 64 байтов, а уже потом — разработать логику активации. Высказывая исключительно свое личное мнение, он считает, что было бы реалистично начать рассматривать вопрос об активации во второй половине 2027 года, если к тому времени сообщество придет к согласию.

Питер Вуйлле обновил свою ветку в Delving Bitcoin, посвящённую тому, как два правила временных меток BIP54 ограничивают длину цепочки (см. бюллетень № 425). В верхнем посте теперь приведена точная формула для нижней границы работы, и как эта формула, так и десятичное приближение теперь доказаны в приведённом коде Lean.

Риард ответил на возражение, высказанное во время разработки BIP54: что исправление ошибки time warp сделает изменение консенсуса в стиле forward blocks Марка Фриденбаха невозможным на всю оставшуюся историю Биткойна. Поскольку исправление ограничивает манипуляции с временными метками, а не устраняет их, гораздо более ограниченное предложение по «forward blocks» всё ещё может быть реализовано. По его оценкам, оконо 7 200 секунд, которое по-прежнему допускается исправлением, может снизить сложность примерно на 0,60 % за каждый период перенацеливания и повысить скорость формирования блоков примерно на столько же, что значительно меньше увеличения пропускной способности, предусмотренного первоначальным предложением. Риард также утверждал, что эта идея несостоятельна даже при старых правилах: валидаторы будут обрабатывать транзакции один раз в цепочке «forward» и ещё раз, когда они синхронизируются с цепочкой совместимости, за те же комиссии, если только пользователи не заплатят дважды, а узлы, которые не обновились, всё равно будут вынуждены загружать лишние данные. Риард предложит краткую сноску к BIP54, в которой изложит эти аргументы, и попросит Фриденбаха представить контраргументы.

Прототип опции opt-in защиты от повторного воспроизведения : Сьорс Провоост продолжил обсуждение в ветке Delving Bitcoin, посвященной опции «opt-in» защиты от повторного воспроизведения при разделении цепочки (см. бюллетень № 420 ), представив прототип, использующий новую версию свидетеля. Приложение , полезные данные которого начинаются с байта 0x01, указывает блок по 4-байтовой высоте, а каждая подпись на этом входе фиксирует хеш блока в желаемой цепочке. Сам хеш в транзакции отсутствует. Он оценил дополнительные затраты в 1,75 vbytes. Названный блок должен быть не моложе 100 блоков — это тот же горизонт, что и срок действия coinbase. Он отметил, что если хешрейт разделится равномерно, время ожидания до возможности разделения монет составит в худшем случае два дня, поскольку правило должно соблюдаться только на одной стороне. Он предложил выпустить версию witness вместе с другим предложением, которое в ней нуждается, например, CISA (BIP460), BIP360 или выходом в стиле P2TRv2

с ключевым путем, который позже можно будет отключить.

Энтони Таунс ответил, что новая версия witness не нужна, и что достаточно будет нового кодирования открытого ключа для проверки подписи Taproot в стиле BIP118. Провоост ответил, что он рассматривал это кодирование и счёл его «хаком», и что, насколько он понимает, оно не сработает для траты по ключевому пути.

Moonsettler задал вопрос, является ли требование 100 блоков желательным в случае разделения, где эта функция будет иметь наибольшее значение, и предложил оставить эту задержку в качестве правила политики, которое можно будет ослабить. Провоост ответил, что после того, как монеты перейдут на более быструю сторону и наберут подтверждения, более медленная сторона больше не будет нуждаться в защите. Провоост также написал, что ожидает, что правило будет внедрено до спорного хард-форка, чтобы обе стороны унаследовали его, и ни одна из сторон не смогла легко от него отказаться: хеш блока находится только в сообщении подписи, поэтому удаление правила означает изменение сериализации транзакций для передачи хеша.

● QSAVE для неперенесённых монет: Джеймс Тэгг опубликовал в

списке рассылки Bitcoin-Dev пять черновых версий BIP для QSAVE (Quantum Secure Asset Verification and Escrow) — постквантового перехода, не предусматривающего сжигания монет. Он описал их как альтернативу BIP361 и Hourglass. С точки зрения применения, которое может быть активировано в виде мягкого форка в любой момент, любой вход, не входящий в реестр известных постквантовых типов, будет рассматриваться как немигрированный, включая неизвестные и будущие типы скриптов. Немигрированный вход по-прежнему должен будет соответствовать своему скрипту блокировки, а также второму фактору: либо доказу с нулевым разглашением того, что один сед является источником как скрипта траты, так и постквантового ключа, либо постквантовой привязке, зафиксированной до даты отсечения. Если в транзакции присутствует неперенесённый вход, не имеющий этого второго фактора, каждый расходуемый выход должен быть выходом восстановления. В QSAVE нет срока действия, поэтому отсутствие второго фактора не приводит к уничтожению монеты. Доказательство в цепочке может всегда потратить её напрямую, без участия третьей стороны. В противном случае он описал внецепочечный процесс обращения с утраченным имуществом, правовое и экономическое регулирование которого он вынес за пределы консенсуса: в рамках этого процесса группа децентрализованных хранителей будет удерживать выходы восстановления, с резервным хранителем и контролером с правом вето, а средства смогут приносить консервативную доходность в размере 0,5 %, направляемую на благотворительность. В черновиках также указаны водяные знаки до отсечения, опциональный ключ ML-DSA-87, который он назвал QD5, и листья расходования zk-STARK для выходов BIP360 (P2MR) .

● Proof-of-decay для неперемещенных выходов: bitKingAE

опубликовал на сайте Delving Bitcoin эскиз механизма сокращения выходов, уязвимых для постквантовых атак, таких как ранние монеты P2PK, которые не перемещаются в течение льготного периода. По истечении льготного периода стоимость выхода будет снижаться в соответствии с графиком, зависящим от высоты блока. Потерянные сатоши будут сожжены или выплачены в качестве вознаграждения за майнинг, а не заморожены или оставлены тому, кто сможет предоставить подпись. В примере, приведенном в посте, речь шла о небольшом проценте от баланса каждые 50 000 блоков. Винисиус Честари ответил тремя возражениями: квантовый злоумышленник может дождаться окончания льготного периода и снять уязвимые выходы до того, как их стоимость значительно снизится; внезапное усовершенствование квантовых атак может привести к их исчезновению ещё раньше; а такой график уменьшает баланс пассивного владельца, в том числе того, у кого ключи уже были украдены.

● Цензура пакетов BIP300: Ори Ньюман утверждал в

списке рассылки Bitcoin-Dev, что майнер, владеющий 26 % хешрейта, может бесконечно цензурировать действительный пакет вывода средств в предложении о драйвчейнах (BIP300). Он написал, что если майнер с долей 26 % отправляет сигнал ALARM в каждом добытом им блоке, каждый из этих блоков снижает оценку каждого ожидающего пакета на 1. Если остальные 74 % хешрейта будут голосовать «за» пакет в каждом блоке, его ожидаемый балл составит 12 624 в конце окна из 26 300 блоков, что меньше требуемых 13 150. Он предложил запретить ALARM и любые другие голоса «против», что восстановило бы допущение о честном большинстве: пакет, поддержанный 51 % хешрейта, почти наверняка был бы принят, а тот, что поддержан 49 %, почти наверняка был бы отклонен. Если же текущее правило является намеренным, он попросил, чтобы в BIP вместо этого было указано допущение о 75-процентном честном большинстве. Он назвал это значительным отклонением от модели безопасности Биткойна и отметил, что одним из аргументов в его пользу является то, что злоумышленнику, обладающему менее чем 75 % хешрейта, будет сложнее похитить средства.

Релизы и кандидатские версии

*Новые версии и кандидатские версии для популярных инфраструктурных проектов Биткойна. Пожалуйста, рассмотрите возможность обновления до новых версий или помощи в тестировании кандидатских версий.*

● LND v0.21.6-beta и v0.20.7-beta — это выпуски,

направленные на устранение уязвимостей, для ветвей 0.21 и 0.20 этой популярной реализации узла LN. Оба Обе версии содержат меры по устранению уязвимости ядра Linux CVE-2026-98432, описанной ниже в LND #11456. Операторам Linux следует выполнить обновление, отключить MPTCP на хосте для защиты других сервисов и установить исправленное ядро, поскольку меры по устранению уязвимости в LND не устраняют саму базовую уязвимость.

● Core Lightning 26.06.10 — это выпуск, посвящённый безопасности, данной популярной реализации узла LN.

Он устраняет уязвимости в механизмах двойного финансирования, сплисинга, разрешения HTLC в цепочке блоков, контроля доступа и других компонентах. Исходный код исправлений безопасности доступен, однако соответствующие тесты временно приостановлены, чтобы дать пользователям больше времени на обновление. Проект настоятельно рекомендует выполнить обновление.

● BTCPay Server 2.4.7 — это выпуск, посвящённый устранению уязвимостей в этом платежном процессоре для самостоятельного развёртывания. В нём исправлены 85 уязвимостей, о которых сообщила программа OSS Scanner, включая проблемы, затрагивающие лимиты выплат, доступ к данным других магазинов, аутентификацию и исчерпание ресурсов. Также устранены проблемы, связанные с учетом платежей и надежностью работы. Настоятельно рекомендуется провести обновление, особенно для серверов, совместно используемых несколькими продавцами.

Заметные изменения в коде и документации

*Заметные недавние изменения в Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, предложениях по улучшению Биткойна (BIP), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition и BINANAs.*

● В Bitcoin Core #36539 восстановлен формат PSBTv0 для неподписанных транзакций

и увеличения комиссии, экспортируемых из графического интерфейса. Bitcoin Core 32.1 экспортировал эти PSBT, используя версию 2, что не позволяло пользователям подписывать их с помощью инструментов, поддерживающих только версию 0. Отдельный рабочий процесс с использованием внешнего подписанта, настроенный с помощью `-signer` (см. бюллетень № 138), по-прежнему использует PSBTv2, поэтому этим пользователям требуется внешний подписант, поддерживающий эту версию, например, HWI 2.1.0 или более поздней версии.

● В Bitcoin Core #35714 исправлена ошибка, из-за которой узел мог обновлять свой индекс блоков

и базу данных UTXO после неудачной попытки списания данных блоков или отменённых операций на диск. Хотя сбой давал сигнал узлу на завершение работы, код, обрабатывающий эти записи, всё ещё мог обновлять базы данных до остановки узла. Если эти обновления завершались успешно, в базах данных могло быть зафиксировано состояние, для которого соответствующие данные блока или отмены ещё не были безопасно сохранены. Это могло привести к несогласованности локального состояния узла и затруднить восстановление. Теперь код пропускает эти записи в базы данных во время неудачной попытки сброса. Это дополняет ранее реализованные меры защиты порядка сброса для опциональных индексов, описанные в бюллетене № 414.

● В Bitcoin Core #35492 исправлена ошибка, из-за которой `bitcoin-wallet dump` (см.

бюллетень № 130) могла сообщать об успешном завершении после записи неполного экспорта кошелька. Ранее команда проверяла, удаётся ли открыть файл назначения, но не обнаруживала последующие сбои записи, такие как нехватка места на диске. В результате пользователи могли ошибочно полагать, что экспорт завершился успешно, но при попытке восстановления кошелька обнаруживали отсутствующие данные. Теперь команда проверяет запись, сброс и закрытие файла. Она сообщает об ошибках и удаляет неполные файлы дампа.

● BIP № 2205, № 2210 и № 2212 добавляют три проекта

спецификаций для агрегации подписей с перекрестными входами. BIP458 определяет неинтерактивную агрегацию половинок, объединяющую `n` существующие подписи BIP340 в `32 × (n + 1)` байты вместо `64 × n` байтов. BIP459 описывает DahLIAS — интерактивный протокол, генерирующий единую 64-байтовую агрегированную подпись для нескольких ключей и сообщений. BIP460 предлагает использовать эти схемы для трат по ключевому пути (keypath) выходов новой версии свидетеля 2 выходов, при этом сохраняя отдельные подписи для трат по пути скрипта и позволяя входам по пути ключа отказаться от участия. С момента освещения этого предложения в бюллетене № 417 входы, отказавшиеся от участия, были изменены на использование обычных подписей BIP341 без специального маркера, что позволяет кошелькам принять новый тип выхода, повторно используя свою существующую логику подписи. Это позволило бы уменьшить вес транзакций и комиссии для транзакций с несколькими участвующими входами, включая coinjoins и payjoins . Внедрение предлагаемой агрегации транзакций потребует мягкого форка. В BIP460 механизм активации и параметры не указаны.

● Core Lightning #9419 добавляет опциональное `failure_reason` поле в

`listforwards` RPC и `forward_event` уведомлениях для локально неудачных попыток пересылки. Ранее несколько различных проблем имели один и тот же код сбоя протокола, что затрудняло операторам определение причины неудачной пересылки. Новое поле позволяет различать такие причины, как недостаточная исходящая ликвидность, отключенный исходящий узел и ограничения на количество или общую сумму ожидающих HTLC.

● Core Lightning #9592 обновляет `xpay` (см. бюллетень № 330)

с целью исключения узла пересылки для оставшейся части платежа после того, как он дважды возвращает `unknown_next_peer`. Ранее каждый сбой исключал только указанный канал, поэтому при последующих попытках могли продолжаться выбор других каналов через тот же узел до истечения времени повторной попытки платежа. Теперь, после второго сбоя со стороны того же узла, `xpay` он исключается на уровне частной `askrene` уровне маршрутизации. Эта эвристика может исключить пригодные для использования каналы, но ограничивает повторные попытки через один и тот же узел.

● LDK #5089 обновляет механизм повышения комиссии при принудительном закрытии каналов с

якорными выходами. Если LDK не может получить необходимые средства для дочерней транзакции CPFP, расходующей якорный выход, теперь он транслирует только транзакцию обязательства. Ранее этот сбой мог привести к тому, что обе транзакции оставались нерассыланными, что задерживало восстановление средств канала. Транзакция подтверждения уже включает комиссию, которой может оказаться достаточно для подтверждения, если оценка комиссии была консервативной или нагрузка на сеть снизилась. Однако этот резервный вариант исключает транзакции подтверждения с нулевой комиссией, которые требуют дочерней транзакции с оплатой комиссии для ретрансляции. Об этой проблеме сообщил Project Loupe.

● LND #11456 по умолчанию отключает прослушиватели Multipath TCP (MPTCP) для

смягчения последствий CVE-2026-98432 — уязвимости ядра Linux, для которой было продемонстрировано удалённое выполнение кода с использованием MPTCP. В Go 1.24 и более поздних версиях эти прослушиватели включены по умолчанию на поддерживаемых системах Linux, что может подвергнуть операторов LND риску, даже если они явно не настраивают MPTCP. Это изменение устанавливает `multipathtcp=0` в настройках по умолчанию LND на Go. Это блокирует продемонстрированный путь эксплуатации через прослушиватели LND, но не устраняет базовую ошибку ядра. Затронутые системы по-прежнему требуют установки исправленного ядра. Операторы, использующие существующие бинарные файлы, могут применить ту же меру защиты, перезапустив LND с переменной среды `GODEBUG=multipathtcp=0`.

● LND #11357 ужесточает проверку счетов BOLT11 в соответствии с BOLT

#1357 (см. Бюллетень № 428). Вместо использования первого и игнорирования остальных, теперь отклоняются дубликаты полей секретного ключа платежа, что предотвращает неоднозначность между парсерами, выбирающими разные вхождения. Это основано на ранее введённом отклонении дубликатов хэшей платежей (см. информационный бюллетень № 425). Тесты, добавленные в рамках обновления спецификации, также выявили, что существующие требования не соблюдались. Теперь декодер отклоняет неправильные длины при разборе хеша платежа, хеша описания, секретного ключа платежа и открытого ключа получателя, вместо того чтобы рассматривать эти поля как отсутствующие. Ранее поле открытого ключа получателя с неправильным размером могло привести к тому, что LND переходил к восстановлению ключа из подписи. Для счетов, содержащих явный открытый ключ получателя, также требуется подпись ECDSA с низким показателем S. Однако это ограничение не применяется, когда открытый ключ восстанавливается из подписи (см. информационный бюллетень № 381).

● LND #11413 ускоряет очистку при запуске сохраненных результатов исходящих платежей

на узлах, использующих SQLite или PostgreSQL. Во время нормальной работы узел накапливает результат для каждой разрешённой, инициированной локально попытки HTLC. При запуске он удаляет результаты, которые больше не нужны. Ранее чтение и удаление записей по отдельности требовали многократных обращений к базе данных, из-за чего очистка на загруженном узле, использующем удалённый PostgreSQL, могла занимать часы. Теперь очистка объединяет операции с базой данных в пакеты, сохраняя при этом результаты, необходимые для возобновления ожидающих платежей.

● LND #11151 добавляет проверки на чрезмерные комиссии за обязательства и недостаточные

начальные балансы при приеме входящих каналов. Теперь LND отклоняет предлагаемую ставку комиссии, превышающую большее из следующих значений: десятикратную оценку за три блока или 100 сат/вбайт. Он также обеспечивает соблюдение правила BOLT2 о начальном резерве и отдельно отклоняет каналы, в которых начальный баланс ни одной из сторон не превышает резерв, который эта сторона должна поддерживать. Хотя инициатор и оплачивает комиссию за обязательство, чрезмерно высокая комиссия может исчерпать его доступный баланс, в результате чего во время открытия канала будет впустую потрачена пропускная способность канала получателя, а после подтверждения транзакции пополнения останется неиспользуемый канал. Это дополняет проверки минимальной ставки комиссии, описанные в бюллетене № 429.

● Rust Bitcoin #7067 расширяет вспомогательные функции хеширования подписи Taproot

(sighash) для принятия опционального приложения, а также, для расходов по scriptpath, позицию опкода последнего OP_CODESEPARATOR, выполненного перед проверкой подписи. Оба параметра влияют на сообщение, к которому относится подпись. Ранее эти удобные функции предполагали отсутствие приложения и отсутствие выполненного `OP_CODESEPARATOR`, поэтому вызывающие функции, обрабатывающие такие расходы, должны были использовать более общую функцию sighash, чтобы избежать получения неверного дайджеста. Теперь вспомогательные функции принимают эти значения напрямую, хотя вызывающие функции по-прежнему должны определять позицию разделителя. Вызывающие функции, обрабатывающие расходы без приложения или без выполненного `OP_CODESEPARATOR` могут передать `None` для новых аргументов, чтобы сохранить прежнее поведение. См. бюллетень № 427, где описаны связанные изменения API sighash для трат в режиме legacy и segwit v0 .