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

У цьому тижневому бюлетені підсумовано триваючу дискусію щодо використання TCP-хол-панчингу для забезпечення доступності вузлів, розташованих за домашніми маршрутизаторами, а також описано проект BIP щодо стандартизації правил витрачання коштів, які дотримуються співпідписники під час емуляції ковенантів. Також до випуску увійшли наші регулярні рубрики, в яких підсумовуються пропозиції та обговорення щодо зміни правил консенсусу в Bitcoin, анонсуються нові версії та кандидатські версії, а також описуються значні зміни в популярному програмному забезпеченні інфраструктури Bitcoin.

Новини

● Продовження обговорення пробивання отворів у TCP для домашніх вузлів: Після

нашого травневого підсумку обговорення у темі 0xB10C «Delving Bitcoin» щодо використання «hole punching» для того, щоб вузли, розташовані за домашніми маршрутизаторами, могли приймати з’єднання один від одного, 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 погодився з обома зауваженнями та сказав, що додасть прапорець остаточності та чітко визначить правила верифікатора.

Зміна консенсусу

*Щомісячний розділ, у якому підсумовуються пропозиції та обговорення щодо зміни правил консенсусу Bitcoin.*

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

розсилці Bitcoin-Dev свою точку зору щодо стану м’якого форку з очищення консенсусу (BIP54). Заборона транзакцій, розмір яких без свідчень становить рівно 64 байти, залишається найбільш суперечливим правилом. Реалізація Bitcoin Core наразі перебуває на стадії розгляду та тестування і є еталонною реалізацією, на яку посилається BIP (Bitcoin Core #35793). Цей PR увімкне нові правила в regtest без активації в мейннеті. Він також вказав на роботу з взаємодії в btcd (btcd #2537) і зазначив, що йому не відомо про жодну реалізацію libbitcoin. На його думку, залишається провести додатковий перегляд і тестування, підготувати документацію, щоб гаманці знали про запропоноване обмеження у 2 500 операцій підпису в скрипті pre-segwit та про правило 64 байтів, а вже потім — про логіку активації. Висловлюючи лише свою особисту думку, він вважає, що реалістично було б почати розглядати питання активації у другій половині 2027 року, якщо до того часу спільнота дійде згоди.

Пітер Вуїлле оновив свою гілку «Delving Bitcoin» щодо того, як два правила часових міток BIP54 обмежують довжину ланцюга (див. Бюлетень № 425). У першому дописі тепер наведено точну формулу для нижньої межі роботи, і як ця формула, так і десяткове наближення тепер доведені в коді Lean, посилання на який наведено.

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

Прототип опції opt-in захисту від повторного відтворення : Сьорс Провоост продовжив обговорення у темі Delving Bitcoin щодо опції «opt-in» захисту від повторного відтворення у разі розгалуження ланцюга (див. Бюлетень № 420 ) , представивши прототип, що використовує нову версію свідка. Додаток , корисне навантаження якого починається з байта 0x01, позначає блок за допомогою 4-байтової висоти, а кожен підпис на цьому вході фіксує хеш блоку в бажаному ланцюгу. Сам хеш у транзакції відсутній. Він оцінив додаткові витрати в 1,75 vbytes. Названий блок повинен мати вік щонайменше 100 блоків, що відповідає терміну дії coinbase. Він зазначив, що якщо хешрейт розподілиться рівномірно, час очікування до можливого розділення монет у найгіршому випадку становитиме два дні, оскільки правило має дотримуватися лише з одного боку. Він запропонував випустити версію свідка разом з іншою пропозицією, яка її потребує, наприклад, 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% чесної більшості. Він назвав це суттєвим відхиленням від моделі безпеки Bitcoin і зазначив, що одним із аргументів на користь цього є те, що зловмиснику, який володіє менше ніж 75% хешрейту, буде складніше викрасти кошти.

Випуски та кандидатські версії

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

● 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, Bitcoin Improvement Proposals (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 , зберігаючи при цьому індивідуальні підписи для витрат за сценарієм scriptpath та дозволяючи входам за ключовим шляхом відмовитися від участі. З часу висвітлення цієї пропозиції в Бюлетені № 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 .