Miniscript

アンナは普段、自分の鍵でコインを使いたいと考えています。デジタル署名は、秘密の数値である秘密鍵を使って支払いの許可を証明し、鍵そのものは公開しません。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。アンナは同時に、ある出力が承認されてから 144 ブロック経過すれば、ピーターも自分の鍵で使える経路を用意したいとします。この意図を spending policy、つまり支出のルールと呼びます。Miniscript は、それをウォレットが扱える正確な形にする手助けをします。ピーターには依然として鍵が必要で、待つだけでは代わりになりません。これは複数の利用経路の単純な例であり、自動送金やアンナの鍵紛失を検知する仕組みではありません。 [1] [2] [10]

言葉で述べたルールは、まだネットワークが検証するプログラムではありません。コンパイラは具体的な Miniscript を選び、Bitcoin Script に変換できます。Output Descriptor は、そのスクリプトを鍵や必要な派生パスとともに記述し、転記ミスを見つけるチェックサムも付けられます。支出時に検証されるのは実際のスクリプトと提出データであり、元の文章ではありません。Miniscript は命令を追加せず、共通の有効性ルールであるコンセンサスも変更しません。あらゆる Bitcoin Script を表せるわけではありません。 [1] [3] [6]

ブロックは、共有する履歴に追加する取引のまとまりです。ピーターの例の 144 ブロックは、出力の承認から数えます。出力とは、支出条件が付いた具体的な金額です。正確に一日という意味でも、ウォレット作成からの経過時間でもありません。Miniscript は相対的な待ち条件を older(n) と表し、CSV と、その出力を使う取引入力の nSequence フィールドを利用します。経過期間の検証における 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 はバージョン 24 で P2WSH 内の Miniscript の監視専用対応を、バージョン 25 で署名を、バージョン 26 で Taproot descriptors での利用を追加しました。コインを監視できることと、使えることは別です。設定時には、機器の実際の機能に応じて、信頼できる画面で鍵、必要な署名、待ち時間、すべての代替経路を確認してください。 [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 を別の有効な satisfaction に変えられるかを調べます。保証には条件があります。攻撃者は参加者の秘密鍵を持たず、正直な利用者より多くの preimages を知らず、一つの satisfaction しか見ていないと仮定します。公開鍵の重複がないことや通常の受入ルールも前提で、マイナーには普通の中継ノードと異なる選択肢があり得ます。あらゆる悪意ある参加者、バックアップ紛失、不適切な保管設計から守る保証ではありません。それらは別に検討する必要があります。 [1]

コンパイラは、同じルールを異なるスクリプトや witness のサイズで表し、コストモデルに従って選択できます。ポリシー入力言語の分岐に付く 9@ のような記号は、相対的な利用確率のヒントであり、署名数でもネットワークの許可でもありません。違うコンパイル結果は別のスクリプト、そして別のアドレスを生む場合があります。そのため復元時に、ルールを自分の言葉で書き直して再コンパイルするだけでは不十分です。保存した正確な表現、派生アドレスの確認、試験済みの署名経路が重要です。 [2] [5]