annoying stack magic
This cases is mostly a bit of OP_XDUP overhead which just so happens to enable a feature. Something special-cased that doesn’t need it will require interpreter-wide state to know where the value should be going which is what I was attempting to avoid in the first place with the replacement of OP_FORWARD_PARTIAL. I’m not sold that collateral should be a first-class citizen, just interesting that a potentially useful feature is possible with little additional spec complexity(I’d argue the complexity is a lateral move myself).
The problem with that is collateral specification isn’t so simple - do you want to require x BTC per input being unvaulted, or for a single unvault operation? Or maybe you want to be able to specify a percentage of the amount that has to be locked for collateral?
Yeah this is where we’re definitely at the limit of Bitcoin Script. We’d essentially be re-implementing OP_DIV et al just implicitly, maybe side-stepping CScriptNum arithmetic issues by doing it implicitly. Percentage-based rate-limiting of unvaults would also be great, and I could imagine it being used in many other contexts if it was a more general-purpose widget.
Limits of Bitcoin Script, Simplicity right meow, you know the drill