OP_CAT

OP_CATはbitcoinのオペコードの一つ

スタックの最上位にある2つのデータ要素を取り出し、それらを連結して1つのデータ要素として再びスタックに載せる

(2つの文字列を結合（連結）することができる)

2010年あたりにセキュリティ上の懸念であり無効化された

実行時にスクリプト内のデータサイズが急激に増大する可能性があり、リソース消費を抑えるのが難しかった。

バッファオーバーフローやDoS攻撃などのリスクがあった。

以下のように、OP_DUPと組み合わせることでスタックのサイズが指数関数的に増加する

1. スタック上のデータをOP_DUPにより複製

2. OP_CATにより、スタック上の2つの要素を連結し、その結果をスタックにプッシュする

3. OP_DUPとOP_CATの数分、1〜2を繰り返す。

スタック要素のサイズが最大5000バイトの制限があるが、OP_DUPとOP_CATを組み合わせて24バイト程度で5000バイトの要素を生成することができるため、攻撃に使用される恐れがあった。

---------------------------------------------------------------------------------------------------------------

TapscriptでOP_CATを再導入しようとしている

Taprootのスタック要素の最大サイズが520バイトであり、OP_CATで連結したスタック要素の最大サイズも520バイトに制限

スタック要素の最大数は1000であるため、1000*520=520KBが最大となる

これらの制限もあり、Tapscriptと組み合わせることで柔軟なスクリプトが書けるようになるため、再導入が提案されている

Covenants（コベナント）の実現

コベナントとは、UTXO（未使用のビットコイン残高）が将来的にどのように使われるかに制約をかける仕組み

これは、Bitcoinの既存の仕組みでは実現が非常に難しい機能です。

具体例: 制限付き送金のユースケース

「特定の受取人に送金された資金は、その後特定のウォレットにしか移動できない」

という制約をスクリプトに埋め込む場合、以下のようなイメージになります：

制約条件 = SHA256(次のUTXOのScriptPubKeyの一部 || 制限条件データ)

現状では、次のトランザクションのScriptPubKeyデータをスクリプトで生成・連結できません。

OP_CATが利用可能になれば、Covenantsスクリプトで将来のスクリプト条件を明確に指定し、UTXOの利用を制限できるようになります。

応用例:

資金をマルチシグウォレットに移動した後、一定期間（例：3ヶ月）経過するまでは、特定のアドレスにしか送金できないように制限をかける。