Taproot vault key structure

Setup:
  1. Generate hot key H and cold key C
  2. Create vault address: P2WSH of a 2-of-2 multisig or timelock script
  3. Pre-sign a "unvault" transaction (moves to hot wallet after delay)
  4. Pre-sign a "emergency" transaction (moves to cold storage immediately)
  5. Destroy or secure the hot key until needed

Vault locking script:
OP_IF
    <cold_pubkey> OP_CHECKSIG     ← cold path: immediate, no delay
OP_ELSE
    <delay> OP_CSV OP_DROP
    <hot_pubkey> OP_CHECKSIG      ← hot path: requires waiting 'delay' blocks
OP_ENDIF

Vault script with 144-block (~24 hour) delay:

scriptPubKey (P2WSH of):
OP_IF
    OP_DUP OP_HASH160 <cold_keyhash> OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
    <0x9000> OP_CHECKSEQUENCEVERIFY OP_DROP
    OP_DUP OP_HASH160 <hot_keyhash> OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

Spending via cold path (emergency recovery, no delay):
  witness: [<cold_sig> <cold_pubkey> OP_1 <witnessScript>]

Spending via hot path (normal withdrawal, after 144 blocks):
  witness: [<hot_sig> <hot_pubkey> OP_0 <witnessScript>]
  Input nSequence must be >= 0x9000 (144 in CSV encoding)

Revault flow:
  Deposit → Vault UTXO
     ↓ (pre-signed Unvault tx, broadcast by manager)
  Unvault UTXO (locked by CSV delay)
     ↓ Option A: After delay, Spend tx (manager + stakeholder sigs)
  Destination
     ↓ Option B: Watchtower sees Unvault, broadcasts Cancel tx immediately
  Vault UTXO (funds re-vaulted)

Key innovation: Watchtowers can cancel any unvaulting attempt using
pre-signed Cancel transactions, giving stakeholders emergency override
even if manager keys are compromised.

CTV vault design (BIP 345 style):
  Vault output: OP_CTV <unvault_template_hash>
  Unvault output (after delay): OP_CTV <spend_template_hash>

Template hash commits to:
  - Specific output addresses
  - Specific amounts
  - Timelocks

This creates an "unbreakable" vault: even with the spending key,
funds MUST flow through the pre-committed path.
No need for pre-signed transactions.
No trusted deletion of keys.

# Taproot vault key structure
internal_key = cold_pubkey  # Emergency recovery, no scripts revealed

script_tree = {
    "hot_delayed": """
        <144> OP_CSV OP_DROP
        <hot_pubkey> OP_CHECKSIG
    """,
    "watchdog_cancel": """
        <watchdog_pubkey> OP_CHECKSIG
        <hot_pubkey> OP_CHECKSIGADD
        OP_1 OP_NUMEQUAL
    """,
    "time_escape": """
        <52560> OP_CLTV OP_DROP  ← 1 year absolute timeout
        <cold_pubkey> OP_CHECKSIG
    """
}

# Key path: cold_pubkey signs directly → emergency spend, reveals nothing
# Script path 1: hot key after 144 blocks → normal operations
# Script path 2: watchdog OR hot key → cancel/sweep
# Script path 3: after 1 year → time-based recovery

Defense-in-depth vault security layers:

Layer 1: Hot key compromise
  → Attacker broadcasts Unvault tx
  → Watchtower detects in mempool (< 10 second latency)
  → Watchtower broadcasts Cancel tx (pre-signed, higher fee)
  → Funds re-locked in vault
  → Defender notified

Layer 2: Watchtower compromise + Hot key compromise
  → Attacker controls both; can complete unvault after delay
  → But cold key holder can also spend the vault directly
  → Race: attacker needs full delay period undetected
  → Cold storage can sweep during delay window

Layer 3: All hot infrastructure compromised
  → Only cold key remains
  → Cold storage sweep to new keys
  → Absolute timelock provides final fallback if cold key also lost

This is the security model that companies like Unchained Capital,
Casa, and institutional custodians implement in practice.