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
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 99E4CC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 16:28:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 795A74187E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 16:28:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.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 eIEorEwEWy6h
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 16:28:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com
[IPv6:2607:f8b0:4864:20::231])
by smtp4.osuosl.org (Postfix) with ESMTPS id 31D9A416FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 16:28:55 +0000 (UTC)
Received: by mail-oi1-x231.google.com with SMTP id q129so9601783oif.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Apr 2022 09:28:54 -0700 (PDT)
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;
bh=9FYJK0w35QIE9EPfFaIjBaYBcHD5CrA2rkprlEdvNKk=;
b=iopnPwvOCc2DHWiV4uQGg4QIrqeUqbf1grxxy/2zGQLQrMcHeQEMGUiMeEPEunKWMu
C0R26sUW4r5v0aBPynmxr1FMyjHPAJbMy/HmlAhyTo68xxxTHAEZQuTs+QfTgv8AdyiC
+qppENjrWyJgNfJxax6G0FTO//FB7+lAx8DFtbqKSNjIP5BKmh9Cxfloo+jjhpB8b3Gv
Mja4UmUt9SxOpq08x/kbAYgr+tJyg5n/XPdl3F6ljHXA30wPD+PXxhsE5hsN89OlM8Ba
ipPSTJUpZHU6vKg5j34HlJkjCi/xXfiqFNtftI3m19NzgTk00CQO/i/tTIKdCUnNiBR9
n4/A==
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=9FYJK0w35QIE9EPfFaIjBaYBcHD5CrA2rkprlEdvNKk=;
b=gIvLRQ9tpzMT4xBaGjBmKl40dlljtvy3z1ZjHlgybukY05C9G/Xl6+4SWB6azvkAGG
7ARLyTdtS10HUJxWoGXZvkwFyzGE++xc5B/OutYkANK9K1iXBYeUwbyWEzqmLscXT5xD
ukaDxRm3kLQ0l76O2a6av24jOhp0wWSSXURQTURIyHdKa8sRd7ALwfXHX4GGiR8csKq6
eYd8EHRoT0Z6YocWDchHmE/YT9kIVekaIyefsBC4WipFWxeg4XC6ttxd3rLFkCRHsocB
0vL/f8b+hnE+gUmkCw1onge7CWgC2JCGmCopJaRLfxM5Irs/DeRWlLGQBF7Ft0jPPQBA
fHrA==
X-Gm-Message-State: AOAM531R6/ACotkjYXpWXQPZx2+nJx7elrI6OIEgIpAh2TixbepWWF1e
8wDUW0LLmzv8oyQn9MbqHv29x/HHedptKpk3QAg28NybST3Y/Q==
X-Google-Smtp-Source: ABdhPJwQzJquFmylYQL10b/auC1oPWbyq9HObqvlVAYPxNwfYl4FzjuKjbXps74ndQ9rzhUT9vixCrWNb3N29oc7Gsk=
X-Received: by 2002:a05:6808:1788:b0:322:eae3:5d3c with SMTP id
bg8-20020a056808178800b00322eae35d3cmr2735687oib.222.1650644934075; Fri, 22
Apr 2022 09:28:54 -0700 (PDT)
MIME-Version: 1.0
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
<d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
<4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
<c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
In-Reply-To: <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Fri, 22 Apr 2022 12:28:42 -0400
Message-ID: <CAPfvXfJe6YHViquT8i+Kq2QUjZDZyUq24nKkJd2a6dYKgygxNQ@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f2298905dd40b85e"
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks,
e.g. for CTV
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: Fri, 22 Apr 2022 16:28:56 -0000
--000000000000f2298905dd40b85e
Content-Type: text/plain; charset="UTF-8"
> There are at least three or four separate covenants designs that have
> been posted to this list, and I don't see why we're even remotely
> talking about a specific one as something to move forward with at
> this point.
To my knowledge none of these other proposals (drafts, really) have
actual implementations, let alone the many sample usages that exist for
CTV. Given that the "covenants" discussion has been ongoing for years
now, I think the lack of other serious proposals is indicative of the
difficulty inherent in coming up with a preferable alternative to CTV.
Each covenant proposal aside from CTV has seemed either abstruse and
handwavy to me (TLUV, OP_EVICT) or general to the point of
being hard to analyze for safety (CAT) or encourages
witness verbosity that seems wasteful (OP_TX[HASH]).
CTV is about as simple a covenant system as can be devised - its limits
relative to more "general" covenant designs notwithstanding.
The level of review around CTV's design is well beyond the other
sketches for possible designs that this list has seen.
> We could just as well be talking about
> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
> CTV can probably just as easily use those instead - ie this has
> nothing to do with "will people use it".
This vault design (https://github.com/jamesob/simple-ctv-vault)
is a good benchmark for evaluating covenant proposals because it's (i)
simple and (ii) has high utility for many users of Bitcoin. I would
love to see it implemented in one or all of these alternatives, but I
am almost certain no one will do it in the next few months because the
implementations, tooling, and in some cases even complete
specifications do not exist.
Why that is after years of discussion and the utility of
covenants being widely appreciated is indicative to me.
--000000000000f2298905dd40b85e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">> There are at least three or four sep=
arate covenants designs that have<br>> been posted to this list, and I d=
on't see why we're even remotely<br>> talking about a specific o=
ne as something to move forward with at<br>> this point.<br><br>To my kn=
owledge none of these other proposals (drafts, really) have<br>actual imple=
mentations, let alone the many sample usages that exist for<br>CTV. Given t=
hat the "covenants" discussion has been ongoing for years<br>now,=
I think the lack of other serious proposals is indicative of the<br>diffic=
ulty inherent in coming up with a preferable alternative to CTV.<br><br>Eac=
h covenant proposal aside from CTV has seemed either abstruse and<br>handwa=
vy to me (TLUV, OP_EVICT) or general to the point of<br>being hard to analy=
ze for safety (CAT) or encourages<br>witness verbosity that seems wasteful =
(OP_TX[HASH]).<br><br>CTV is about as simple a covenant system as can be de=
vised - its limits<br>relative to more "general" covenant designs=
notwithstanding.<br>The level of review around CTV's design is well be=
yond the other<br>sketches for possible designs that this list has seen.</d=
iv><div dir=3D"ltr"><br> </div><div dir=3D"ltr">> We could just as well =
be talking about<br>> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone =
who is going to use<br>> CTV can probably just as easily use those inste=
ad - ie this has<br>> nothing to do with "will people use it".=
<br><br>This vault design (<a href=3D"https://github.com/jamesob/simple-ctv=
-vault">https://github.com/jamesob/simple-ctv-vault</a>)<br>is a good bench=
mark for evaluating covenant proposals because it's (i)<br>simple and (=
ii) has high utility for many users of Bitcoin. I would<br>love to see it i=
mplemented in one or all of these alternatives, but I<br>am almost certain =
no one will do it in the next few months because the<br>implementations, to=
oling, and in some cases even complete <br></div><div dir=3D"ltr">specifica=
tions do not exist.<br><br>Why that is after years of discussion and the ut=
ility of<br>covenants being widely appreciated is indicative to me.<br></di=
v><br></div>
--000000000000f2298905dd40b85e--
|
