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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id C02AFC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Mar 2022 15:45:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 9863040A2B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Mar 2022 15:45:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5
tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=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 bIFjlt6n0_HI
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Mar 2022 15:45:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp2.osuosl.org (Postfix) with ESMTPS id 2F55A40A22
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 15 Mar 2022 15:45:58 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1nU9Mv-0002BK-9R; Wed, 16 Mar 2022 01:45:55 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Wed, 16 Mar 2022 01:45:49 +1000
Date: Wed, 16 Mar 2022 01:45:49 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@jtimon.cc>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220315154549.GA7580@erisian.com.au>
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
<CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
<CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
<CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Speedy Trial
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, 15 Mar 2022 15:45:59 -0000
On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> > Thirdly, if some users insist on a chain where taproot is
> > "not activated", they can always softk-fork in their own rule that
> > disallows the version bits that complete the Speedy Trial activation
> > sequence, or alternatively soft-fork in a rule to make spending from (or
> > to) taproot addresses illegal.
> Since it's about activation in general and not about taproot specifically,
> your third point is the one that applies.
> Users could have coordinated to have "activation x" never activated in
> their chains if they simply make a rule that activating a given proposal
> (with bip8) is forbidden in their chain.
> But coordination requires time.
People opposed to having taproot transactions in their chain had over
three years to do that coordination before an activation method was merged
[0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].
[0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
trial activation parameters for mainnet and testnet were merged.
[1] 2021-11-14
For comparison, the UASF activation attempt for segwit took between 4
to 6 months to coordinate, assuming you start counting from either the
"user activated soft fork" concept being raised on bitcoin-dev or the
final params for BIP 148 being merged into the bips repo, and stop
counting when segwit locked in.
> Please, try to imagine an example for an activation that you wouldn't like
> yourself. Imagine it gets proposed and you, as a user, want to resist it.
Sure. There's more steps than just "fork off onto a minority chain"
though.
1) The first and most important step is to explain why you want to
resist it, either to convince the proposers that there really is
a problem and they should stand down, or so someone can come up
with a way of fixing the proposal so you don't need to resist it.
Ideally, that's all that's needed to resolve the objections. (That's
what didn't happen with opposition to segwit)
2) If that somehow doesn't work, and people are pushing ahead with a
consensus change despite significant reasonable opposition; the next
thing to do would be to establish if either side is a paper tiger
and setup a futures market. That has the extra benefit of giving
miners some information about which (combination of) rules will be
most profitable to mine for.
Once that's setup and price discovery happens, one side or the other
will probably throw in the towel -- there's not much point have a
money that other people aren't interested in using. (And that more
or less is what happened with 2X)
If a futures market like that is going to be setup, I think it's
best if it happens before signalling for the soft fork starts --
the information miners will get from it is useful for figuring out
how much resources to invest in signalling, eg. I think it might even
be feasible to set something up even before activation parameters are
finalised; you need something more than just one-on-one twitter bets
to get meaningful price discovery, but I think you could probably
build something based on a reasonably unbiassed oracle declaring an
outcome, without precisely defined parameters fixed in a BIP.
So if acting like reasonable people and talking it through doesn't
work, this seems like the next step to me.
3) But maybe you try both those and they fail and people start trying
to activate the soft fork (or perhaps you just weren't paying
attention until it was too late, and missed the opportunity).
I think the speedy trial approach here is ideal for a last ditch
"everyone stays on the same chain while avoiding this horrible change"
attempt. The reason being that it allows everyone to agree to not
adopt the new rules with only very little cost: all you need is for
10% of hashpower to not signal over a three month period.
That's cheaper than bip9 (5% over 12 months requires 2x the
cumulative hashpower), and much cheaper than bip8 which requires
users to update their software
4) At this point, if you were able to prevent activation, hopefully
that's enough of a power move that people will take your concerns
seriously, and you get a second chance at step (1). If that still
results in an impasse, I'd expect there to be a second, non-speedy
activation of the soft fork, that either cannot be blocked at all, or
cannot be blocked without having control of at least 60% of hashpower.
5) If you weren't able to prevent activation (whether or not you
prevented speedy trial from working), then you should have a lot
of information:
- you weren't able to convince people there was a problem
- you either weren't in the economic majority and people don't
think your concept of bitcoin is more valuable (perhaps they
don't even think it's valuable enough to setup a futures market
for you)
- you can't get control of even 10% of hashpower for a few months
and your only option is to accept defeat or create a new chain.
Since your new chain won't have a hashpower majority, you'll likely
have significant problems if you don't hard fork in a change to
how proof-of-work works; my guess is you'd either want to switch
to a different proof-of-work algorithm, or make your chain able
to be merge-mined against bitcoin, though just following BCH/BSV's
example and tweaking the difficulty adjustment to be more dynamic
could work too.
(For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
merge-mining, are apparently at 68%, 42% and 17% respectively)
At the point that you're doing a hard fork, making a clean split is
straightforward: schedule the hard fork for around the same time as
the start of enforcement of the soft fork you oppose, work out how
to make sure you're on your own p2p network, and figure out how
exchanges and lightning channels and everything else are going to
cope with the coin split.
6) There's potentially also the case where a soft fork locks-in
and later everyone realises the people who were opposing it were
right all along and the fork is a really bad idea.
If everyone agreed that some idea was irredeemably bad -- eg,
OP_VERIF -- then we could soft fork them out and just forbid
blocks/transactions that attempt to use them. Or conceivably we could
do a hardfork and have more options about how to fix the problem.
That's already true for various features that satoshi included and
that are still available today -- eg the CHECKMULTISIG bug where
it pops one too many things from the stack, or the timewarp bug,
or CODESEP/FindAndDelete validation complexity.
Those can be complicated to fix though; if people have lost their
private keys and are sitting on (timelocked?) pre-signed transactions,
even fixing the problem via a hard fork could cause loss of funds.
But those are really progressively worse options -- just talking to each
other and solving the problem before it's a problem is a better approach
than risking money on futures markets; and that's better than having to
buy hashpower to try to block something that other people want; and that's
better than forking the chain; and even that's better than doing things
that might cause irretrievable loss of funds from random other bitcoiners.
Cheers,
aj
|
