From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 98F3FC002D for ; Fri, 24 Jun 2022 18:06:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 65B2B41A19 for ; Fri, 24 Jun 2022 18:06:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 65B2B41A19 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNuSRBhUE-_q for ; Fri, 24 Jun 2022 18:06:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2C9E9417AB Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) by smtp4.osuosl.org (Postfix) with ESMTPS id 2C9E9417AB for ; Fri, 24 Jun 2022 18:06:04 +0000 (UTC) Received: (Authenticated sender: j@rubin.io) by mail.gandi.net (Postfix) with ESMTPSA id 1D640240003 for ; Fri, 24 Jun 2022 18:06:01 +0000 (UTC) Received: by mail-lj1-f180.google.com with SMTP id c30so3600342ljr.9 for ; Fri, 24 Jun 2022 11:06:01 -0700 (PDT) X-Gm-Message-State: AJIora/wwT+MMSAuV5gFwwVFW2BZ3YwrTiX++RpS6ZGNO614cwvacheH PAjoZMZjY/3yUpIuTdsVrV/8Sk4ymjz8Ao7MX/g= X-Google-Smtp-Source: AGRyM1tFSdkNqbYWLfDx1K8mFeJmdmZwm0dsEh6HRcjsjDUh/2iNFhsz2PuUtAEPHDU9uKQp20RNNA39AZHtZCFnOsw= X-Received: by 2002:a05:651c:1502:b0:25a:8c33:5935 with SMTP id e2-20020a05651c150200b0025a8c335935mr117540ljf.246.1656093961250; Fri, 24 Jun 2022 11:06:01 -0700 (PDT) MIME-Version: 1.0 References: <87h75xoet1.fsf@rustcorp.com.au> <20220624060605.GC5322@erisian.com.au> In-Reply-To: <20220624060605.GC5322@erisian.com.au> From: Jeremy Rubin Date: Fri, 24 Jun 2022 11:05:50 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Anthony Towns , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000466c9b05e2356cb4" X-Mailman-Approved-At: Fri, 24 Jun 2022 18:09:09 +0000 Subject: Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2022 18:06:09 -0000 --000000000000466c9b05e2356cb4 Content-Type: text/plain; charset="UTF-8" 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 > --000000000000466c9b05e2356cb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can't find a link, = but I've discussed=C2=A0this before somewhere a=C2=A0while ago... perha= ps one of the IRC meetings? I'll see if I can't turn something up.<= /div>

The main reason not to was validation performance -- we already usual= ly compute the flat hash, so the merkle tree would be extra work for just C= TV.

However, from an API perspective, I agree that a merkle tree coul= d 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 m= ight 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 <bitc= oin-dev@lists.linuxfoundation.org> wrote:
= On Tue, May 10, 2022 at 08:05:54PM +0930, Rusty Russell via bitcoin-dev wro= te:

> OPTX_SEPARATELY: treat fields separately (vs concatenating)
> OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before pus= h)

> 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 output= s
[A,B,C,D,E] to outputs [A,B,X,D,E]". The approach above and the one CT= V
takes are somewhat awkward for that:

=C2=A0* you have to include all of A,B,D,E in order to generate both hashes= ,
=C2=A0 =C2=A0which seems less efficient than a merkle path

=C2=A0* proving that you're taking an output in its entirety, rather th= an,
=C2=A0 =C2=A0say, the last 12 bytes of C and the first 30 bytes of D, seems= hard.
=C2=A0 =C2=A0Again, 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/mail= man/listinfo/bitcoin-dev
--000000000000466c9b05e2356cb4--