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
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1FDD9C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Jul 2021 18:40:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 0E57A40163
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Jul 2021 18:40:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 nwChe_b3KMf5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Jul 2021 18:39:59 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp2.osuosl.org (Postfix) with ESMTPS id 94AC7400C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Jul 2021 18:39:58 +0000 (UTC)
Received: from mail-io1-f51.google.com (mail-io1-f51.google.com
[209.85.166.51]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 164IduET026899
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 4 Jul 2021 14:39:57 -0400
Received: by mail-io1-f51.google.com with SMTP id k16so18358047ios.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 04 Jul 2021 11:39:57 -0700 (PDT)
X-Gm-Message-State: AOAM530v5N54gVRo3k4C5cSmud4HQSgnzMgm1Hls60Qz4tL/IvPM/dZB
YwE1hItXgZAxkXvUwIcqh1lC8sAutq9UrT3G1Qo=
X-Google-Smtp-Source: ABdhPJzZXwVKZ36jciUl3R31xp6/nfY/450hrFDTsVpMouh5P7htMPBsXScOD8vc70lVfAaUZr6yNhw5a4ROUVeqypM=
X-Received: by 2002:a05:6602:89c:: with SMTP id
f28mr8702870ioz.170.1625423996333;
Sun, 04 Jul 2021 11:39:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
<20210704011341.ddbiruuomqovrjn6@ganymede>
In-Reply-To: <20210704011341.ddbiruuomqovrjn6@ganymede>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 4 Jul 2021 11:39:44 -0700
X-Gmail-Original-Message-ID: <CAD5xwhimPBEV_tLpSPxs9B+XGUhvPx_dnhok=8=hyksyi4=B6g@mail.gmail.com>
Message-ID: <CAD5xwhimPBEV_tLpSPxs9B+XGUhvPx_dnhok=8=hyksyi4=B6g@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000e931db05c65083bb"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
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: Sun, 04 Jul 2021 18:40:00 -0000
--000000000000e931db05c65083bb
Content-Type: text/plain; charset="UTF-8"
>
> Do you have concerns about sophisticated covenants, and if so, would you
> mind describing them?
Personally, not in particular worried about arbitrary covenants as I think
that: 1 validation costs can be kept in check; 2 you're free to burn your
coins it you want to.
I *do* care that when we enable covenants we don't make people jump through
too many hoops, but I also respect Russel's points that we can enable
functionality and then later figure out how to make it more efficient or
useful guided by use cases.
However, I think the broader community is unconvinced by the cost benefit
of arbitrary covenants. See
https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
as a recent example. Therefore as a critical part of building consensus on
various techniques I've worked to emphasize that specific additions do not
entail risk of accidentally introducing more than was bargained for to
respect the concerns of others.
>
> I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2],
> but it seems artificially limited without OP_CAT. (I also stand by my
> answer on that survey of believing there's a deep lack of developer
> interest in CSFS at the moment. But, if you'd like to tilt at that
> windmill, I won't stop you.)
Well if you're a fan of it, I'm a fan of it, Russel's a fan of it, and
Sanket's a fan of it that sounds like a good amount of dev interest :) I
know Olaoluwa is also a fan of it too and has some cool L2 protocols using
it.
I think it might not be *hype* because it's been around a while and has
always been bundled with cat so been a non starter for the reasons above. I
think as an independent non-bundle it's exciting and acceptable to a number
of devs. I also believe upgrades can be developed and tracked in parallel
so I'm taking on the windmill tilting personally to spearhead that -- on
the shoulders of Giants who have been creating specs for this already of
course.
Best,
Jeremy
P.s. icymi https://rubin.io/blog/2021/07/02/covenants/ covers my current
thinking about how to proceed w.r.t. deploying and developing covenant
systems for bitcoin
--000000000000e931db05c65083bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Do you have concerns about sophisticated covenants, and if so, would =
you<br>
mind describing them?=C2=A0</blockquote></div></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Personally, not in particular worried about arbitrar=
y covenants as I think that: 1 validation costs can be kept in check; 2 you=
're free to burn your coins it you want to.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">I *do* care that when we enable covenants we don=
9;t make people jump through too many hoops, but I also respect Russel'=
s points that we can enable functionality and then later figure out how to =
make it more efficient or useful guided by use cases.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">However, I think =
the broader community is unconvinced by the cost benefit of arbitrary coven=
ants. See=C2=A0<a href=3D"https://medium.com/block-digest-mempool/my-worrie=
s-about-too-generalized-covenants-5eff33affbb6">https://medium.com/block-di=
gest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6</a> as=
a recent example. Therefore as a critical part of building consensus on va=
rious techniques I've worked to emphasize that specific additions do no=
t entail risk of accidentally introducing more than was bargained for to re=
spect the concerns of others.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
I'm a fan of CSFS, even mentioning it on zndtoshi's recent survey[2=
],<br>
but it seems artificially limited without OP_CAT.=C2=A0 (I also stand by my=
<br>
answer on that survey of believing there's a deep lack of developer<br>
interest in CSFS at the moment.=C2=A0 But, if you'd like to tilt at tha=
t<br>
windmill, I won't stop you.)</blockquote></div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Well if you're a fan of it, I'm a fan o=
f it, Russel's a fan of it, and Sanket's a fan of it that sounds li=
ke a good amount of dev interest :) I know Olaoluwa is also a fan of it too=
and has some cool L2 protocols using it.=C2=A0</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">I think it might not be *hype* because it's bee=
n around a while and has always been bundled with cat so been a non starter=
for the reasons above. I think as an independent non-bundle it's excit=
ing and acceptable to a number of devs. I also believe upgrades can be deve=
loped and tracked in parallel so I'm taking on the windmill tilting per=
sonally to spearhead that -- on the shoulders of Giants who have been creat=
ing specs for this already of course.=C2=A0</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Best,</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">Jeremy</div><div dir=3D"auto"><br></div><div dir=3D"auto">P.s. icymi <a h=
ref=3D"https://rubin.io/blog/2021/07/02/covenants/">https://rubin.io/blog/2=
021/07/02/covenants/</a> covers my current thinking about how to proceed w.=
r.t. deploying and developing covenant systems for bitcoin</div><div dir=3D=
"auto"></div></div>
--000000000000e931db05c65083bb--
|
