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
|
Return-Path: <yanmaani@cock.li>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2B14DC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Mar 2021 21:39:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 0503D6F98C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Mar 2021 21:39:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 2.74
X-Spam-Level: **
X-Spam-Status: No, score=2.74 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347,
RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RDNS_NONE=0.793,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=cock.li
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id AVMpbNudiYLM
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Mar 2021 21:39:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.cock.li (unknown [37.120.193.123])
by smtp3.osuosl.org (Postfix) with ESMTPS id 29721606D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Mar 2021 21:39:44 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
t=1614807573; bh=FVlnGlzmfUTmHiFApzQPiVeTfqy2vl//dZE3MrHFFqE=;
h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
b=VQMXrCTpj14qR4rXKOHlEWHI8t7tPKODaKlpDsmXnsiJW0l6fZoi5Qdr1lkdnKdNk
H1NJkilgYNzzTBxmkq+O2iAvvIaphCtBS5JUA/CATwOFYvUd6BaS7aNd5uI6EBnEO9
t1oQ8diFNSfQ7uCndtOyLgv+g5bGh3GoUK0oDj/WNUMD1GonfJ8MDm0U5nNljTfpII
+q4nhhoLvparWUpURxISjR4J15yEVsbPmfQKVeYEjqbeRp8N/znoqUHWWVN4qnOc/S
SSKRUvSq1lRmUvpw0APlALctOSy2WU/Xd+SjeTeEOsHd7BsfzxsnOerA5AS/6hStUH
elrx8vNym0t3w==
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 03 Mar 2021 21:39:33 +0000
From: yanmaani@cock.li
To: Chris Belcher <belcher@riseup.net>
In-Reply-To: <839ee260-7ac0-9c78-5348-28e80b69799f@riseup.net>
References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>
<85745a38e4464541d6357408fae1cfed@cock.li>
<839ee260-7ac0-9c78-5348-28e80b69799f@riseup.net>
Message-ID: <4b89f7feb5d5442527644852188def49@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.15
X-Mailman-Approved-At: Wed, 03 Mar 2021 22:09:55 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot
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: Wed, 03 Mar 2021 21:39:48 -0000
On 2021-03-03 20:48, Chris Belcher wrote:
> On 03/03/2021 17:30, yanmaani@cock.li wrote:
>> Is that supposed to be a good thing? "We should do X because it'll
>> work"
>> doesn't prove X is actually good. These things can be evil, but they
>> can
>> also be legitimate opposition to a change. Taking away the power of a
>> "social media blitz" is not guaranteed to be a good thing!
> It is good that social media drama can only make its own followers fork
> away. In bitcoin people represent themselves, if they want certain
> rules
> enforced they should have to actually tell their software to do that.
> The problem with BIP8 is that social media drama has a incentive to
> promote brinksmanship.
Tell their software to do it, yes, but fork it? That seems like a big
"I'm sorry Dave, I'm afraid I can't do that" moment. If I tell Bitcoin
Core to do something, it seems like a bad thing that it would favor the
Core devs' wishes ("Get Taproot done") over mine.
>> That will only work for really egregious changes. In practice, most
>> people will trust Core on all other (non-egregious) decisions, because
>> of the inertia inherent in disobeying them.
[...]
>> You're right in suggesting that it will work, but the reason why it
>> will
>> work is because nobody wants to disobey Core. It seems immoral to
>> exploit this fact.
> It is not correct to say that this will work because "nobody will
> disobey Core". In reality it will work because basically everyone
> either
> wants taproot or has no opinion about taproot.
Both can be true at the same time. This is going to work because
basically nobody opposes Taproot. But if you did have some people
opposing Taproot, it would still work, because nobody would want to
disobey Core.
> Your argument depends heavily on the word "egregious". I've shown that
> for harmful changes like censorship can be resisted by the bitcoin
> community. Can you come up with an example of a bad change which won't
> be resisted?
Example 1: There is currently a specific mining pool planning to
blacklist addresses on sanctions lists. If they were to
convince/bribe/threaten Core to soft-fork so as to burn one specific
UTXO worth $1, the only direct victim of that would be the holder of
that UTXO, who loses only $1 from it.
Example 2: A soft fork to decrease the block size by 0.1%.
If we assume that the current block size is optimal and censorship is
bad, it seems simultaneously true that
1) it would be bad to decrease the block size or to burn that UTXO
2) nobody would be wiling to fight a war over a 0.1% decrease or a $1
loss to one guy
You might say that these are minor changes. Sure. But that's what I'm
saying: if the change is big ("egregious") enough to seriously
inconvenience people, they would fight it, but if it's trivial (thought
still bad), the inertia of Core would force them to accept it.
> Here's another example of an easily-resisted change: A Core team that's
> been compromised might do a flag-day UASF where transactions are only
> confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The
> community could resist this by doing a counter-UASF where a transaction
> paying just 1 sat/vbyte is required to be included in the first block
> after the flay day.
(Nitpick: Miners would probably not support it, because less people
would be willing to pay that fee.)
Sure, and this change would be resisted because it seriously
inconveniences people. But what if it's just 2sat/vbyte?
>> At least you shouldn't hard-code it and require dissenters to fork
>> away.
>> I exhort you to consider making all this controversial stuff settings
>> that can be changed by RPC command or command-line flag; set the
>> default
>> value sure, but requiring a fork to change it is, in my opinion,
>> oppressive.
> What alternative do you suggest? If you advocate allowing miners to
> activate soft forks then that still won't protect users. Because miners
> won't save users in my above example of a 1000 sat/vbyte price floor,
> in
> fact miners would see their income greatly increased if the soft fork
> was successful. So in fact the ability to do a counter-UASF is always
> what actually protected users, miner protection is nothing something to
> count on.
I don't disagree. The ability to do a counter-UASF should also be added,
if it's envisioned somebody might want to do that.
Basically, I think that Core should provide users with the tools to
express their views and to exercise their economic power, and they could
give them default values according to what they think best.
However, they shouldn't force people to use a forked client if they want
to disobey them. That would be to abuse the power vested in the
development group.
>> On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
>>> Enter flag day activation. With a flag day there can be no
>>> brinksmanship. A social media blitz cant do anything except have its
>>> own
>>> followers fork away. Crucially, miner signalling cant be used to
>>> change
>>> the activation date for nodes that didn't choose to and just
>>> passively
>>> follow signalling. Changing the activation date requires all those
>>> users
>>> to actually run different node software.
>>
>>
>>> What if one day the Core developer team uses the flag
>>> day method to do something bad? The bitcoin user
>>> community who wants to resist this can create their own
>>> counter-soft-fork full node. This forces a chain
>>> split. The real bitcoin which most people follow will be
>>> the chain without censorship.
>>
>> [edited for brevity]
>>
>>
>> What you suggest may be an efficient way to ram taproot through, but
>> is
>> it inherently good? Nothing is free. This seems like de-facto forcing
>> people to go along with you, because you're convinced you're right. In
>> this case, you are, but you'd be convinced you'd be right even if you
>> weren't so.
>>
>>
>>
>> (Also consider some compromise, such as ">95% miner support before
>> flag
>> day or >33% on flag day")
>>
>> Best wishes
>> Yanmaani
|