I can't find a link, but I've discussed this before somewhere a while
ago... perhaps one of the IRC meetings? I'll see if I can't turn something
up.
The main reason not to was validation performance -- we already usually
compute the flat hash, so the merkle tree would be extra work for just CTV.
On Tue, May 10, 2022 at 08:05:54PM +0930, Rusty Russell via bitcoin-dev wrote:
> OPTX_SEPARATELY: treat fields separately (vs concatenating)
> OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)
> OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair
>
Hi Rusty,
One of the common sentiments thats been expressed over the last few months
is that more people want to see experimentation with different applications
using covenants. I really like this proposal because in addition to
offering a cleaner upgrade/extension path than adding “CTV++” as a
Hi Rusty,
Thanks for this. Seems like a productive direction to explore.
To me, one of the biggest limitations of CTV is that the script is
specific to the amount of the input being spent. OP_TX makes it
possible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be
combined with CTV
Hi all,
TL;DR: a v1 tapscript opcode for generic covenants, but
OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an
obvious use case, with clean future expansion. OP_NOP4 can be
repurposed in future as a shortcut, if experience shows that to be a
useful optimization.
