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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 28890C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Apr 2022 17:00:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 16AC260A69
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Apr 2022 17:00:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 1gGM9hLf_12H
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Apr 2022 17:00:20 +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 smtp3.osuosl.org (Postfix) with ESMTPS id CB59B60797
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Apr 2022 17:00:19 +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 1nj24N-00059g-Tn; Tue, 26 Apr 2022 03:00:17 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Tue, 26 Apr 2022 03:00:12 +1000
Date: Tue, 26 Apr 2022 03:00:12 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Keagan McClelland <keagan.mcclelland@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220425170012.GA7453@erisian.com.au>
References: <CABm2gDoC5Y=o6Vu7urzBoioVmXBf+YBLg95w-kupx9nidRDBPg@mail.gmail.com>
<20220326014546.GA12225@erisian.com.au>
<CABm2gDpMxN0sBCpcbmvYsQbdsGp=JRjAyLhsd6BWyAxdCY95+A@mail.gmail.com>
<20220330042106.GA13161@erisian.com.au>
<CABm2gDrsZ9ZimFTkNrdj+wr7328h2N2GmRCawq8xYv3BqyHNow@mail.gmail.com>
<20220411130522.GA3633@erisian.com.au>
<CABm2gDqw7ZSLwuFvWstLpkRAFT_4DLWkhNFBLW8m_E46_VWG3A@mail.gmail.com>
<20220424121429.GA7363@erisian.com.au>
<CABm2gDo0=psMAKY6Pvfp8b-RvAJdUabiESJpff_yzgwmy7cigQ@mail.gmail.com>
<CALeFGL19G7eLdM7J9dQrumdVTgo1OyoK6UbzF3oJMkGG55qLzg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALeFGL19G7eLdM7J9dQrumdVTgo1OyoK6UbzF3oJMkGG55qLzg@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: Mon, 25 Apr 2022 17:00:21 -0000
On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via bitcoin-dev wrote:
> > Under *any* other circumstance, when they're used to activate a bad soft
> > fork, speedy trial and bip8 are the same. If a resistance method works
> > against bip8, it works against speedy trial; if it fails against speedy
> > trial, it fails against bip8.
> IIRC one essential difference between ST (which is a variant of BIP9) and
> BIP8 is that since there is no mandatory signaling during the lockin
> period,
BIP8 doesn't have mandatory signaling during the lockin period, it has
semi-mandatory [0] signalling during the must_signal period.
> you can't do a counter soft fork as easily.
The "counter" for bip8 activation is to reject any block during either
the started or must_signal phases that would meet the threshold. In that
case someone running bip8 might see blocks:
[elapsed=2010, count=1813, signal=yes]
[elapsed=2011, count=1813, signal=no]
[elapsed=2012, count=1814, signal=yes]
[elapsed=2013, count=1815, signal=yes, will-lockin!]
[elapsed=2014, count=1816, signal=yes]
[elapsed=2015, count=1816, signal=no]
[elapsed=2016, count=1816, signal=no]
[locked in!]
But running software to reject the soft fork, you would reject the
elapsed=2013 block, and any blocks that build on it. You would wait for
someone else to mine a chain that looked like:
[elapsed=2013, count=1814, signal=no]
[elapsed=2014, count=1814, signal=no]
[elapsed=2015, count=1814, signal=no]
[elapsed=2016, count=1814, signal=no]
[failed!]
That approach works *exactly* the same with speedy trial.
Jeremy's written code that does exactly this using the getdeploymentinfo
rpc to check the deployment status, and the invalidateblock rpc to
reject a block. See: https://github.com/JeremyRubin/forkd
The difference to bip8 with lot=true is that nodes running speedy trial
will reorg to follow the resisting chain if it has the most work. bip8
with lot=true nodes will not reorg to a failing chain, potentially
creating an ongoing chain split, unless one group or the other gives up,
and changes their software.
Cheers,
aj
[0] Semi-mandatory in that only "threshold" blocks must signal, so if
only 4% or 9% of miners aren't signalling and the threshold is set
at 95% or 90%, no blocks will be orphaned.
|
