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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3EA98C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 May 2022 13:32:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 17A5F41600
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 May 2022 13:32:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Level:
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
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 nqhHrjCrQey6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 May 2022 13:32:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com
[IPv6:2a00:1450:4864:20::130])
by smtp4.osuosl.org (Postfix) with ESMTPS id C207A4099C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 May 2022 13:32:28 +0000 (UTC)
Received: by mail-lf1-x130.google.com with SMTP id y32so18828949lfa.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 14 May 2022 06:32:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=T0yt0t95LhtTCMY40PgTZ0LASflnc7+ySrFoDLyRaFI=;
b=j2hrl7KDoDdelDP0zJKE8eERw8i0BdNjR1KU9shGHdeVN9vFbDfD6T24itV5VOI7FV
f4AySLdGsUtsxUo6Lyk8++RZTecWkPIM0kGFs67mBoyHAa8Mg6sYpGT2s9bKs3i4BIb5
m1eGR0wZcbrhtdgNwvXaXmR/lUvgxhP2LIseR257iXipa5t3t36caumH5z3cehsa++TB
V7dyLS08OD18BUfGKmxh22FILS6WxRYlepOBWA1aImZlVKKDmBoeI6z6z5cro6qxFW+2
CuQ07//UXMxxj1g47K6FOK6PmdlS2cVJzY2Kaau1M81Q3EnexOubnbNz3FYkmirHxpVU
L2bw==
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;
bh=T0yt0t95LhtTCMY40PgTZ0LASflnc7+ySrFoDLyRaFI=;
b=kEghyQlyM+6Qe2CUiQuaedpBv7o71Nwqb8lQy5DVuSXpRph8f5P7LXIFsTwANom/sO
O5dp37ncYBzbDejm/MoXOxXx//euwt1BJLYe9SbRiqga3FB+GLpoQGWAiQ9pD43ZzCNU
MzfelEQTmhvABj+dQ4K/rOAlZQILo6YfTsOH1VkSExfOKtxo+iTRBTrn8TyIGo5BoKHl
lQrHOtfR7dTVDwCwNaQziy2Z8dEsAiqkGMVQJd6mgorvW6/GRoYavLjVn7IV01qvxywm
yLgqFnapqcgjk34fTd9obr26gfyEO5cleUa2A8CfVfX1tLO/EqwMJxo5girSgOf3YxYO
pU4w==
X-Gm-Message-State: AOAM531qdK9d9ct3xHqzPy9Z2f25WTn+8vJQ3FXuIm2/CY+n+7jIAbk6
AE5NEXCLi0lriAVhrGhYiFiLv174O27Y9g+V6gh48XI=
X-Google-Smtp-Source: ABdhPJwaZgXJYox95KL/zVkudwm9nut/DWDhG2qYRiEEz+TLdVy1y9VLNAZm1vrNrhjgzj4blwyV/l1nwUrOiigFFCc=
X-Received: by 2002:a05:6512:3045:b0:473:d457:1541 with SMTP id
b5-20020a056512304500b00473d4571541mr6796618lfb.308.1652535146455; Sat, 14
May 2022 06:32:26 -0700 (PDT)
MIME-Version: 1.0
References: <161946014-482cdec305e2bd7a2c3fc4774c70239d@pmq1v.m5r2.onet>
<M80pb4TxcE1yCMCW4IboyTtx8MSvp8m9tphXe2EYvIvcrcf2Wzsn4ManJw8EP_ri-ohqtIOPrEaw7XkUcTO3lfVSLN4WMUwpromwzLm15Kc=@protonmail.com>
<CAMZUoKnzjcYDM-mOhT00P7YO18YmjxRkYsfO6QFtYFn0mEtLQw@mail.gmail.com>
<fkMEju1kNN5OJPoI1d2K99sV0bhr7qeAnhVbv-99K_UL48YQyHp-rbqEfQ81crx-thaA8JuUY4-eFlYUskvFC_8h6DIhdF0Wj-v-4DNnlcI=@protonmail.com>
<CAMZUoKmhOpt2N+6YxxREMzmRca2hNnPHBMRMsT09efkEs0CJiQ@mail.gmail.com>
<20220513214347.GA2463@erisian.com.au>
<CAMZUoK=stZaPcTNfC_KdOxbQp=VyORwC3osSm3sTeQ0WZ4ejYQ@mail.gmail.com>
In-Reply-To: <CAMZUoK=stZaPcTNfC_KdOxbQp=VyORwC3osSm3sTeQ0WZ4ejYQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Sat, 14 May 2022 09:32:18 -0400
Message-ID: <CAJowKgKfy7-2UsBoypHmPkGnMb5V+m7Mt3ek5scsEHwj0YW9wA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000062277605def8d20e"
X-Mailman-Approved-At: Sat, 14 May 2022 14:24:07 +0000
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
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: Sat, 14 May 2022 13:32:30 -0000
--00000000000062277605def8d20e
Content-Type: text/plain; charset="UTF-8"
>
>
>
> FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle
> messages and pubkey delegation. The ability to covenants would be
> secondary and would mostly serve to get us some real user data about what
> sort of covenants users find especially valuable.
>
I don't think this should be discounted. I think it's worthwhile to
willingly include possibly less-than-awesome, but proven perfectly-safe
opcodes, knowing we will have to validate them forever, even if new, cooler
and more widely-used ones replace them years from now.
I honestly don't think the development of the latter will happen without
some version of the former.
Personally I am satisfied:
- the safety of covenants, in general, is covered by how addresses are
generated
- fears of forced forward-encumbrance are not any worse than can be
easily done today
- ctv+apo, cat+csfs are fine, but we should pick ones that everyone
thinks are "good enough for everyone who cares about them"
- they are not an undue burden on nodes in terms of
validate-cpu-cycles-per-byte (have we proven this?)
- the complexity is low, code is easy to validate
- won't introduce DDOS attack vectors (also needs to be proven i think?)
- the game theory underpinning selfish miner support of the chain won't
be altered by causing a widespread use of on-chain leveraging instruments
(shorting bitcoin on-chain would be dangerous, for example)
>
--00000000000062277605def8d20e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br><br=
></div><div>FWIW, I think the rmain reasons to do CAT+CSFS is to validate o=
racle messages and pubkey delegation.=C2=A0 The ability to covenants would =
be secondary and would mostly serve to get us some real user data about wha=
t sort of covenants users find especially valuable.<br></div></div></div></=
blockquote><div><br></div><div>I don't think this should be discounted.=
=C2=A0 =C2=A0I think it's worthwhile to willingly include possibly less=
-than-awesome, but proven perfectly-safe opcodes, knowing we will have to v=
alidate them forever, even if new, cooler and more widely-used ones replace=
them years from now.</div><div><div><br></div><div>I honestly don't th=
ink the development of the latter will happen without some version of the f=
ormer.=C2=A0</div></div><div><br></div><div>Personally I am satisfied:</div=
><div><br></div><div>=C2=A0 - the safety of covenants, in general, is cover=
ed by how addresses are generated</div><div>=C2=A0 - fears of forced forwar=
d-encumbrance are not any worse than can be easily done today=C2=A0</div><d=
iv>=C2=A0 - ctv+apo, cat+csfs are fine, but we should pick ones that everyo=
ne thinks are "good enough for everyone who cares about them"</di=
v><div>=C2=A0 - they are not an undue burden on nodes in terms of validate-=
cpu-cycles-per-byte (have we proven this?)</div><div>=C2=A0 - the complexit=
y is low, code is easy to validate</div><div>=C2=A0 - won't introduce=
=C2=A0DDOS attack vectors (also needs to be proven i think?)</div><div>=C2=
=A0 - the game theory underpinning selfish miner support of the chain won&#=
39;t be altered by causing a widespread use of on-chain leveraging instrume=
nts (shorting bitcoin on-chain would be dangerous, for example)=C2=A0</div>=
<div><br></div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><br>
</blockquote></div></div>
--00000000000062277605def8d20e--
|
