132 / 736MINI

Miniscript

Более понятная запись условий расходования биткоинов

Кто может потратить монеты, что он должен доказать и нужно ли сначала ждать? Miniscript помогает кошелькам точно составлять, проверять и применять такие правила.

Miniscript — структурированная запись части Bitcoin Script, языка условий расходования монет. Он позволяет объединять подписи, ожидание и раскрытие определённых секретов так, чтобы программа могла проанализировать условия и подготовить данные для их выполнения. Это не отдельный кошелёк и не новые правила Bitcoin: монеты защищает получившийся скрипт.

Анна хочет пользоваться монетами как обычно, с помощью собственного ключа. Цифровая подпись подтверждает разрешение на платёж с помощью закрытого ключа — секретного числового значения, не раскрывая сам ключ. Кошелёк — приложение или устройство для получения и отправки биткоинов. При этом Анна хочет предусмотреть путь для Петра: он сможет потратить их своим ключом после 144 блоков с момента подтверждения этого выхода. Такой замысел называют spending policy — правилами расходования. Miniscript помогает придать ему точную форму, понятную кошельку. Петру по-прежнему нужен ключ; ожидание его не заменяет. Это простой пример альтернативных путей доступа, а не автоматический перевод и не способ определить, что Анна потеряла ключ. [1] [2] [10]

Правило, выраженное словами, ещё не программа, которую проверяет сеть. Компилятор может выбрать конкретный Miniscript и преобразовать его в Bitcoin Script. Output Descriptor затем описывает скрипты вместе с ключами и, при необходимости, путями их вывода; он также может содержать контрольную сумму для обнаружения ошибок копирования. При расходовании сеть проверяет сам скрипт и предоставленные данные, а не исходное предложение. Miniscript не добавляет инструкций и не меняет консенсус — общие правила действительности. Не любой мыслимый Bitcoin Script можно представить в этой форме. [1] [3] [6]

Блок объединяет транзакции в пакет, добавляемый в общую историю. В примере Петра 144 блока отсчитываются от подтверждения выхода — конкретной суммы с условиями расходования. Это не ровно сутки и не время с момента создания кошелька. Относительное ожидание Miniscript записывает как older(n), используя CSV и поле nSequence входа, расходующего этот выход. BIP 68 задаёт смысл этого поля при проверке возраста. Напротив, after(n) использует CLTV и абсолютный nLockTime — фиксированную высоту или временную границу. Кошелёк должен правильно задать поля транзакции и выполнить остальные условия. Ограничения по высоте и времени нельзя сочетать несовместимым образом; само ожидание ничего не отправляет. [1] [7] [8] [9] [11]

Показать описание правил недостаточно. Кошелёк должен предоставить данные, выполняющие разрешённый путь: например, подписи или секрет с нужным хешем, называемый его preimage. Хеш — цифровой отпечаток данных; здесь проверяют, даёт ли предоставленный секрет нужный отпечаток. Такое выполнение — satisfaction; необходимые входные данные входят в witness транзакции. При объединении ветвей иногда нужно сделать отдельное подусловие ложным предусмотренным способом, чтобы использовать другой путь. Это dissatisfaction, а не недействительность всего платежа. Программа может собрать подходящий путь, но не придумать отсутствующий приватный ключ или неизвестный секрет. [1] [12]

PSBT — формат передачи подготовленной транзакции и дополнительных данных между кошельком и подписывающими устройствами. Одной поддержки PSBT мало: программа и Hardware Wallet должны понимать descriptor и его условия. Bitcoin Core добавил наблюдение за Miniscript в P2WSH в версии 24, подписание в версии 25 и использование в Taproot descriptors в версии 26. Следить за монетами не значит уметь их потратить. При настройке проверьте на доверенном дисплее ключи, необходимые подписи, задержки и все альтернативные пути с учётом реальных возможностей устройства. [3] [4] [5]

Seed Phrase восстанавливает ключи, но для собственных сложных условий может не объяснить, как их объединили с другими ключами и скриптом. Это резервная копия в виде последовательности слов, из которой кошелёк может вывести свои ключи. Сохраните точный descriptor с контрольной суммой, соответствие ключей, пути вывода и различие между адресами получения и сдачи. Отдельно запишите сеть, диапазон адресов и начальную точку поиска по истории. Публичный descriptor — не приватный ключ, но он может раскрыть историю платежей. Прежде чем пользоваться такой схемой, проверьте восстановление наблюдающего кошелька и каждый задуманный путь расходования в тестовой среде Regtest или Signet. [5] [6]

pk(), older(), after() и sha256() обозначают подписи, ожидание или требование секрета. and_v(), or_d() и thresh() объединяют условия. Обёртки вроде v: меняют способ вычисления, сохраняя смысл подвыражения. Типы B, V, K и W определяют, как части передают элементы в стеке, рабочей области скрипта; не любые две части совместимы. Проверка типов позволяет обнаружить несовместимую конструкцию. Но она не решит за Анну, кому доверять и разумно ли выбран запасной путь. [1] [2]

Структура позволяет заранее анализировать размеры скрипта и witness, количество операций, проверок подписей и элементов стека. Это помогает оценить стоимость разных путей и обнаружить превышение допустимых пределов. Важен контекст: P2WSH помещает условия в SegWit, а Tapscript обозначает скрипты, используемые в Taproot. Их ограничения отчасти различаются. Помимо консенсуса действуют обычные правила передачи транзакций. Поэтому результат анализа не подтверждает, что любой кошелёк сможет выполнить задуманный порядок действий. [1]

Открытый ключ используют для проверки подписей; его не требуется хранить в секрете. Анализ malleability исследует, может ли посторонний превратить одну действительную satisfaction в другую, тоже действительную. Гарантии имеют конкретные предпосылки: у атакующего нет приватных ключей участников, он знает не больше preimages, чем честный пользователь, и видит лишь одну satisfaction. Также предполагаются неповторяющиеся публичные ключи и обычные правила приёма; у майнера могут быть возможности, которых нет у обычного передающего узла. Это не защита от всех недобросовестных участников, утраты резервных копий или плохой схемы хранения. Эти вопросы нужно рассматривать отдельно. [1]

Компилятор способен выразить одинаковые правила разными способами с разными размерами скрипта и witness. Выбор зависит от модели стоимости. Пометка 9@ у ветви языка политик указывает относительную вероятность её использования; это не число подписей и не разрешение сети. Другая компиляция может создать другой скрипт, а значит, другие адреса. Для восстановления недостаточно вновь описать правила своими словами и скомпилировать их. Важны точная сохранённая запись, проверка выведенных адресов и испытанный путь подписания. [2] [5]

Для полной картины прочитайте эту статью вместе с Bitcoin Script, Output Descriptor, Multisig, Andrew Poelstra, Timelock, Bitcoin. На эту статью также ссылаются Output Descriptor, Dead Man’s Switch, Andrew Poelstra, Simplicity.

DOC · 001BIP 379 — MiniscriptСпецификация DOC · 002Miniscript Reference — Specification and AnalyzerСпецификация DOC · 003Bitcoin Core v29.0 — Output DescriptorsДокументация DOC · 004Bitcoin Core 24.0.1 — Miniscript SupportДокументация DOC · 005BIP 388 — Wallet Policies for Descriptor WalletsСпецификация DOC · 006BIP 380 — Output Script DescriptorsСпецификация DOC · 007BIP 68 — Relative Lock-Time Using Consensus-Enforced Sequence NumbersСпецификация DOC · 008BIP 65 — OP_CHECKLOCKTIMEVERIFYСпецификация DOC · 009BIP 112 — CHECKSEQUENCEVERIFYСпецификация DOC · 010Bitcoin Developer Guide — WalletsДокументация DOC · 011Bitcoin Developer Guide — Block ChainДокументация DOC · 012Bitcoin Developer Reference — TransactionsДокументация
Обновлено: Сначала источники · Не является инвестиционной рекомендацией