[prev in list] [next in list] [prev in thread] [next in thread]
List: bitcoin-dev
Subject: Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY
From: Jeremy Rubin via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date: 2022-06-24 18:05:50
Message-ID: CAD5xwhg5=L67BVfhoBh_Abwc_AsPx_9uO=Nbzx3F9spDxdd_LQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 #5 (text/html)]
<div dir="ltr"><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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.</div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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.</div><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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.</div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Best,</div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 23, 2022 at 11:06 \
PM Anthony Towns via bitcoin-dev <<a \
href="mailto:bitcoin-dev@lists.linuxfoundation.org" \
target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On \
Tue, May 10, 2022 at 08:05:54PM +0930, Rusty Russell via bitcoin-dev wrote:<br> <br>
> OPTX_SEPARATELY: treat fields separately (vs concatenating)<br>
> OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)<br>
<br>
> OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair<br>
> OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey<br>
<br>
Doing random pie-in-the-sky contract design, I had a case where I<br>
wanted to be able to say "update the CTV hash from commiting to outputs<br>
[A,B,C,D,E] to outputs [A,B,X,D,E]". The approach above and the one CTV<br>
takes are somewhat awkward for that:<br>
<br>
* you have to include all of A,B,D,E in order to generate both hashes,<br>
which seems less efficient than a merkle path<br>
<br>
* proving that you're taking an output in its entirety, rather than,<br>
say, the last 12 bytes of C and the first 30 bytes of D, seems hard.<br>
Again, it seems like a merkle path would be better?<br>
<br>
This is more of an upgradability concern I think -- ie, only relevant if<br>
additional features like CAT or TLUV or similar are added; but both OP_TX<br>
and CTV seem to be trying to take upgradability into account in advance,<br>
so I thought this was worth raising.<br>
<br>
Cheers,<br>
aj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" \
target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> <a \
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" \
rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic