BIP345 is in roughly final form, but why not dream a little more?
Here’s a small set of modifications I had proposed that would make the proposal slightly more flexible and interesting, at the cost of a few WU. James disagrees it’s necessary, but others might find it interesting to think about. A slight cleanup of OP_FORWARD_PARTIAL in my humble opinion.
<revault-amount>, have it take
<revault-vout-idx>. Instead of pushing
0x01 on the stack, have it push the minimally-encoded “residual” value of the input left over from
<unvault-amount> onto the stack. This residual will be fed directly into the next opcode…
OP_VAULT args are then just:
<leaf-update-script-body> <n-pushes> [ n leaf-update script data items ... ] <trigger-vout-idx>
OP_REVAULT which takes:
0x01 on success.
Typical usage looks like:
<revault-vout-idx> <trigger-vout-idx> <trigger-amt> [ n leaf-update script data items ... ] <n-pushes> <leaf-update-script-body> OP_VAULT OP_REVAULT
But now that these are split, we can do things like add partial collateral(by committing to additional VAULT opcodes):
<leaf-update-script-body> OP_VAULT OP_REVAULT <duplicated args to make sure it's same trigger output spk....> <collat-amt> OP_VAULT
by having multiple
OP_VAULT opcodes with the explicit amounts.
Or per-utxo-rate-limited unvaults(by committing to the unvaulting amount):
<deposit-delay> OP_CSV OP_DROP OP_DUP <max-val> OP_LEQ OP_VERIFY <leaf-update-script-body> OP_VAULT OP_REVAULT
with some additional math to break up “denominations” in the actual use-case.