Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY

[Jeremy Rubin <j@rubin.io>]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

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.

However, from an API perspective, I agree that a merkle tree could be
superior for CTV. It does depend on use case. If you have just, say, 3
outputs, a merkle tree probably just 'gets in the way' compared to the
concatenation. It is only when you have many outputs and your need to do a
random-index insertion that it adds value. In many applications, you might
be biased to editing the last output (e.g., change outputs?) and then
SHASTREAM would allow you to O(1) edit the tail.

Best,

Jeremy

On Thu, Jun 23, 2022 at 11:06 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> > OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey
>
> Doing random pie-in-the-sky contract design, I had a case where I
> wanted to be able to say "update the CTV hash from commiting to outputs
> [A,B,C,D,E] to outputs [A,B,X,D,E]". The approach above and the one CTV
> takes are somewhat awkward for that:
>
>  * you have to include all of A,B,D,E in order to generate both hashes,
>    which seems less efficient than a merkle path
>
>  * proving that you're taking an output in its entirety, rather than,
>    say, the last 12 bytes of C and the first 30 bytes of D, seems hard.
>    Again, it seems like a merkle path would be better?
>
> This is more of an upgradability concern I think -- ie, only relevant if
> additional features like CAT or TLUV or similar are added; but both OP_TX
> and CTV seem to be trying to take upgradability into account in advance,
> so I thought this was worth raising.
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4013 bytes --]