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
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
|
Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7BF54C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Feb 2022 01:43:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 5774C8126B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Feb 2022 01:43:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id rBLGfWsMk2DA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Feb 2022 01:43:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com
[IPv6:2a00:1450:4864:20::22f])
by smtp1.osuosl.org (Postfix) with ESMTPS id EF2F281247
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 2 Feb 2022 01:43:50 +0000 (UTC)
Received: by mail-lj1-x22f.google.com with SMTP id c15so26652287ljf.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 01 Feb 2022 17:43:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=idIhFQG8mK/bicxh2Zi1T5SGNLeMWnjsgp25L2X2fhQ=;
b=M+WnUf+6sxCsvoIlLzWGXnDyndUanJv9F1ebaIIIGiW/CO7L3hfYKQEQVfNcv7bRlw
A8Yv1JyxAcAaMlPxvsFHEneoVN4FwCMKnfZSlnmObm3/iq6dzSEot9JDVkP37UyTURuA
7dtK6XXEZZnCUFdU2LvvWErkiNNm664tz0yW/9/gd0AtiHG93+iExjpCCjkxjgLxoQxx
lzUmSIWmPO7uuqzVaCSnJhSrA6NY/7JUrweV8y3JKS8OzF6QjM3kstAcbIWwdXlXjLEe
v5jxGTIyEWjckOPXNvBKTmLBFpqlFmx0906o39yx9fciQCmycahKlSwMkjhP6VYr7V+j
krlQ==
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=idIhFQG8mK/bicxh2Zi1T5SGNLeMWnjsgp25L2X2fhQ=;
b=2w1H9AVcnafVvvhfg7pGY+AHQa8MzmnVfeZtqG6o0q2uVTiE7TVZhES+ASbB3ANgCI
RcTsGkyzNKodHG4AVOypubJYkzEfX4mt2AhKDhYFYk5dbmQouJGI7WJY1NDqudrPdKIV
JcO+/vjvN9NVmWTU2m90NV9SRgEme3kog+fom7hHSMaK/STZr9nf+ZjKjRn1Mfk7l1C0
X3yR/3+LtisHLx/x6Mb//zbK6QByq2wHB18hiLBpZwWk3pYWSAYYHqtqvdXeAnenGppV
VmOV0h9xf7NGbptk4EJZKMhpDjn6pP/7e7ECmHlTIDXWJCTI1cxr8pF7jPN2pT23oTac
tSzw==
X-Gm-Message-State: AOAM5332WqVYR0OU7ZQEy2Y2eFWaWmi7y2q3NB2/5LjHqlQn8+0HRX0/
uBCrmaoV1GbwcbSuJUjhlrH+qsJYqPeJOhdlJHw=
X-Google-Smtp-Source: ABdhPJwvfWfPSrMfFqGnVFlIHCPBVsr8aoSLEjfSLl49yNWFNjnXUJ44qZd4XOfuJ23Ht3ayZM/HMv/uesT/bFYiNYc=
X-Received: by 2002:a2e:a5c3:: with SMTP id n3mr9911548ljp.212.1643766228660;
Tue, 01 Feb 2022 17:43:48 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhg-uxvJ4BCEeo5h2BxvCo87xwZ6r7cT-=u5PT9yskpbJQ@mail.gmail.com>
<20220202012849.GA5140@erisian.com.au>
In-Reply-To: <20220202012849.GA5140@erisian.com.au>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Tue, 1 Feb 2022 17:43:38 -0800
Message-ID: <CAD5xwhgCNbQkCMWRY_saAfQRXUXo7+DUHQkqv_um6UG_E0dNpA@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000027372905d6ff26b1"
Cc: Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] Why CTV, why now?
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, 02 Feb 2022 01:43:52 -0000
--00000000000027372905d6ff26b1
Content-Type: text/plain; charset="UTF-8"
I agree this emulation seems sound but also tap out at how the CT stuff
works with this type of covenant as well.
Happy hacking!
On Tue, Feb 1, 2022, 5:29 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Jan 05, 2022 at 02:44:54PM -0800, Jeremy via bitcoin-dev wrote:
> > CTV was an output of my personal "research program" on how to make simple
> > covenant types without undue validation burdens. It is designed to be the
> > simplest and least risky covenant specification you can do that still
> > delivers sufficient flexibility and power to build many useful
> applications.
>
> I believe the new elements opcodes [0] allow simulating CTV on the liquid
> blockchain (or liquid-testnet [1] if you'd rather use fake money but not
> use Jeremy's CTV signet). It's very much not as efficient as having a
> dedicated opcode, of course, but I think the following script template
> would work:
>
> INSPECTVERSION SHA256INITIALIZE
> INSPECTLOCKTIME SHA256UPDATEE
> INSPECTNUMINPUTS SCRIPTNUMTOLE64 SHA256UPDATE
> INSPECTNUMOUTPUTS SCRIPTNUMTOLE64 SHA256UPDATE
>
> PUSHCURRENTINPUTINDEX SCRIPTNUMTOLE64 SHA256UPDATE
> PUSHCURRENTINPUTINDEX INSPECTINPUTSEQUENCE SCRIPTNUMTOLE64 SHA256UPDATE
>
> { for <x> in 0..<numoutputs-1>
> <x> INSPECTOUTPUTASSET CAT SHA256UPDATE
> <x> INSPECTOUTPUTVALUE DROP SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
> <x> INSPECTOUTPUTNONCE SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE
> <x> INSPECTOUTPUTSCRIPTPUBKEY SWAP SIZE SCRIPTNUMTOLE64 SWAP CAT CAT
> SHA256UPDATE
> }
>
> SHA256FINALIZE <expectedhash> EQUAL
>
> Provided NUMINPUTS is one, this also means the txid of the spending tx is
> fixed, I believe (since these are tapoot only opcodes, scriptSig
> malleability isn't possible); if NUMINPUTS is greater than one, you'd
> need to limit what other inputs could be used somehow which would be
> application specific, I think.
>
> I think that might be compatible with confidential assets/values, but
> I'm not really sure.
>
> I think it should be possible to use a similar approach with
> CHECKSIGFROMSTACK instead of "<expectedhash> EQUAL" to construct APO-style
> signatures on elements/liquid. Though you'd probably want to have the
> output inspction blocks wrapped with "INSPECTNUMOUTPUTS <x> GREATERTHAN
> IF .. ENDIF". (In that case, beginning with "PUSH[FakeAPOSig] SHA256
> DUP SHA256INITIALIZE SHA256UPDATE" might also be sensible, so you're
> not signing something that might be misused in a different context later)
>
>
> Anyway, since liquid isn't congested, and mostly doesn't have lightning
> channels built on top of it, probably the vaulting application is the
> only interesting one to build on top on liquid today? There's apparently
> about $120M worth of BTC and $36M worth of USDT on liquid, which seems
> like it could justify some vault-related work. And real experience with
> CTV-like constructs seems like it would be very informative.
>
> Cheers,
> aj
>
> [0]
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
> [1] https://liquidtestnet.com/
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000027372905d6ff26b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I agree this emulation seems sound but also tap out at ho=
w the CT stuff works with this type of covenant as well.<div dir=3D"auto"><=
br></div><div dir=3D"auto">Happy hacking!</div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 1, 2022, 5:29 PM=
Anthony Towns via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">On Wed, Jan 05, 2022 at 02:44:54PM -0800=
, Jeremy via bitcoin-dev wrote:<br>
> CTV was an output of my personal "research program" on how t=
o make simple<br>
> covenant types without undue validation burdens. It is designed to be =
the<br>
> simplest and least risky covenant specification you can do that still<=
br>
> delivers sufficient flexibility and power to build many useful applica=
tions.<br>
<br>
I believe the new elements opcodes [0] allow simulating CTV on the liquid<b=
r>
blockchain (or liquid-testnet [1] if you'd rather use fake money but no=
t<br>
use Jeremy's CTV signet). It's very much not as efficient as having=
a<br>
dedicated opcode, of course, but I think the following script template<br>
would work:<br>
<br>
INSPECTVERSION SHA256INITIALIZE<br>
INSPECTLOCKTIME SHA256UPDATEE<br>
INSPECTNUMINPUTS SCRIPTNUMTOLE64 SHA256UPDATE<br>
INSPECTNUMOUTPUTS SCRIPTNUMTOLE64 SHA256UPDATE<br>
<br>
PUSHCURRENTINPUTINDEX SCRIPTNUMTOLE64 SHA256UPDATE<br>
PUSHCURRENTINPUTINDEX INSPECTINPUTSEQUENCE SCRIPTNUMTOLE64 SHA256UPDATE<br>
<br>
{ for <x> in 0..<numoutputs-1><br>
<x> INSPECTOUTPUTASSET CAT SHA256UPDATE<br>
<x> INSPECTOUTPUTVALUE DROP SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDAT=
E<br>
<x> INSPECTOUTPUTNONCE SIZE SCRIPTNUMTOLE64 SWAP CAT SHA256UPDATE<br>
<x> INSPECTOUTPUTSCRIPTPUBKEY SWAP SIZE SCRIPTNUMTOLE64 SWAP CAT CAT =
SHA256UPDATE<br>
}<br>
<br>
SHA256FINALIZE <expectedhash> EQUAL<br>
<br>
Provided NUMINPUTS is one, this also means the txid of the spending tx is<b=
r>
fixed, I believe (since these are tapoot only opcodes, scriptSig<br>
malleability isn't possible); if NUMINPUTS is greater than one, you'=
;d<br>
need to limit what other inputs could be used somehow which would be<br>
application specific, I think.<br>
<br>
I think that might be compatible with confidential assets/values, but<br>
I'm not really sure.<br>
<br>
I think it should be possible to use a similar approach with<br>
CHECKSIGFROMSTACK instead of "<expectedhash> EQUAL" to cons=
truct APO-style<br>
signatures on elements/liquid. Though you'd probably want to have the<b=
r>
output inspction blocks wrapped with "INSPECTNUMOUTPUTS <x> GREA=
TERTHAN<br>
IF .. ENDIF". (In that case, beginning with "PUSH[FakeAPOSig] SHA=
256<br>
DUP SHA256INITIALIZE SHA256UPDATE" might also be sensible, so you'=
re<br>
not signing something that might be misused in a different context later)<b=
r>
<br>
<br>
Anyway, since liquid isn't congested, and mostly doesn't have light=
ning<br>
channels built on top of it, probably the vaulting application is the<br>
only interesting one to build on top on liquid today? There's apparentl=
y<br>
about $120M worth of BTC and $36M worth of USDT on liquid, which seems<br>
like it could justify some vault-related work. And real experience with<br>
CTV-like constructs seems like it would be very informative.<br>
<br>
Cheers,<br>
aj<br>
<br>
[0] <a href=3D"https://github.com/ElementsProject/elements/blob/master/doc/=
tapscript_opcodes.md" rel=3D"noreferrer noreferrer" target=3D"_blank">https=
://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md=
</a><br>
[1] <a href=3D"https://liquidtestnet.com/" rel=3D"noreferrer noreferrer" ta=
rget=3D"_blank">https://liquidtestnet.com/</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000027372905d6ff26b1--
|
