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
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
|
Return-Path: <rgrant@rgrant.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 48736C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 14:36:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 3126A8140F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 14:36:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
autolearn=ham autolearn_force=no
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 Ie8Eabk0AbUZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 14:36:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com
[209.85.217.42])
by smtp1.osuosl.org (Postfix) with ESMTPS id B24C0813A2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 14:36:53 +0000 (UTC)
Received: by mail-vs1-f42.google.com with SMTP id w124so16595747vsb.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 03 May 2022 07:36:53 -0700 (PDT)
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:cc:content-transfer-encoding;
bh=S6nboAGFTBNvDkYAiyuoZ1TvetYICXya/QuvAhh55Jc=;
b=uUbmlSgKgk1XmVKbznWhCfH0r/zCXolim9Kb6hkVyfPjryLfG7ulR6X0Eq7rvyqiHJ
kcwGmnSHskywGv5jOdLid8xF9MiKIkRGbr675OIKOuk1dAm2cXBiXyMz4mwm4gWVHwop
7BovFEwNf/yBfzdDo8tkTNOdKMbojl5QDTWC2cX/6yL7oeR1acfKhBVFHey4Cg7R2viH
JF0OgaMz8rl+li4/fIBuqCrBXd0jNEl5iNWF11NruF/l+R/FNg0TeYLg5LcFNz222Q8x
wMQNoTkicV0Sypi4KzoXM/lY4QXHr9xwL7FtzHoQFlyQsjA/8Sqg4TWz/v/idXBSgtg7
SxaA==
X-Gm-Message-State: AOAM530hRbE+zxZn8shk3TfgFq4SsAiHF9zLw/HwZvBvuDa3jGQ4tqJ7
2WAQHkFvdWyFC4rIHLQo6/ONeYkCtYrAgTXkd3NX/ZWMU6mww+V/
X-Google-Smtp-Source: ABdhPJzBNu4XZHebTRZ0eA3pWXGAL7hdP4a7g9RCBauxkVwmXSC6NJhomaoNjG9D9mdYC5DYI1AdK6HaVfg2Azq/gPs=
X-Received: by 2002:a05:6102:2333:b0:32c:e27c:b60b with SMTP id
b19-20020a056102233300b0032ce27cb60bmr5101462vsa.79.1651588611768; Tue, 03
May 2022 07:36:51 -0700 (PDT)
MIME-Version: 1.0
References: <EpwH6R7Ol7S4DZ4r_UcSSMU9RysZiRHFKZ2WkWZatUIeU9YE9avRZ-YIiafnf6I6U4tBbEu5xHa4JwcGh0fxMuyY-fGMwpaesfo5XK6SzLc=@protonmail.com>
<WtHCNGNhHAWBer9QnaWajdbJ341jMHQJa23WAPgNaRldKhopPIN7ry8wNAnmfnlAK6j0m7p3NEgckA6kIjWV5_rFla63Bh6HCfAlLHFODsE=@protonmail.com>
<CABm2gDrQXbS=i8j+Ja5PTgYekyH2X06eTOs8SXP8X-dhTy-hiQ@mail.gmail.com>
In-Reply-To: <CABm2gDrQXbS=i8j+Ja5PTgYekyH2X06eTOs8SXP8X-dhTy-hiQ@mail.gmail.com>
From: Ryan Grant <bitcoin-dev@rgrant.org>
Date: Tue, 3 May 2022 14:36:15 +0000
Message-ID: <CAMnpzfoLTecKQPmdDv7B=_JKgh1LZr_K5aahZ6JA5CsGbvomkA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] What to do when contentious soft fork activations
are attempted
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: Tue, 03 May 2022 14:36:55 -0000
On Sun, May 1, 2022 at 8:49 PM Jorge Tim=C3=B3n via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <bitcoin-dev@lists.li=
nuxfoundation.org> wrote:
>> [...] Andreas is clueless about BIP 119 and other covenant
>> proposals. He is spreading misinformation and [...]
> Clueless and spreading disinformation, you say? What
> misinformation, could you explain?
First, OP_CTV covenants cannot restrict any address that the sender
does not control. OP_CTV just delivers auditable presigned
transactions. That's it! OP_CTV's primary design constraint is to
NOT empower new ways to do blacklists (which are already possible
using unwanted-multisig). That's not a statement about what Bitcoin
should ultimately become, but rather what Bitcoin is likely ready for.
Much like Bitcoin's design, the simplest possible covenant solution
was chosen, so that it would be "dirt simple" to audit that the code
does only what it should, and no more.
Andreas used a few words of indecision to make excuses for not
code-reviewing BIP119 or the pull request, while using a lot of words
talking about: how dangerous any change is; conservative consensus
process; and GovCoin blacklists. This gave the strong impression that
the change was dangerous and could easily lead to the creation of
blacklists enforced by L1 consensus itself (rather than enforced by
other signers in a sidechain or unwanted-multisig).
Andreas also didn't look into the reason that the proposed client was
safe and would not cause a chain split. Speedy Trials by themselves
don't risk chain splits, they poll. There was no UASF in the planned
executable. Some devs hate ST because it puts the initiative in
miner's hands to gauge **user support and readiness** - which those
devs feel the miners have no reason to be good at - but that expires
speedily. If everyone loved the change and the trial was about to
pass, except ornery users - who we love when UASF is needed, of
course - were going to cause a chain split of their own to block it,
then ST offers miners the capability to - very quickly, faster than a
release can be pushed out - change their signaling to again prevent a
chain split.
Russell O'Connor wrote the definitive explanation for how ST arose in
the consensus process and how it was designed to make everyone
unhappy. It's a great explanation of what we went through last year.
https://r6.ca/blog/20210615T191422Z.html
"On Building Consensus and Speedy Trial"
on | 2021-06-15T19:14:22Z
by | Russell O'Connor
Andreas also didn't look for a non-attack reason for a separate binary
release. (Here I feel like I should be naming a lot of devs as well,
hmm.) Let's go back to O'Connor, who reminds us of a faction from the
last consensus change:
> The "devs-do-not-decide" faction's concern is regarding the
> appearance of Bitcoin developers deciding the rules of Bitcoin.
> [...] This faction would be fine with users building their own
> alternative client for forced activation, or a configuration flag
> for enabling some kind of forced activation that is not enabled by
> default.
Maintainers of the repository and "Big Name" devs have very personal
reasons to take this stance. Meanwhile, devs who want to form an
opinion on some given matter but who do not want to do their own code
reviews typically look to Big Name code reviewers for guidance, in a
"Consensus Beauty Contest" [note_kbc]. Contrast this with everyone
who restricts their opinion-formation to their own review of the code;
they are "Doing Consensus Right", rather than being stuck in the
Beauty Contest. Now, if a "devs-do-not-decide" dev wrote some code,
they implicitly reviewed their own code, right? But! If they did not
write that code, then they **must avoid it** ...in proportion to how
much it affects consensus. According to this theory of Bitcoin's
consensus, we would **expect** Big Names to be partly missing from the
OP_CTV code reviews. This confuses people who are used to playing the
Consensus Beauty Contest.
[note_kbc:] for another game about what everybody else thinks,
see Keynesian beauty contest:
https://en.wikipedia.org/wiki/Keynesian_beauty_contest
(The connection is funny to me because we all have to individually
play this game when deciding what money is, and in so doing pay a
last homage to Keynes, during our multi-generational exit from his
eponymous economics of manipulated interest rates.)
Jimmy Song, in a video best fitting the advocacy referred to by
Michael (who did not give any specific link), claims that the OP_CTV
review process is "routing around" some Big Names. Jimmy is seemingly
unaware that some Big Names are explicitly not participating in
guiding what Bitcoin's consensus should be, and that some are even
using strategic ambiguity to do so. With the context above, we have a
much less nefarious interpretation of motive for releasing a
binary - one that is part of the consensus process.
https://www.youtube.com/watch?v=3Di5VNiiCYnIg
"Bitcoin Brief - BIP119, Mexico CBDC & Bitcoin's Role in Russia vs
Ukraine!"
on | Apr 25, 2022
(mark 1:13:52.0) Jimmy Song
(mark 1:18:00.0) "routing around"
An alternative client must, by necessity, offer both its consensus
feature and its activation. Releasing an alternative client is not a
decision made from impatience and disrespect. It=E2=80=99s the result of
asking everyone, getting literal non-responses, and intuiting that the
landscape has changed, so something on this path must be different
from last time. While the alternative client route surprised me when
I heard about it, I cannot say that I personally knew of any other way
to advance what has clearly been a blocked discussion, and so I did
not disassociate myself from the effort. People do not understand how
blocked up consensus is, and no dev has verbalized a better solution
for maintainers than strategic ambiguity, which is most confusing when
it is delivering only silence.
The typical alternative offered by other devs is, "Wait." Well, this
"Wait" has almost always meant "Never." Take a look at CSFS and APO.
They've been waiting, but for what? What's the bug that BIP authors
can't fix? Where's the concrete pull request? Who is going to anoint
them as done? OP_CTV has made its rite of passage and transcended
these questions. Its only competition is whether something better can
be imagined, but those arguments need to explain why learning from a
good opcode in the meantime is worth waiting years to work through new
safety concerns. If any of this matters, then timing matters, too.
OP_CTV is sitting at the front of the bus.
Personally, I suspect that the "something better" crowd wants
recursive covenants, yet recognizes the argument is difficult and
would have put it off in a sense of misplaced priorities, but we'll
find out soon. If there were some kind of assurance that could be
offered, something that would result in a less contentious soft fork,
instead of stonewalling resistance that makes all soft forks more
contentious, then a later "epsilon" upgrade to covenants would be
easier instead of harder. This is because everyone who believes that
recursive covenants are not a new threat to Bitcoin could argue
towards a common purpose and resolve that in a binding consensus
agreement. One such binding mechanism could be parties committing
matched coins locked under a future opcode, although this would be an
extreme departure from typical development and incur massive risk to
the parties if for other reasons phase two of the initiative fails.
It's too bad the game theory isn't simpler.
Finally, Andreas summarized the conservatism in his position as
basically, "If you want scripting and contracts, go buy ETH." Which
is offensive to everyone trying to make bitcoins more protective of
individual freedom and thus more valuable; whether you're working on
scaling and privacy, the Lightning Network, Discreet Log Contracts,
CoinPool covenants, self-custody vault covenants, building out Taproot
capabilities, or working on other infrastructure. What a clueless
shitcoiner!
https://www.youtube.com/watch?v=3DvAE5fOZ2Luw
"BIP119, EU regulatory attack, El Salvador, and much more in Q&A
with aantonop (April 2022)"
on | Apr 24, 2022
by | aantonop
(mark 30:34.0) "if you want to do smart contracts..."
The path to redemption in the Bitcoin community is to unequivocally
help Bitcoin.
Jeremy wasn't always Bitcoin-only, but his efforts have been sincere
and he works in the concrete realm where anyone can judge how pure his
contributions are. Even if OP_CTV is never activated, or if no
covenant opcode is ever activated, Bitcoin is much more secure due to
the critical bug fixes that Jeremy has already seen merged just
planning ahead for a mempool that could handle dependent transactions.
Bitcoin was never under attack or at risk of harm from Jeremy's
actions to advance the covenants discussion.
Andreas is welcome to research technical merits better before
communicating, and to discover how a vision of powerful contract
covenants - in the most decentralized money that exists - can affect
people's freedom. In so doing, join us.
|
