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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B0A7B13DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 17:53:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com
[209.85.213.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 50885220
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 17:53:21 +0000 (UTC)
Received: by vkfp126 with SMTP id p126so106147168vkf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 10:53:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=VxX4yVZYxfzDRdaP5DUy7KrNd1Ea1r5Cm3x7Q4BNyiA=;
b=SHZEfB4RFwr1+9XV8aDiBWQ8JWjosaLQXstI0jyRGSwP0xnl+arya7O1m1X7UxLFx+
PyL+Q/dv9Nr5UhIFlxbEHXlOdPoap+U6EPKHYlBRrDc+5sfDILyFPC4O0ERMzDCD3IVq
oO+f4Td/CrG116tRBCsgtGfqF6QUs8MM00XFr0nZgPHHNNnt1gdToR43o35D/0g1+F0V
IX3aQ/O++3oVOJC3VpX77seHwJ+JfVGh0gtL1fsBfzXhr0YrTZ0H3+byocvUlV8w8H9g
Xbidy4VZFJ9Q5mTLKYhNgyXKjpyJOtXf7PYaLmesQDkCjr0dkKbaBPEDQDo6Oe9dgldk
W3Bg==
MIME-Version: 1.0
X-Received: by 10.31.166.206 with SMTP id p197mr6216614vke.52.1442426000384;
Wed, 16 Sep 2015 10:53:20 -0700 (PDT)
Received: by 10.103.65.204 with HTTP; Wed, 16 Sep 2015 10:53:20 -0700 (PDT)
In-Reply-To: <87mvwqb132.fsf@rustcorp.com.au>
References: <87mvwqb132.fsf@rustcorp.com.au>
Date: Wed, 16 Sep 2015 18:53:20 +0100
Message-ID: <CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1141664c5e2a81051fe0f9d9
X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
MALFORMED_FREEMAIL,
MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and
delay.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 16 Sep 2015 17:53:21 -0000
--001a1141664c5e2a81051fe0f9d9
Content-Type: text/plain; charset=UTF-8
On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> '''States'''
> With every softfork proposal we associate a state BState, which begins
> at ''defined'', and can be ''locked-in'', ''activated'',
> or ''failed''. Transitions are considered after each
> retarget period.
>
I think the 75% rule should be maintained. It confirms that miners who are
setting the bit are actually creating blocks that meet the new rule (though
it doesn't check if they are enforcing it).
What is the reason for aligning the updated to the difficulty window?
*defined*
Miners set bit
If 75% of blocks of last 2016 have bit set, goto tentative
*tentative*
Miners set bit
Reject blocks that have bit set that don't follow new rule
If 95% of blocks of last 2016 have bit set, goto locked-in
*locked-in*
Point of no return
Miners still set bit
Reject blocks that have bit set that don't follow new rule
After 2016 blocks goto notice
*activated*
Miners don't set bit for at least 10080 blocks
Reject blocks that don't follow new rule
'''Failure: Timeout'''
> A soft fork proposal should include a ''timeout''.
>
I think counting in blocks is easier to be exact here.
If two bits were allocated per proposal, then miners could vote against
forks to recover the bits. If 25% of the miners vote against, then that
kills it.
In the rationale, it would be useful to discuss effects on SPV clients and
buggy miners.
SPV clients should be recommended to actually monitor the version field.
--001a1141664c5e2a81051fe0f9d9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <span di=
r=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">
'''States'''<br>
With every softfork proposal we associate a state BState, which begins<br>
at ''defined'', and can be ''locked-in'', &=
#39;'activated'',<br>
or ''failed''.=C2=A0 Transitions are considered after each<=
br>
retarget period.<br></blockquote><div><br></div><div>I think the 75% rule s=
hould be maintained.=C2=A0 It confirms that miners who are setting the bit =
are actually creating blocks that meet the new rule (though it doesn't =
check if they are enforcing it).<br><br></div><div>What is the reason for a=
ligning the updated to the difficulty window?<br></div><div><br></div><div>=
<b>defined<br></b><br></div><div>Miners set bit<br>If 75% of blocks of last=
2016 have bit set, goto tentative<br><br><div><b>tentative<br></b><br></di=
v>Miners set bit<br>Reject blocks that have bit set that don't follow n=
ew rule<br>If 95% of blocks of last 2016 have bit set, goto locked-in<br></=
div><div></div><div><br></div><div><b>locked-in<br></b></div><div><br></div=
><div>Point of no return<br></div><div>Miners still set bit<br>Reject block=
s that have bit set that don't follow new rule<br></div><div></div><div=
>After 2016 blocks goto notice<br></div><br><div><div><b>activated<br></b><=
/div><div><br></div><div>Miners don't set bit for at least 10080 blocks=
<br>Reject blocks that don't follow new rule<br></div><div><br></div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
'''Failure: Timeout'''<br>
A soft fork proposal should include a ''timeout''.=C2=A0 <b=
r></blockquote><div><br></div><div>I think counting in blocks is easier to =
be exact here.<br><br></div><div>If two bits were allocated per proposal, t=
hen miners could vote against forks to recover the bits.=C2=A0 If 25% of th=
e miners vote against, then that kills it.<br><br></div><div>In the rationa=
le, it would be useful to discuss effects on SPV clients and buggy miners.<=
br><br></div><div>SPV clients should be recommended to actually monitor the=
version field.<br></div></div></div></div>
--001a1141664c5e2a81051fe0f9d9--
|
