1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
|
Return-Path: <j@rubin.io>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 98F3FC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jun 2022 18:06:01 +0000 (UTC)
Received: by mail-lj1-f180.google.com with SMTP id c30so3600342ljr.9
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <j@rubin.io>
Date: Fri, 24 Jun 2022 11:05:50 -0700
X-Gmail-Original-Message-ID: <CAD5xwhg5=L67BVfhoBh_Abwc_AsPx_9uO=Nbzx3F9spDxdd_LQ@mail.gmail.com>
Message-ID: <CAD5xwhg5=L67BVfhoBh_Abwc_AsPx_9uO=Nbzx3F9spDxdd_LQ@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">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><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000">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.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000">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.</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000">Best,</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Thu, Jun 23, 2022 at 11:06 PM Anthony Towns via bitcoin-dev <<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-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 wro=
te:<br>
<br>
> OPTX_SEPARATELY: treat fields separately (vs concatenating)<br>
> OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before pus=
h)<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 output=
s<br>
[A,B,C,D,E] to outputs [A,B,X,D,E]". The approach above and the one CT=
V<br>
takes are somewhat awkward for that:<br>
<br>
=C2=A0* you have to include all of A,B,D,E in order to generate both hashes=
,<br>
=C2=A0 =C2=A0which seems less efficient than a merkle path<br>
<br>
=C2=A0* proving that you're taking an output in its entirety, rather th=
an,<br>
=C2=A0 =C2=A0say, the last 12 bytes of C and the first 30 bytes of D, seems=
hard.<br>
=C2=A0 =C2=A0Again, 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<b=
r>
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=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000466c9b05e2356cb4--
|
