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
|
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 EBD0911FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 20:30:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com
[209.85.213.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33BA613C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 20:30:28 +0000 (UTC)
Received: by vkgd64 with SMTP id d64so109441279vkg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2015 13:30:27 -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=fEK9g60EiPzAi0cyvtCDA/KmRJ58azAIXuro71PPKoA=;
b=Qv17MI4j9fX4ujPgfILx9hP4y39AiTf4ewem9NKuJSNLOjupMb/DQir0rj9bdMxrdD
JFVYIPNWSWn52GfXwXwvPaT73S5Qg/ugiuAqrr4/OKLI4kO70YoaN8OUc8ctl4VlDGp6
T1LYv+K6zHeZ6bMwJ9i2PpBdE3GLr6fgkFTFzXSkAVr1WO1ZWM0Pl/Mj4zE2UN8p10/4
c8b5+ncrABzhfUweF8kWFfCatW5LGJevuvztOM5w2lBu6ADwq3GbshFXh0djj+ev2Qv0
kdDHNfQa0HxzIxXZ/K/HUlxTK8kd63menUGfnQUcMSKyK8GxW+y6VuKNR2BbpPbm9GU1
WdFw==
MIME-Version: 1.0
X-Received: by 10.31.5.205 with SMTP id 196mr30497269vkf.88.1442435427590;
Wed, 16 Sep 2015 13:30:27 -0700 (PDT)
Received: by 10.103.65.204 with HTTP; Wed, 16 Sep 2015 13:30:27 -0700 (PDT)
In-Reply-To: <87r3lyjewl.fsf@rustcorp.com.au>
References: <87mvwqb132.fsf@rustcorp.com.au>
<CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>
<87r3lyjewl.fsf@rustcorp.com.au>
Date: Wed, 16 Sep 2015 21:30:27 +0100
Message-ID: <CAE-z3OW6BKHfx=wS9AYqb4+Ems6xM+SDqBKgGbNkXfPwuPqn8A@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1143dda045ec3e051fe32b02
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 20:30:30 -0000
--001a1143dda045ec3e051fe32b02
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell <rusty@rustcorp.com.au>
wrote:
> I couldn't see a use for it, since partial enforcement of a soft fork is
> pretty useless.
>
It isn't useful for actually using the feature, but some miners might set
the bit but not actually create blocks that comply with the new rule.
This would cause their blocks to be orphaned until they fixed it.
OK, *that* variant makes perfect sense, and is no more complex, AFAICT.
>
> So, there's two weeks to detect bad implementations, then you everyone
> stops setting the bit, for later reuse by another BIP.
>
It could be more than two weeks if the support stays between 80% and 90%
for a while.
75%+ checks that blocks with the bit set follow the rule.
95%+ enters lock-in and has the same rules as 75%+, but is irreversible at
that point.
> You need a timeout: an ancient (non-mining, thus undetectable) node
> should never fork itself off the network because someone reused a failed
> BIP bit.
>
I meant if the 2nd bit was part of the BIP. One of the 2 bits is "FOR" and
the other is "AGAINST". If against hits 25%, then it is deemed a failure.
The 2nd bit wouldn't be used normally. This means that proposals can be
killed quickly if they are obviously going to fail.
--001a1143dda045ec3e051fe32b02
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 Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell <span dir=3D"ltr"><<a=
href=3D"mailto:rusty@rustcorp.com.au" target=3D"_blank">rusty@rustcorp.com=
.au</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I couldn't =
see a use for it, since partial enforcement of a soft fork is<br>
pretty useless.<span class=3D""><br></span></blockquote><div>=C2=A0<br></di=
v><div>It isn't useful for actually using the feature, but some miners =
might set the bit but not actually create blocks that comply with the new r=
ule.<br><br></div><div>This would cause their blocks to be orphaned until t=
hey fixed it.<br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span =
class=3D"">
</span>OK, *that* variant makes perfect sense, and is no more complex, AFAI=
CT.<br>
<br>
So, there's two weeks to detect bad implementations, then you everyone<=
br>
stops setting the bit, for later reuse by another BIP.<br></blockquote><div=
><br></div><div>It could be more than two weeks if the support stays betwee=
n 80% and 90% for a while.<br><br></div><div>75%+ checks that blocks with t=
he bit set follow the rule.<br><br></div><div>95%+ enters lock-in and has t=
he same rules as 75%+, but is irreversible at that point.<br></div><div>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
</span>You need a timeout: an ancient (non-mining, thus undetectable) node<=
br>
should never fork itself off the network because someone reused a failed<br=
>
BIP bit.<br></blockquote><div><br></div><div>I meant if the 2nd bit was par=
t of the BIP.=C2=A0 One of the 2 bits is "FOR" and the other is &=
quot;AGAINST".=C2=A0 If against hits 25%, then it is deemed a failure.=
<br><br></div><div>The 2nd bit wouldn't be used normally.=C2=A0 This me=
ans that proposals can be killed quickly if they are obviously going to fai=
l.<br></div></div></div></div>
--001a1143dda045ec3e051fe32b02--
|
