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.
Instead of OP_VAULT
taking <revault-amount>
, have it take <unvault-amount>
. Drop <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>
Then create OP_REVAULT
which takes:
<revault-amount>
<revault-vout-idx>
and returns 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.