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
|
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 DBC911421
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Sep 2015 10:38:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com
[209.85.213.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4A442103
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Sep 2015 10:38:30 +0000 (UTC)
Received: by vkfp126 with SMTP id p126so8088800vkf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Sep 2015 03:38:29 -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:to
:content-type; bh=6XhZd/rWw8lfgbWvpW3AGEb9hNh/I4dO/sw5pMQl96s=;
b=MmiF+/Aw3ElMgUKoNn+Hc75oqTx6uv6o+gdzlxYxqZ2ilf/gMLJL9KQm6uZGo/aHTu
DtfAbYICjmxa0F9zMvyMbAji/M7ZDZ92NrNO8JdrxsmmpdnoqfY2gMw24qyS+3Tmbf2/
AmliljUa1qnqIW+YadKUhBM2Oe5IQw8bomUFCpcGTAS9HSZE52/hg5NbWEo7JI1bFUxW
97U4dOhKT2MypRKiIWBmx3Z0/LZQExnuNEuSduyuz4PZoDnR+KLvpJwPzjCBTrB9EYgS
UCKhRYKp+rIyuShAeytVUXPkaEc4OFYTg46UsSXB6oOlZfRzkLNaBiXTYgraJPom9MnN
6AQg==
MIME-Version: 1.0
X-Received: by 10.31.166.206 with SMTP id p197mr10094170vke.52.1442486309382;
Thu, 17 Sep 2015 03:38:29 -0700 (PDT)
Received: by 10.103.65.204 with HTTP; Thu, 17 Sep 2015 03:38:29 -0700 (PDT)
In-Reply-To: <CDB1F26E-FE26-44F3-9A86-CDAE33A51B8B@gmail.com>
References: <87mvwqb132.fsf@rustcorp.com.au>
<CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
<87r3lyjewl.fsf@rustcorp.com.au>
<CABm2gDqh=Dv2Ygctg+jEt61N_nJDRBMqdZypSPtmfM2QrY4AYQ@mail.gmail.com>
<CAE-z3OXATJ6HGKqU=vxc8k-yCMAMwXiWQJxvO3D_O256_ZODtw@mail.gmail.com>
<CABm2gDppFsTbh3JtdJkAkV_GzKFYAOLiEmtQPCgS9O6b7eWFuw@mail.gmail.com>
<CAE-z3OXbUhsyzd=8hxzFAST9rEQyTg9whn+CMh92S0FMdLH4ug@mail.gmail.com>
<CABm2gDo4f6bpJeobwRyoukKw9t=ApuRtHMYWpWFXjv9=K7aFyA@mail.gmail.com>
<CAE-z3OUyNpmG5uhSCExf39zmmB-b9xDrn+gkp3UFeg7M3G8E5g@mail.gmail.com>
<CABm2gDphLRQ6huhxvcx1YvbsmaBHA_sk6MEZF+hgdxoC472P+w@mail.gmail.com>
<CDB1F26E-FE26-44F3-9A86-CDAE33A51B8B@gmail.com>
Date: Thu, 17 Sep 2015 11:38:29 +0100
Message-ID: <CAE-z3OWu7HgHh=8nAZMfJaekL03HHXvHrkRBho=aBAoRtHR9Eg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1141664c10725c051fef046d
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW, URIBL_BLACK 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: Thu, 17 Sep 2015 10:38:31 -0000
--001a1141664c10725c051fef046d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Sep 16, 2015 at 11:52 PM, Eric Lombrozo <elombrozo@gmail.com> wrote=
:
> The exact numbers (95% vs. 75% etc) don't need to be completely specified
> to start working on an implementation. What really matters for now is
> defining the states and trigger mechanisms. I'd rather we not argue over
> the optimal values for supermajority requirement at this point.
>
The discussion was about what each state means, not the thresholds
exactly. I agree that can be set later.
On Wed, Sep 16, 2015 at 10:03 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
> I understand your proposal, but I don't see what it accomplishes compared
to applying the new rule from the start (in your own blocks)
> and wait for 95% for consensus activation (which is my preference and
it's much simpler to implement).
> What are the disadvantages of my approach? What are the advantages of
yours?
I agree that miners should apply the rule from the start in their own
blocks.
*defined*
Miners set bit
Miners apply rule to their own blocks
If 75% of blocks of last 2016 have bit set, goto tentative
*tentative*
Miners set bit
Miners apply rule to their own blocks
Miners enforce rule in blocks with bit set (reject invalid blocks)
If 95% of blocks of last 2016 have bit set, goto locked-in
*locked-in*
Point of no return
Miners set bit
Miners apply rule to their own blocks
Miners enforce rule in blocks with bit set (reject invalid blocks)
After 2016 blocks goto activated
*activated*
Miners don't set bit
Reject any block that has the bit set for 10080 blocks (10 diff periods)
Reject blocks that don't follow new rule
The advantage of enforcing the rule when 75% is reached (but only for
blocks with the bit set) is that miners get early notification that they
have implemented the rule incorrectly. They might produce blocks that
they think are fine, but which aren't.
--001a1141664c10725c051fef046d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Sep 16, 2015 at 11:52 PM, Eric Lombrozo <span dir=3D"ltr"><<a href=
=3D"mailto:elombrozo@gmail.com" target=3D"_blank">elombrozo@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>=
The exact numbers (95% vs. 75% etc) don't need to be completely specifi=
ed to start working on an implementation. What really matters for now is de=
fining the states and trigger mechanisms. I'd rather we not argue over =
the optimal values for supermajority requirement at this point.</div></bloc=
kquote><div><br></div><div>The discussion was about what each state means, =
not the thresholds exactly.=C2=A0 I agree that can be set later.<br><br>On =
Wed, Sep 16, 2015 at 10:03 PM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a hr=
ef=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></=
span> wrote:<br><p dir=3D"ltr">> I
understand your proposal, but I don't see what it accomplishes compare=
d
to applying the new rule from the start (in your own blocks) <br></p><p di=
r=3D"ltr">> and wait=20
for 95% for consensus activation (which is my preference and it's much=
=20
simpler to implement).<br>
> What are the disadvantages of my approach? What are the advantages of =
yours?</p>I agree that miners should apply the rule from the start in their=
own blocks.<br><br><div><b>defined<br></b><br></div><div>Miners set bit<br=
>Miners apply rule to their own blocks<br>If 75% of blocks of last 2016 hav=
e bit set, goto tentative<br><br><div><b>tentative<br></b><br></div>Miners =
set bit<br>Miners apply rule to their own blocks<br>Miners enforce rule in =
blocks with bit set (reject invalid blocks)<br></div><div>If 95% of blocks =
of last 2016 have bit set, goto locked-in<br></div><div><br></div><div><b>l=
ocked-in<br></b></div><div><br></div><div>Point of no return<br></div>Miner=
s set bit<br>Miners apply rule to their own blocks<br>Miners enforce rule i=
n blocks with bit set (reject invalid blocks)<br>After 2016 blocks goto act=
ivated<br><br><div><b>activated<br></b></div><div><br></div>Miners don'=
t set bit<br>Reject any block that has the bit set for 10080 blocks (10 dif=
f periods)<br>Reject blocks that don't follow new rule<br><br></div><di=
v>The advantage of enforcing the rule when 75% is reached (but only for blo=
cks with the bit set) is that miners get early notification that they have =
implemented the rule incorrectly.=C2=A0=C2=A0=C2=A0 They might produce bloc=
ks that they think are fine, but which aren't.<br></div></div></div></d=
iv>
--001a1141664c10725c051fef046d--
|
