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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id F01D1C007A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 23:02:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id D736C841CD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 23:02:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -3.402
X-Spam-Level:
X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Q4hGCFdyimtq
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 23:02:30 +0000 (UTC)
X-Greylist: delayed 04:23:09 by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [IPv6:2620:6e:a000:1::99])
by smtp1.osuosl.org (Postfix) with ESMTPS id E863A841B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Apr 2022 23:02:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mattcorallo.com; s=1650580863; h=In-Reply-To:From:References:Cc:To:Subject:
From:Subject:To:Cc:Reply-To; bh=3Kf3IUQCVjV+Q3ulNSTdDLxdLfi8itxHlhTBo49dD3w=;
b=V3LptXWrgcZu6t6PngJw77En+sNMwj8XTrhMK5zTT/jcumL/kNvKQOjCXXPkHW+B/C+EUfwa3MJ
mQ8LkZezfsHD2zhc5CMDM7CUdJQsWU6BHvqhuPdwq2MCAJ57+Tha7d6yQiaxXnBczSfCjzOB8k1Ak
nOLYN4jMwaXT8NjvC/NWQgBVgNnCWHuTOjoC4SchrzaloXV7Aj/VmJbs0EB0Yx0taHsSH5oTFN2JM
aqgZGyPEiMiPzu/fElsOHEARIv0IPa6qStomn9q3whrXJuPQkumVMxPM5J73rVSpA8z8YWlqbHWhY
KsOTtdi5SB3Aw+wtBMESrdzi15HdJRG7eT3Q==;
Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim)
(envelope-from <lf-lists@mattcorallo.com>)
id 1nhfog-000FCF-VN; Thu, 21 Apr 2022 23:02:27 +0000
Message-ID: <01d4a034-eb80-a598-1858-6b0ed8295a13@mattcorallo.com>
Date: Thu, 21 Apr 2022 16:02:26 -0700
MIME-Version: 1.0
Content-Language: en-US
To: "David A. Harding" <dave@dtrt.org>
References: <64a34b4d46461da322be51b53ec2eb01@dtrt.org>
<d95eec37-269d-eefb-d191-e8234e4faed3@mattcorallo.com>
<4b252ef6f86bbd494a67683f6113f3fe@dtrt.org>
<c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>
<4056eca7e1ff018bff03918b8c266d76@dtrt.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <4056eca7e1ff018bff03918b8c266d76@dtrt.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-DKIM-Note: Keys used to sign are likely public at
https://as397444.net/dkim/mattcorallo.com
X-DKIM-Note: For more info, see https://as397444.net/dkim/
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 23:02:31 -0000
On 4/21/22 3:28 PM, David A. Harding wrote:
> On 21.04.2022 08:39, Matt Corallo wrote:
>> We add things to Bitcoin because (a) there's some demonstrated
>> use-cases and intent to use the change (which I think we definitely
>> have for covenants, but which only barely, if at all, suggests
>> favoring one covenant design over any other)
>
> I'm unconvinced about CTV's use cases but others have made reasonable claims that it will be used.
> We could argue about this indefinitely, but I would love to give CTV proponents an opportunity to
> prove that a significant number of people would use it.
To be clear - I was not suggesting that CTV fell flat here. I think there *is* demand for Bitcoin
covenant designs, CTV included. I do *not* think there is demand for CTV *over* other covenant
designs, that's okay, though, it doesn't need that, we just have to be confident its the right
direction.
I believe you got the impression I was arguing CTV did not meet by criteria list (a)-(d), but in
fact I only think it falls flat horribly on (c).
>> (b) because its
>> generally considered aligned with Bitcoin's design and goals, based on
>> developer and more broad community response
>
> I think CTV fulfills this criteria. At least, I can't think of any way BIP119 itself
> (notwithstanding activation concerns) violates Bitcoin's designs and goals.
I tend to agree.
>> (c) because the
>> technical folks who have/are wiling to spend time working on the
>> specific design space think the concrete proposal is the best design
>> we have
>
> This is the criteria that most concerns me. What if there is no universal best? For example, I
> mentioned in my previous email that I'm a partisan of OP_CAT+OP_CSFS due to their min-max of
> implementation simplicity versus production flexibility. But one problem is that spends using them
> would need to contain a lot of witness data. In my mind, they're the best for experimentation and
> for proving the existence of demand for more optimized constructions.
I agree, there is no universal best, probably. But is there a concrete listing of a number of
use-cases and the different weights of things, plus flexibility especially around forward-looking
designs? You don't mention the lack of recursion in CTV vs CAT+CSFS, which is a *huge* difference in
the available design space for developers. This stuff is critical to get right and we're barely even
talking about it, let alone at a position of deciding something?
>> I do not see how we can make an argument for any specific covenant
>> under (c) here. 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".
>
> I'm curious how we as a technical community will be able to determine which is the best approach.
> Again, I like starting simple and general, gathering real usage data, and then optimizing for
> demonstrated needs. But the simplest and most general approaches seem to be too general for some
> people (because they enable recursive covenants), seemingly forcing us into looking only at
> application-optimized designs. In that case, I think the main thing we want to know about these
> narrow proposals for new applications is whether the applications and the proposed consensus changes
> will actually receive significant use. For that, I think we need some sort of test bed with real
> paying users, and ideally one that is as similar to Bitcoin mainnet as possible.
Again, you're writing off the real and nontrivial risk of doing a fork to begin with. You're also
writing off something organic that has happened without issue time and time again - a community of
independent contributors who care about Bitcoin working together to make decisions on what is or
isn't the "right way to go" is something we've all collaboratively done time and time again. Why are
you suggesting its something that you "don't know how to do"?
Again, my point *is not* "will people use CTV", I think they will. I think they would also use TLUV
if that were activated for the exact same use-cases. I think they would also use CAT+CSFS if that
were what was activated, again for the exact same use-cases. Given that, I'm not sure how your
proposal teaches us anything at all, aside from "yes, there was demand for *some* kind of covenant".
Matt
|
