AJ/Greg-ish OP_VAULT rework

rework.md

Required opcodes

• OP_VAULT: spent to trigger withdrawal
• OP_VAULT_RECOVER: spent to recover
• OP_CTV: spent into final withdrawal target

Initial deposit

Output structure

  tr(key, {$expr_recovery, $expr_trigger, ...(?)})

where

  $expr_recovery = 
   [<opt.> <recovery> <auth>] <recovery sPK hash> OP_VAULT_RECOVER

  $expr_trigger  = 
    <trigger> <auth> <script> <spend-delay> OP_VAULT

Triggering a withdrawal request

Witness structure

Witness contains

• Taproot script-spend path to $expr_trigger.
• <trigger-vout-idx>: indicates trigger output (described below)

Output structure

  tr(key, {$expr_recovery, $expr_withdraw, ...(?)})

where

  $expr_recovery is preserved exactly
  $expr_withdraw = 
    <spend-delay> OP_CSV OP_DROP <target-outputs-hash> OP_CTV

Rules

• Sum amount of all OP_VAULT inputs with matching $expr_recovery values must be reflected in <trigger-vout-idx>

  • deferred check for cross-input aggregation
  • supports batching

• <trigger-vout-idx> must correspond to an output that is the input taptree, but with the spent tapleaf (OP_VAULT) swapped out for the timelocked CTV constructed using <target-outputs-hash> and <spend-delay> as extracted from the spent tapleaf

  • key is preserved
  • recovery tapleaf is preserved

Withdrawal

Happens via script-path spend to $expr_withdraw, i.e. a timelocked CTV.

Recovery

Can happen from any of the above outputs using the $expr_recovery script path in a way very similar to the existing OP_VAULT proposal.

Note that OP_VAULT_RECOVER is necessitated (vs. something more general) because of recovery batching: a vault-unique rule is that recovery-compatible outputs can be recovered together into a single output.