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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 95285DC0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 19:01:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f43.google.com (mail-la0-f43.google.com
[209.85.215.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A68DC2A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 19:01:57 +0000 (UTC)
Received: by lahh2 with SMTP id h2so38195915lah.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 12:01:55 -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
:cc:content-type;
bh=iVjOaUaazJYfVWXCUIF3qlU/s5GXc2w+BvbwRN2PnBc=;
b=QQCcJvVi9iIQ2pvAD3Ww3PsFr4tSIwBmMIpBV97mV3g0FvUmQQSiBExd8KLD+mfq41
/y1RuCmB9SnHHphyTxBuiegmXDNgH6MHf25rW6/OQ8lKKmJHnysG+TVEy5my9SyJC7ux
cbvX+Om+R4u/YcKb7F07u8kvk7N2jr0WZN5IJAmeK2H9mVQcVAycY/bYNgaXW6eOskb6
XxxOZm+xgNrYmWewZRBdmssrHenPDjuyj9AYDeofghxnFLrfzLxyeFNV4poOcuDunv/u
qzz6SMhxDUmxgX10jCXFVPNiyvM2WRgqyrBcAuIlwp6qu/sKDCxFyQq8wkB/3rOqgfdK
S9tg==
MIME-Version: 1.0
X-Received: by 10.152.5.233 with SMTP id v9mr12216685lav.65.1443034915674;
Wed, 23 Sep 2015 12:01:55 -0700 (PDT)
Received: by 10.25.200.214 with HTTP; Wed, 23 Sep 2015 12:01:55 -0700 (PDT)
In-Reply-To: <5602F075.4000102@thinlink.com>
References: <87mvwqb132.fsf@rustcorp.com.au>
<5602F075.4000102@thinlink.com>
Date: Wed, 23 Sep 2015 15:01:55 -0400
Message-ID: <CABsx9T3pFAbtOv78uwaoToHWRXQGwmHA_h8KR89X2HLxiose5g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=089e013d0f5a8c1fbe05206ebf59
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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, 23 Sep 2015 19:01:58 -0000
--089e013d0f5a8c1fbe05206ebf59
Content-Type: text/plain; charset=UTF-8
I say keep it simple.
If the 75% threshold is hit, then support suddenly drops off below 50%,
"meh" -- there will be a big ruckus, everybody will freak out, and miners
will refuse to build big blocks because they'll worry that they'll get
orphaned.
Adding more complexity for a case that ain't gonna happen (and isn't a
disaster if it does) is a mistake, in my humble opinion.
On Wed, Sep 23, 2015 at 2:33 PM, Tom Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:
>
>> '''Success: Activation Delay'''
>> The consensus rules related to ''locked-in'' soft fork will be enforced in
>> the second retarget period; ie. there is a one retarget period in
>> which the remaining 5% can upgrade. At the that activation block and
>> after, the bit B may be reused for a different soft fork.
>>
>>
> Rather than a simple one-period delay, should there be a one-period
> "burn-in" to show sustained support of the threshold? During this period,
> support must continuously remain above the threshold. Any lapse resets to
> inactivated state.
>
> With a simple delay, you can have the embarrassing situation where support
> falls off during the delay period and there is far below threshold support
> just moments prior to enforcement, but enforcement happens anyway.
>
> BIP 101 has this problem too.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
--
Gavin Andresen
--089e013d0f5a8c1fbe05206ebf59
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I say keep it simple.<div><br></div><div>If the 75% thresh=
old is hit, then support suddenly drops off below 50%, "meh" -- t=
here will be a big ruckus, everybody will freak out, and miners will refuse=
to build big blocks because they'll worry that they'll get orphane=
d.</div><div><br></div><div>Adding more complexity for a case that ain'=
t gonna happen (and isn't a disaster if it does) is a mistake, in my hu=
mble opinion.</div><div><br></div><div><br></div></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Wed, Sep 23, 2015 at 2:33 PM, Tom =
Harding via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
'''Success: Activation Delay'''<br>
The consensus rules related to ''locked-in'' soft fork will=
be enforced in<br>
the second retarget period; ie. there is a one retarget period in<br>
which the remaining 5% can upgrade.=C2=A0 At the that activation block and<=
br>
after, the bit B may be reused for a different soft fork.<br>
<br>
</blockquote>
<br></span>
Rather than a simple one-period delay, should there be a one-period "b=
urn-in" to show sustained support of the threshold?=C2=A0 During this =
period, support must continuously remain above the threshold.=C2=A0 Any lap=
se resets to inactivated state.<br>
<br>
With a simple delay, you can have the embarrassing situation where support =
falls off during the delay period and there is far below threshold support =
just moments prior to enforcement, but enforcement happens anyway.<br>
<br>
BIP 101 has this problem too.<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div>
--089e013d0f5a8c1fbe05206ebf59--
|
