summaryrefslogtreecommitdiff
path: root/ff/69fe319f9dfb0a5f46ac8bf49fce51b3373bf5
blob: d3d02c9379be73fbdd03dea87e805a2fbd0124e2 (plain)
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
Return-Path: <roconnor@blockstream.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 48CDFC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Feb 2022 04:10:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 22D9240154
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Feb 2022 04:10:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key)
 header.d=blockstream-com.20210112.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id c9RfzDuggnm4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Feb 2022 04:10:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com
 [IPv6:2607:f8b0:4864:20::835])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 8D9D84010E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Feb 2022 04:10:31 +0000 (UTC)
Received: by mail-qt1-x835.google.com with SMTP id x5so968900qtw.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 20:10:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=1B+P4Tqvusqq09myjyArp4VCoy7juVeKJSrg7CaUcOA=;
 b=jMC3XLzjB5MsGsHKw5pPZMMhcMhAnirICjaYqGgJhOcEMpS4jYFdUvEbdthhhh19HG
 4I7pOsuoVTgVMB9oLKdgAoRvtMAP9FCc/fGTgAtRKXLLT2Qqd8Dy/tQSFs8owkKbC+/A
 HpXSga/ZApgyx/+QywG3NhrqqkTV09hSHbwBmCUg7luql6P9FgftMhwvl/g2y0fYLSqZ
 AQdOBSNE+6t8eEw9mbpgCqjBLOYrLPwLIhKwsQ71efJFsbLTEuXFlMY3dKt5C3G2i8/d
 /vszjmerJWJ82pIWuGPFiV8RxaN1Y95B+jJBmZodhsD/7nw0Pc/xsCUYFRn7PGubROcR
 pkmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=1B+P4Tqvusqq09myjyArp4VCoy7juVeKJSrg7CaUcOA=;
 b=XW/ArXGFfoeSrIrFin9ODxBMBRbJGCigPq6fvuAaQe12l+PBoNBV7OWcRUxJ2Q8CEH
 6g9QpM5DeJ3sGoDb77RfwbQTW99fSluVXbaiSfEy0oTpTuPU2R9frS8z1kWLqjNAme8S
 bJ/HL/nSkehjyQSQPnEOe4DzAPjurY0G4tbIPCV2SEmR35tpKVtXmoQwEoTkDggmr3im
 Ms7kPD2RHcV9iKVeQaKQs0NaxI3Ce9Jfh16yHuY+uPJiv9Gz5nMXhgfqaoj4AZEGI5eS
 2MkAixYmp3YKf1+AiAKsvh5QwKbaB1nkk6Mdt1u7BtJn/qnDwaLDY9v37hqZ4h54krGI
 2d5w==
X-Gm-Message-State: AOAM5326RWED4OcBkkomXe++jZS729wLXZ7lyllMAh8VVBFtYNZjlFra
 vmRZEHYialxnuB5u9cBsVzux4Mv+NZ2lL144BQ9+IdpOA4Q=
X-Google-Smtp-Source: ABdhPJyTahjbMqDR0aJDu8WeZ7aTTgOqLOCNn+AGCt8a9Ws0PY5UAHmx2BZ+YEJGrTwkxZL/KaZ/GSma2RFLuhOmJPo=
X-Received: by 2002:a05:622a:592:b0:2dc:ed48:7a54 with SMTP id
 c18-20020a05622a059200b002dced487a54mr683141qtb.289.1644984630246; Tue, 15
 Feb 2022 20:10:30 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <87leymuiu8.fsf@rustcorp.com.au>
 <CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com>
 <87k0dwr015.fsf@rustcorp.com.au>
 <CAD5xwhi4y1NiZ__c1WY-rCV3XBzN5yxY1Zox6Mc1FTjxUhXK9A@mail.gmail.com>
 <87a6err1h5.fsf@rustcorp.com.au>
In-Reply-To: <87a6err1h5.fsf@rustcorp.com.au>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 15 Feb 2022 23:10:19 -0500
Message-ID: <CAMZUoKm3vQDOQ1PiMBhyJz+m9G+RsDSvZ0k-QwoW5+HMbkUOQw@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary="0000000000008c1a8905d81ad4c4"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV
	and ANYPREVOUT
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: Wed, 16 Feb 2022 04:10:33 -0000

--0000000000008c1a8905d81ad4c4
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell <rusty@rustcorp.com.au>
wrote:

> Jeremy Rubin <jeremy.l.rubin@gmail.com> writes:
> > Hi Rusty,
> >
> > Please see my post in the other email thread
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
> >
> > The differences in this regard are several, and worth understanding
> beyond
> > "you can iterate CTV". I'd note a few clear examples for showing that
> "CTV
> > is just as powerful" is not a valid claim:
> >
> > 1) CTV requires the contract to be fully enumerated and is non-recursive.
> > For example, a simple contract that allows n participants to take an
> action
> > in any order requires factorially many pre-computations, not just linear
> or
> > constant. For reference, 24! is about 2**80. Whereas for a more
> > interpretive covenant -- which is often introduced with the features for
> > recursion -- you can compute the programs for these addresses in constant
> > time.
> > 2) CTV requires the contract to be fully enumerated: For example, a
> simple
> > contract one could write is "Output 0 script matches Output 1", and the
> set
> > of outcomes is again unbounded a-priori. With CTV you need to know the
> set
> > of pairs you'd like to be able to expand to a-priori
> > 3) Combining 1 and 2, you could imagine recursing on an open-ended thing
> > like creating many identical outputs over time but not constraining what
> > those outputs are. E.g., Output 0 matches Input 0, Output 1 matches
> Output
> > 2.
>
> Oh agreed.  It was distinction of "recursive" vs "not recursive" which
> was less useful in this context.
>
> "limited to complete enumeration" is the more useful distinction: it's a
> bright line between CTV and TXHASH IMHO.
>

If TXHASH is limited to requiring the flags be included in the hash (as is
done with sighash) I believe TXHASH has the same "up front" nature that CTV
has.

--0000000000008c1a8905d81ad4c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell &lt;<a href=3D"mailto=
:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Jeremy Rubin &lt;<a href=3D"ma=
ilto:jeremy.l.rubin@gmail.com" target=3D"_blank">jeremy.l.rubin@gmail.com</=
a>&gt; writes:<br>
&gt; Hi Rusty,<br>
&gt;<br>
&gt; Please see my post in the other email thread<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
2-February/019886.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html</a><br>
&gt;<br>
&gt; The differences in this regard are several, and worth understanding be=
yond<br>
&gt; &quot;you can iterate CTV&quot;. I&#39;d note a few clear examples for=
 showing that &quot;CTV<br>
&gt; is just as powerful&quot; is not a valid claim:<br>
&gt;<br>
&gt; 1) CTV requires the contract to be fully enumerated and is non-recursi=
ve.<br>
&gt; For example, a simple contract that allows n participants to take an a=
ction<br>
&gt; in any order requires factorially many pre-computations, not just line=
ar or<br>
&gt; constant. For reference, 24! is about 2**80. Whereas for a more<br>
&gt; interpretive covenant -- which is often introduced with the features f=
or<br>
&gt; recursion -- you can compute the programs for these addresses in const=
ant<br>
&gt; time.<br>
&gt; 2) CTV requires the contract to be fully enumerated: For example, a si=
mple<br>
&gt; contract one could write is &quot;Output 0 script matches Output 1&quo=
t;, and the set<br>
&gt; of outcomes is again unbounded a-priori. With CTV you need to know the=
 set<br>
&gt; of pairs you&#39;d like to be able to expand to a-priori<br>
&gt; 3) Combining 1 and 2, you could imagine recursing on an open-ended thi=
ng<br>
&gt; like creating many identical outputs over time but not constraining wh=
at<br>
&gt; those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Ou=
tput<br>
&gt; 2.<br>
<br>
Oh agreed.=C2=A0 It was distinction of &quot;recursive&quot; vs &quot;not r=
ecursive&quot; which<br>
was less useful in this context.<br>
<br>
&quot;limited to complete enumeration&quot; is the more useful distinction:=
 it&#39;s a<br>
bright line between CTV and TXHASH IMHO.<br></blockquote><div><br></div><di=
v>If TXHASH is limited to requiring the flags be included in the hash (as i=
s done with sighash) I believe TXHASH has the same &quot;up front&quot; nat=
ure that CTV has.<br></div></div></div>

--0000000000008c1a8905d81ad4c4--