OP_CAT

連結は些細なことに思えますが、そうではありません。これがあれば、スクリプトはスタックに積まれた部分からトランザクションの署名ハッシュを520バイト以下のチャンクで組み立て直し、そのハッシュを通常の署名検証で確認できます。危険であるために無効化されたオペコードが、covenantの一覧で最も議論される項目になったのは、こうした理由からです。

仕組み

状態： 2010年8月から無効化されています。このとき、スクリプトエンジンの防御的な一掃の中で、文字列と算術に関する一連のオペコードが無効化されました。BIP-347はtapscript内でのみ再有効化することを提案しています。mainnetでは有効になっていません。

操作そのものは1行です。2つの要素をポップし、そのバイト列を端から端まで結合してプッシュします。2010年にこれが危険だった理由は、スタック要素がどこまで大きくなり得るかに制限がなかったことです。要素をそれ自身と連結すると2倍になるため、プッシュと結合を短いループで繰り返すと、数バイトがギガバイトに膨れ上がり、ノードのメモリを奪いかねませんでした。現代のエンジンには、単一のスタック要素に対して520バイトという厳格な上限があるため、BIP-347は結果がそれを超える場合に単に操作を失敗させ、かつての攻撃は消えます。

番号付けの奇妙な点が、復活を異例なほどきれいなものにしています。OP_CATはオペコード126です。BIP-342がtapscriptを定義したとき、オペコード126から129までをはじめとするいくつかのオペコードをOP_SUCCESSと宣言しました。これに遭遇すると、スクリプトはその場で成功します。そのため旧ノードは、バイト126を含むtapscriptを、そのオペコードを実行せずにすでに受け入れます。それを連結を行うものとして再定義することは、そうしたノードが許容したはずの範囲を狭めるだけであり、変更はチェーンの分裂ではなくソフトフォークになります。

連結が解き放つものは、その大きさに不釣り合いです。バイト列を構築できるスクリプトは、Merkle証明を検証し、楕円曲線ではなくハッシュから構築されたLamport署名やWinternitz署名を確認し、署名が固定のnonceを使うよう強制することで署名方程式そのものが支出トランザクションをスクリプトに露出させることができます。最後の技法が、covenant専用のオペコードを一切使わずにOP_CATを汎用のcovenantツールに変えるものです。

使われている場所

OP_CATはビットコイン上ではまったく動作しません。動作する場所は、ビットコインのスクリプトエンジンをコピーし、その後2010年の決定を覆したサイドチェーンとテストネットワークです。

Elements、ひいてはLiquidではオペコードが有効になっており、公開されているcovenantの実演のほとんどがビットコインではなくLiquid向けに書かれているのはそのためです。BIP-347のルールを備えたカスタムsignetももう1つの場であり、開発者がコンセンサスの変更を誰かに求める前にその仕組みを構築できるように存在しています。

ビットコインを購入したり保有したりする人にとって、実用的な内容は短いものです。OP_CATが有効になっても、決して有効にならなくても、ウォレット、アドレス、バックアップのいずれも変わりません。この名前を知っておく価値があるのは、ビットコインがどれだけのプログラマビリティを持つべきかという実際の意見の相違の中心にあるからであり、量子コンピュータの未来に備えてハッシュベースの署名を追加する提案が、しばしばこれを経由するからです。