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
