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