Opcode

アンナがペーターに支払うとします。ウォレットが取引と必要な署名を作り、ノードが選ばれたコインを使う権限を確かめます。ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。ノードは、取引やブロックを検証し、ネットワークの他の参加者と通信するソフトウェアです。その検証の一部を記述する言語が Bitcoin Script です。Opcode は署名の確認など、一つの命令を指します。通常の支払いでアンナが手書きするものではありません。ただしノードは所有者の名前や「署名済み」という表示を信用できず、実際に条件を評価します。スクリプトが正しいことは、取引全体の検証の一部分です。 [1] [4]

読みやすい表示には OP_DUP や OP_CHECKSIG が出てきます。これは人向けの命令名で、実際のスクリプトでは一バイトのコードです。バイトはデータ量を表す一般的な単位です。別の部分には公開鍵などのデータがあります。公開鍵は署名の検証に使うもので、秘密にしておく必要はありません。OP_PUSHDATA 系の命令は、続く何バイトをデータとして入れるか指定します。入れたデータの内部のバイトを、再び命令として実行することはありません。レシピの「塩を加える」という指示と、器に入れる材料の違いに似ています。 [1] [2]

一番上から取り出すメモの山を想像してください。スクリプトの基本的な作業用スタックも同様です。OP_DUP は一番上の項目を複製し、OP_DROP は一番上を取り除きます。空でないスタックで OP_DUP の後に OP_DROP を実行すると、内容は元に戻ります。コインを増やしたのではなく、作業データを複製しただけです。必要な項目がなければ失敗することがあります。順序や正確な符号化も重要です。 [1]

OP_EQUAL は上の二項目を取り出してバイトを比較し、比較結果で置き換えます。OP_EQUALVERIFY は不一致ならすぐ失敗し、一致なら結果をスタックに残さず続行します。どちらも単独では署名を確認しません。同じ公開鍵を二つ出すことは誰でもできます。必要なメッセージに署名できたことを示すには、対応する署名検証が必要です。 [1] [4]

OP_CHECKSIG は公開鍵と取引から組み立てたメッセージを使い、秘密鍵を公開せずに署名を検証します。秘密鍵は、そのような署名を作るために使う秘密の数値です。sighash の指定で署名が対象とする部分が決まり、どのモードもすべてに署名するわけではありません。従来のスクリプトと SegWit バージョン 0 は署名方式 ECDSA を使います。Taproot のスクリプト規則である Tapscript は、通常の 32 バイト鍵に別の方式 Schnorr を使います。こうした前提なしに命令名だけでは判断できません。 [1] [3]

条件は通常の支出や、代わりの復旧経路を許可できます。OP_IF と OP_ELSE はスタックの値で分岐を選び、OP_ENDIF が条件部分を閉じます。Bitcoin Script には任意に繰り返す一般的なプログラムループがありません。しかし、実行しない分岐なら何でも無視できるわけではありません。読み取り時点で確認する命令もあり、種類と規則のバージョンが重要です。 [1] [3]

CLTV、つまり OP_CHECKLOCKTIMEVERIFY は、チェーン内での位置を表すブロック高などの絶対的な境界を強制できます。CSV、つまり OP_CHECKSEQUENCEVERIFY は、取引の経過期間の規則と合わせ、使う出力の承認から相対的な待機を要求します。出力とは以前受け取った金額と支出条件の記録です。命令は取引のフィールドを確認するのであって、タイマーを動かしたり送金したり署名を代替したりしません。用途に合う時間ロックを他の条件と組み合わせる必要があります。 [7] [8] [9]

技術例を読む前に、従来のスクリプト、SegWit、Tapscript のどれか確かめましょう。Tapscript は署名検証を組み合わせる OP_CHECKSIGADD を追加します。一方 OP_CHECKMULTISIG は実行すると失敗し、実行しない分岐ではその規則に従って無視されます。名前の矛盾ではなく、検証環境が違うのです。Opcode の一覧は、形式をまたいで無条件に使い回せる万能の部品集ではありません。 [1] [3] [6]

BIP 342 は将来の Tapscript 拡張のために OP_SUCCESSx 群を予約しています。先行する検査を通過した後、デコード中に該当命令を見つけると、以降のスクリプト検査を飛ばして成功します。実行しない分岐でも同様です。挿入データの中に偶然同じバイトがあるだけでは該当しません。これは規則変更の余地で、すでに有効な新しい保護ではありません。未定義の将来の意味に頼る条件では、作者の意図どおりに資金を守れない可能性があります。 [1] [3]

Full Node は独立して有効性規則を確認しますが、未承認取引の受け入れや中継には、より厳しい規則を使えます。例えば Bitcoin Core v29.0 は標準設定で、Tapscript 内で OP_SUCCESSx 命令を使う取引の中継を拒否します。合意規則ではブロック内に認められる場合でも同じです。例を読むときはバージョン、初期データ、署名範囲、失敗条件を確かめましょう。読みやすい構文だけで安全なウォレットとはいえず、通常は検討済みのソフトウェアにこの仕事を任せます。 [1] [5]