The Future of Disabled Opcodes - OP_CAT Revival Debate

OP_CAT enables:
  1. Covenants (constraining future spending conditions)
  2. Merkle proof verification (trustless SPV)
  3. Schnorr signature introspection (Lamport-style sigs, vault enforcement)
  4. ZK proof verification infrastructure
  5. Cross-chain bridges without custodians
  6. Tree signatures and advanced multisig constructions
  7. Recursive covenants (vaults with "only send here" rules)

BIP-347 specification:
  Opcode: OP_CAT (0x7E)
  Available in: Tapscript (leaf version 0xC0 and future versions)
  NOT available in: legacy Script, P2SH, SegWit v0

  Behavior:
    1. Pop item_B from stack
    2. Pop item_A from stack
    3. Check: len(item_A) + len(item_B) <= 520
       If exceeds 520 bytes → SCRIPT_ERR_INVALID_STACK_OPERATION
    4. Push item_A || item_B

  The 520-byte limit:
    This matches the existing MAX_SCRIPT_ELEMENT_SIZE limit.
    Any OP_CAT result respects the same size constraint as any push.
    The exponential doubling attack is bounded:
      Start: 1 byte
      After 9 doublings: 512 bytes (within limit)
      After 10 doublings: 1024 bytes → FAILS at OP_CAT
      The attack terminates naturally before memory becomes a concern.

Schnorr signature structure (64 bytes for SIGHASH_ALL):
  sig = r || s
  Where r is 32 bytes (nonce point x-coordinate)
        s is 32 bytes (signature scalar)

Trick: OP_CAT + OP_CHECKSIG covenant

  Script:
    <fixed_r_value_32_bytes>
    OP_SWAP OP_CAT
    OP_CHECKSIG

  When spending:
    Witness provides: <s_value>
    Script constructs: <fixed_r> || <s_value> = 64-byte Schnorr sig
    OP_CHECKSIG verifies the concatenated signature

  Effect: The r-value is FIXED by the script.
  A Schnorr signature is valid only when r matches the nonce used during signing.
  Fixing r forces the signer to use a specific nonce — and specific nonces
  bind signatures to specific transaction data (sighash), enabling covenant behavior.

  Combined with SIGHASH modes and careful key derivation,
  this allows scripts that enforce "this UTXO can only be spent to <specific output>."

Merkle proof verification script:

  Input: <leaf_hash> <proof_siblings_1..n> <root>

  Verification loop (unrolled for a 3-level tree):
    <leaf_hash> <sibling_1> OP_CAT OP_SHA256   → <level1_hash>
    <level1_hash> <sibling_2> OP_CAT OP_SHA256 → <level2_hash>
    <level2_hash> <sibling_3> OP_CAT OP_SHA256 → <computed_root>
    <expected_root> OP_EQUAL

  Note: Real Merkle verification requires knowing left/right ordering,
  handled by providing pre-sorted pairs or ordering flags.
  OP_CAT + OP_IF can handle this.

  Applications:
    - Bitcoin → Ethereum bridge (prove a Bitcoin tx to an Ethereum contract)
    - Ethereum → Bitcoin bridge (prove to a Bitcoin UTXO that a condition on ETH was met)
    - Cross-chain atomic swaps with on-chain proof of payment
    - Lightning Network watchtower constructions

Lamport signature concept:
  Private key: 256 pairs of 256-bit random numbers (for SHA256 output)
  Public key:  SHA256 of each private key half
  Signing:     For each bit of message hash:
                 If bit is 0: reveal private_key[i][0]
                 If bit is 1: reveal private_key[i][1]
  Verification: Hash each revealed value, check against public key

OP_CAT enables Lamport verification in Script:
  For each of the 256 bits:
    <preimage> OP_SHA256    → <hash>
    <expected_hash> OP_EQUAL → verify one bit's signature

  OP_CAT is needed to assemble intermediate values
  and to reconstruct the signed message hash from revealed preimages.

This creates Bitcoin transactions that are valid even if ECDSA/Schnorr
are broken by quantum computers — purely hash-based security.

Concern: If UTXOs can be marked "only spendable to addresses X, Y, Z,"
then some bitcoins become "restricted" and others "unrestricted."
This could create a two-tier Bitcoin where "clean" coins (no covenants)
trade at a premium over "restricted" coins.

Counter: Covenants are opt-in. Nobody forces anyone to create
covenant-constrained UTXOs. The fungibility concern applies to
any identifiable Bitcoin (which already exists via chain analysis).

Concern: Recursive covenants (covenants whose spending conditions
require the output to also have the same covenant) could create
UTXOs that are permanently unspendable or permanently restricted.

Example:
  UTXO with covenant: "Can only be spent to another UTXO with this same covenant"
  This creates a permanent recursive trap — the coins can never
  leave the covenant's constraints.

Counter: Opt-in again. Also, vaults WANT this behavior (coins can
only ever leave via approved withdrawal path). The "trap" is a feature
for self-custody security, not a bug.

Concern: Every new opcode adds complexity to the consensus rules.
More complexity = more attack surface = more potential bugs.
Bitcoin's conservatism has served it well for 15 years.

Counter: OP_CAT is a single, well-specified operation.
Its semantics are completely understood. The risk is lower
than adding complex new opcodes with multiple parameters.
The 520-byte cap handles the only known attack vector.

Concern: OP_CAT might enable constructions we haven't fully thought through.
Unexpected interactions with future opcodes could create problems.
The safe move is to study it more before deploying.

Counter: OP_CAT has been studied since 2010. Elements/Liquid has run it
in production for years. The research is in — it's time to act.

OP_CAT (BIP-347):      HIGH likelihood of re-enablement
                       Active BIP, implementation exists, widespread interest

OP_SUBSTR / OP_LEFT / OP_RIGHT:
                       MODERATE — less urgent given OP_CAT
                       Could be specified with size limits like OP_CAT
                       Less community momentum currently

OP_AND / OP_OR / OP_XOR:
                       LOW-MODERATE — useful but not critical
                       Elements/Liquid has enabled them with equal-length rules
                       Bitcoin mainnet discussion is minimal

OP_INVERT:             LOW — limited compelling use cases articulated
                       Could be done but not a priority

OP_MUL / OP_DIV / OP_MOD:
                       MODERATE — useful for arithmetic
                       OP_DIV and OP_MOD especially useful for Script math
                       Some BIPs have proposed these

OP_LSHIFT / OP_RSHIFT: LOW — niche use cases
                       Bitshift without clean-up logic is messy in Script

Elements/Liquid re-enabled opcodes:
  OP_CAT            (with 520-byte limit)
  OP_SUBSTR         (with bounds checking)
  OP_LEFT           (with bounds checking)
  OP_RIGHT          (with bounds checking)
  OP_INVERT         
  OP_AND            (equal-length requirement)
  OP_OR             (equal-length requirement)
  OP_XOR            (equal-length requirement)
  OP_LSHIFT         
  OP_RSHIFT

This gives the Bitcoin community empirical evidence that properly
specified versions of these opcodes are safe.

Activation path:
  1. BIP specification finalized (BIP-347 is already drafted)
  2. Implementation in Bitcoin Core (client support)
  3. Community consensus building (mailing list, conferences, CoreDev)
  4. Miner signaling (likely via Speedy Trial or BIP-8)
  5. Tapscript version bump activates OP_CAT
  6. Backward-compatible: old scripts unaffected,
     new Tapscript leaves can use OP_CAT

No hard fork required — this is a soft fork.

Vision A: Bitcoin as Digital Gold
  - Simple, conservative, minimal features
  - Maximum security through minimal complexity  
  - Smart contracts happen on L2 (Lightning, sidechains)
  - OP_CAT is unnecessary risk for marginal benefit

Vision B: Bitcoin as Programmable Settlement Layer
  - Rich on-chain script capabilities
  - Covenants, vaults, bridges, ZK proofs on L1
  - OP_CAT is the minimal step toward this vision
  - The 520-byte cap makes risk manageable

The resolution:
  OP_CAT is opt-in. It doesn't change anything for Vision A holders.
  It only enables Vision B without preventing Vision A.
  This is why it has growing support even among moderate Bitcoiners.