Greetings AJ,
Glad I could resurrect the idea!
> Then instead of `idx hash delay OP_TRIGGER_FORWARD` you
write `idx hash delay 2 "OP_CSV OP_DROP OP_FORWARD_OUTPUTS"
OP_FORWARD_LEAF_UPDATE`
Interesting idea! (I'll let you be the one to scope creep the proposal :) )
To be pedantic, EXPR_TRIGGER would become:
<trigger> <auth> <stuff> <spend-delay> <2> <OP_CSV OP_DROP OP_FORWARD_OUTPUTS> OP_FORWARD_LEAF_UPDATE
and at spend time the idx and hash are put into the witness stack.
To be clear, <spend-delay> could be embedded in the <script> too, right, making <2> a <1> in the above? Any reason for one or the other?
Another bonus from this is that you can introduce withdrawal authorization as well as part of the <script>. Current proposal has no withdrawal authorization, from what I understand. So each transition in a vault construct can have authorization, if it desires it.
> I do recognise that it makes it take a variable number of stack elements
though :)
Just when I thought I was out, they pulled me back in.
> I don't think replacing the internal-public-key makes sense -- if it
was immediately spendable via the keypath before there's no reason for
it not to be immediately spendable now.
Slavishly following the current proposal was the idea to make sure all functionality was captured; I agree with this change.
> Having OP_FORWARD_OUTPUTS not leave its input on the stack would let
you move the OP_CSV to the end and drop the OP_DROP too, saving 1 WU.
Previously setting CSV timeout to 0 would result in it not being satisfiable, if I'm understanding the suggestion correctly. I suppose this was a side-effect of having OP_UNVAULT take this value directly. Indeed with `OP_FORWARD_OUTPUTS` being split out there's not really a reason to use a 0 value?
> I think the existing OP_VAULT cleverness would work here, allowing you
to spend two inputs to the same output, accumulating their values.
Yes I think batching story should be same hopefully. I am assuming all the accounting OP_VAULT is doing is being done here. We match against the hash passed in, and fits into the "deferred checks" IIUC.
> OP_FORWARD_REFUND
Again, to be pedantic EXPR_TRIGGER becomes:
<trigger> <auth> <stuff> <spend-delay> <2> <OP_CSV OP_DROP OP_FORWARD_OUTPUTS> OP_FORWARD_LEAF_UPDATE OP_FORWARD_REFUND
Resulting in 2 more WU at spend time(for small idx). So up front committing to a refund path, perhaps with value explicitly passed in.
Totally forgot about the refund path; will need to mull the issue over, see how it interacts with BYOF schemes, etc.
Cheers,
Greg