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
|
Return-Path: <dave@dtrt.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9A47EC002C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 18:06:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 80919409E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 18:06:18 +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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, 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 9EUbV-Aiy5Fn
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 18:06:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [208.79.240.5])
by smtp2.osuosl.org (Postfix) with ESMTPS id 4C0F5409DD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 18:06:17 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id D7EDA280005E;
Thu, 21 Apr 2022 11:06:14 -0700 (PDT)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Thu, 21 Apr 2022 11:06:14 -0700 (PDT)
MIME-Version: 1.0
Date: Thu, 21 Apr 2022 08:06:14 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
<d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 6918.62619d16.d3665.0
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Thu, 21 Apr 2022 18:06:18 -0000
On 21.04.2022 04:58, Matt Corallo wrote:
> On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
>> The main criticisms I'm aware of against CTV seem to be along the
>> following lines:
>>
>> 1. Usage, either:
>> a. It won't receive significant real-world usage, or
>> b. It will be used but we'll end up using something better later
>> 2. An unused CTV will need to be supported forever, creating extra
>> maintenance
>> burden, increasing security surface, and making it harder to
>> evaluate later
>> consensus change proposals due to their interactions with CTV
>
> Also "is this even the way we should be going about covenants?"
I consider this to be a version of point 1b above. If we find a better
way for going about covenants, then we'll activate that and let CTV
automatically be retired at the end of its five years.
If you still think your point is separate from point 1b, I would
appreciate you helping me understand.
> the Bitcoin technical community (or at least those interested in
> working on covenants) doesn't even remotely show any signs of
> consensus around any concrete proposal,
This is also my assessment: neither CTV nor any other proposal currently
has enough support to warrant a permanent change to the consensus rules.
My question to the list was whether we could use a transitory soft fork
as a method for collecting real-world usage data about proposals. E.g.,
a consensus change proposal could proceed along the following idealized
path:
- Idea (individual or small group)
- Publication (probably to this list)
- Draft specification and implementation
- Riskless testing (integration tests, signet(s), testnet, etc)
- Money-at-stake testing (availability on a pegged sidechain, an altcoin
similar to Bitcoin, or in Bitcoin via a transitory soft fork)
- Permanent consensus change
> talking about a "way forward for CTV" or activating CTV or coming up
> with some way of shoving it into Bitcoin at this stage [...] sets
> incredibly poor precedent for
> how we think about changes to Bitcoin and maintaining Bitcoin's
> culture of security and careful design.
How should we think about changes to Bitcoin and maintaining its culture
of security and careful design? My post suggested a generalized way we
could evaluate proposed consensus changes for real-world demand,
allowing us to settle what I see as the most contended part of the CTV
proposal. That feels to me like legitimate engineering and social
consensus building. What would be your preferred alternatives?
(For the record, my preferred alternative for years has been to add the
technically trivial opcodes OP_CAT and OP_CHECKSIGFROMSTACK, see what
covenant-y things people build with them, and then consider proposals to
optimize the onchain usage of those covenant-y things. Alas, this seems
to fall afoul of the concerns held by some people about recursive
covenants.)
> I'm gobsmacked that the conversation has reached this point, and am
> even more surprised that the response from the Bitcoin (technical)
> community hasn't been a more resounding and complete rejection of this
> narrative.
If the only choices are to support activation of BIP119 CTV at this time
or to reject it, I would currently side with rejection. But I would
prefer over both of those options to find a third way that doesn't
compromise safety or long-term maintainability and which gives us the
data about CTV (or other covenant-related constructions) to see whether
the concerns described above in 1a and 1b are actually non-issues.
I see one of those third ways as the testing on the CTV signet described
in a contemporaneous thread on this list.[1] Other third ways would be
trying CTV on sidechains or altcoins, or perhaps allowing CTV to be
temporarily used on Bitcoin as proposed in this thread. Is there
interest in working on those alternatives, or is the only path forward
an argument over attempting activation of CTV?
Thanks,
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html
|
