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
|
Return-Path: <thibaut-leguilly@garage.co.jp>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id AD74BC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 00:51:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 9435141704
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 00:51:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level:
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UC_GIBBERISH_OBFU=1]
autolearn=no 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 wJ7C2wfESXDZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 00:51:03 +0000 (UTC)
X-Greylist: delayed 00:05:34 by SQLgrey-1.8.0
Received: from mta02.mta.hdems.com (mta02.mta.hdems.com [52.199.63.161])
by smtp4.osuosl.org (Postfix) with ESMTPS id 932F441703
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 00:51:02 +0000 (UTC)
Received: from mo.hdems.com (unknown [10.5.20.57])
by mta02.mta.hdems.com ('HDEMS') with ESMTPSA id 4JkhhQ3gygz2K1r8l
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 00:45:26 +0000 (UTC)
X-HDEMS-MO-TENANT: garage.co.jp
Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com.
[209.85.208.69]) by gwsmtp.prod.mo.hdems.com with ESMTPS id
gwsmtpd-trans-ae28d5b4-60a5-4f96-a281-ab98b91ff06b
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jan 2022 00:45:25 +0000
Received: by mail-ed1-f69.google.com with SMTP id
k5-20020a508ac5000000b00408dec8390aso477048edk.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jan 2022 16:45:24 -0800 (PST)
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=zS9lLelH1foE2ef/5KQV2/bkWStnX16orG1dldZwTHI=;
b=ohxGAZFxPShP1M5C4eiGfsSzOw4nqHnXpivTM7BgIQI46m2rJu1QXD9LuFg0i3C91t
7NidqH9YXDovLW9Liu3E4wG8ahlquNHwQkAyWggeW73Ka6M3Pryz+p+EXNJuTW6AX8Js
AwbfwVol4zxFRP1DvF1q0r/t8a3OrDR1smm8xmG0jbpchh4Yyb7101RLQFV2rc/LiP8H
7GCyNeiKxRmZm0zp1UaZy+oeRlIkQvKi43bTzThUXbsqcuCTp6TqdOv6XaDDO+13qJhi
B8yO0Wtok6RMHcBpfvEbgJcsbVqlQO8iWCE8ftd2fIVwvZyy0g1NdXuqtd0q9qQjof1n
qSSA==
X-Gm-Message-State: AOAM530pIXp/8Ms9Usn8IAWiF6kbRTNX4HJ9Y0f/fe8gjZh0zI87cG+H
kP7pi+DobfLtScoActBYwpwJgNhhR/T0GDFRhMda5oF3y6/kuB4h7iYp/Kw4M/TMRXPSeqC1wi9
AbEyRZwNS5DzUY893xkW+eSwSSOFFzACXBBXNEd75yQmu+pYh1Wcax++LSZ88QoJaL8HHFi8Zne
xdhqOltfgC+wVaFlBXzLKEJYo8e7GwHKoZ4QnMjpDNee/bZ1dqDNvkVMwU2/A+nZpFXU40e+WCs
HObkphlgN48+YmqK1A3btBz/x024Zo7QVt9FTTVeec8ui6A3SJmiGhidC84HgW4n2yMeM6PJQDq
Sa3j5E+JHsvKvM0+Gz/LjX/nPcc=
X-Received: by 2002:a05:6402:4411:: with SMTP id
y17mr1394757eda.175.1643244323984;
Wed, 26 Jan 2022 16:45:23 -0800 (PST)
X-Google-Smtp-Source: ABdhPJyJ3B+zYITCBM1RpGHhO+6yuep2TyyFj9ensLz8fFjj3P52A+Tdsn6kS2AfNm7YDNRbK1SNX2k3UmDx4ipqNWw=
X-Received: by 2002:a05:6402:4411:: with SMTP id
y17mr1394740eda.175.1643244323745;
Wed, 26 Jan 2022 16:45:23 -0800 (PST)
MIME-Version: 1.0
References: <CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com>
<2b316504-f785-b1b3-9ff9-8d781d6c0d9b@gmail.com>
In-Reply-To: <2b316504-f785-b1b3-9ff9-8d781d6c0d9b@gmail.com>
From: Thibaut Le Guilly <thibaut@cryptogarage.co.jp>
Date: Thu, 27 Jan 2022 09:45:12 +0900
Message-ID: <CABPZDUyMmyt0UCmHYfm+s-zs=iLjxXB0VtdJZ64X5HA3XLFESA@mail.gmail.com>
To: Jonas Nick <jonasdnick@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000324bbe05d685a28d"
X-Mailman-Approved-At: Thu, 27 Jan 2022 08:59:30 +0000
Cc: dlc-dev@mailmanlists.org
Subject: Re: [bitcoin-dev] [dlc-dev] CTV dramatically improves DLCs
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: Thu, 27 Jan 2022 00:51:07 -0000
--000000000000324bbe05d685a28d
Content-Type: text/plain; charset="UTF-8"
Hi,
Lloyd, thanks for this excellent writeup. I must say that indeed using CTV
seems like it would very much lower the complexity of the DLC protocol (and
it seems like APO would also work, thanks Jonas for pointing that out).
Though thinking about it, I can't help wondering if the ideal op code for
DLC wouldn't actually be CHECKSIGFROMSTACK? It feels to me that this would
give the most natural way of doing things. If I'm not mistaken, this would
enable simply requiring an oracle signature over the outcome, without any
special trick, and without even needing the oracle to release a nonce in
advance (the oracle could sign `event_outcome + event_id` to avoid
signature reuse). I must say that I haven't studied covenant opcodes in
detail yet so is that line of thinking correct or am I missing something?
Cheers,
Thibaut
On Wed, Jan 26, 2022 at 1:27 AM Jonas Nick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Thank you, that's an interesting application of OP_CTV.
>
> Perhaps worth pointing out that this does not require OP_CTV but could
> also be
> enabled by other covenant constructions. For example, it seems like
> ANYPREVOUT-based covenants provide similar benefits. The script of the
> Taproot
> leaves could be set to
>
> <sig> <G> CHECKSIGVERIFY <CET_i> CHECKSIGVERIFY
>
> where <sig> is an ANYPREVOUTANYSCRIPT signature of the CET for public key
> P = G.
> When using nonce R = G, signature creation has negligible computational
> cost (s
> = 1 + H(R, P, m)). A downside compared to CTV is the additional overhead
> of 64
> witness bytes (<sig>).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000324bbe05d685a28d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>Lloyd, thanks for this excellent=C2=
=A0writeup. I must say that indeed using CTV seems like it would very much =
lower the complexity of the DLC protocol (and it seems like APO would also =
work, thanks Jonas for pointing that out). Though thinking about it, I can&=
#39;t help wondering if the ideal op code for DLC wouldn't actually be =
CHECKSIGFROMSTACK? It feels to me that this would give the most natural way=
of doing things. If I'm not mistaken, this would enable simply requiri=
ng an oracle signature over the outcome, without any special trick, and wit=
hout even needing the oracle to release a nonce in advance (the oracle coul=
d sign `event_outcome=C2=A0+ event_id` to avoid signature reuse). I must sa=
y that I haven't studied covenant=C2=A0opcodes in detail yet so is that=
line of thinking correct or am I=C2=A0missing something?</div><div><br></d=
iv><div>Cheers,</div><div><br></div><div>Thibaut</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 26, 2022=
at 1:27 AM Jonas Nick via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you, th=
at's an interesting application of OP_CTV.<br>
<br>
Perhaps worth pointing out that this does not require OP_CTV but could also=
be<br>
enabled by other covenant constructions. For example, it seems like<br>
ANYPREVOUT-based covenants provide similar benefits. The script of the Tapr=
oot<br>
leaves could be set to<br>
<br>
<sig> <G> CHECKSIGVERIFY <CET_i> CHECKSIGVERIFY<br>
<br>
where <sig> is an ANYPREVOUTANYSCRIPT signature of the CET for public=
key P =3D G.<br>
When using nonce R =3D G, signature creation has negligible computational c=
ost (s<br>
=3D 1 + H(R, P, m)). A downside compared to CTV is the additional overhead =
of 64<br>
witness bytes (<sig>).<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>
--000000000000324bbe05d685a28d--
|
