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
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <roy@gnomon.org.uk>) id 1YqSRL-0004Ex-D6
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 20:30:39 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gnomon.org.uk
designates 93.93.131.22 as permitted sender)
client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
helo=darla.gnomon.org.uk;
Received: from darla.gnomon.org.uk ([93.93.131.22])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YqSRJ-0002Wd-84
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 20:30:39 +0000
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id t47K0NBg063822
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <bitcoin-development@lists.sourceforge.net>;
Thu, 7 May 2015 21:00:29 +0100 (BST)
(envelope-from roy@darla.gnomon.org.uk)
Received: (from roy@localhost)
by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id t47K0NuB063821
for bitcoin-development@lists.sourceforge.net;
Thu, 7 May 2015 21:00:23 +0100 (BST) (envelope-from roy)
Date: Thu, 7 May 2015 21:00:23 +0100
From: Roy Badami <roy@gnomon.org.uk>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20150507200023.GI63100@giles.gnomon.org.uk>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="eJnRUKwClWJh1Khz"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1YqSRJ-0002Wd-84
Subject: [Bitcoin-development] Mechanics of a hard fork
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2015 20:30:39 -0000
--eJnRUKwClWJh1Khz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
I'd love to have more discussion of exactly how a hard fork should be
implemented. I think it might actually be of some value to have rough
consensus on that before we get too bogged down with exactly what the
proposed hard fork should do. After all, how can we debate whether a
particular hard fork proposal has consensus if we haven't even decided
what level of supermajority is needed to establish consensus?
For instance, back in 2012 Gavin was proposing, effectively, that a
hard fork should require a supermajority of 99% of miners in order to
succeed:
https://gist.github.com/gavinandresen/2355445
More recently, Gavin has proposed that a supermoajority of only 80% of
miners should be needed in order to trigger the hard fork.
http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html
Just now, on this list (see attached message) Gavin seems to be
aluding to some mechanism for a hard fork which involves consensus of
full nodes, and then a soft fork preceeding the hard fork, which I'd
love to see a full explanation of.
FWIW, I think 80% is far too low to establish consensus for a hard
fork. I think the supermajority of miners should be sufficiently
large that the rump doesn't constitute a viable coin. If you don't
have that very strong level of consensus then you risk forking Bitcoin
into two competing coins (and I believe we already have one exchange
promissing to trade both forks as long as the blockchains are alive).
As a starting point, I think 35/36th of miners (approximately 97.2%)
is the minimum I would be comfortable with. It means that the rump
coin will initially have an average confirmation time of 6 hours
(until difficulty, very slowly, adjusts) which is probably far enough
from viable that the majority of holdouts will quickly desert it too.
Thoughs?
roy
--eJnRUKwClWJh1Khz
Content-Type: message/rfc822
Content-Disposition: attachment; filename="hardfork.eml"
Return-Path: <bitcoin-development-bounces@lists.sourceforge.net>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on darla.gnomon.org.uk
X-Spam-Level:
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,
DNS_FROM_AHBL_RHSBL, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_HI,
SPF_HELO_PASS,
SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
Received: from lists.sourceforge.net (lists.sourceforge.net [216.34.181.88])
by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id t47ErfmT058987
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <roy@gnomon.org.uk>; Thu, 7 May 2015 15:53:47 +0100 (BST)
(envelope-from bitcoin-development-bounces@lists.sourceforge.net)
Received: from localhost ([127.0.0.1] helo=sfs-ml-2.v29.ch3.sourceforge.com)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-development-bounces@lists.sourceforge.net>)
id 1YqNAf-0008Kt-JP; Thu, 07 May 2015 14:53:05 +0000
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1YqNAd-0008Kn-PM
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 14:53:03 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.43 as permitted sender)
client-ip=209.85.215.43; envelope-from=gavinandresen@gmail.com;
helo=mail-la0-f43.google.com;
Received: from mail-la0-f43.google.com ([209.85.215.43])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqNAb-0001ZG-Eq
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 14:53:03 +0000
Received: by laat2 with SMTP id t2so32521150laa.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 07:52:55 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.205.69 with SMTP id le5mr3387649lbc.65.1431010375037;
Thu, 07 May 2015 07:52:55 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Thu, 7 May 2015 07:52:54 -0700 (PDT)
In-Reply-To: <CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
Date: Thu, 7 May 2015 10:52:54 -0400
Message-ID: <CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
X-Headers-End: 1YqNAb-0001ZG-Eq
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4760500443120036853=="
Errors-To: bitcoin-development-bounces@lists.sourceforge.net
Status: RO
Content-Length: 6078
--===============4760500443120036853==
Content-Type: multipart/alternative; boundary=001a11c3c1be12fa1505157f1144
--001a11c3c1be12fa1505157f1144
Content-Type: text/plain; charset=UTF-8
For reference: the blog post that (re)-started this debate, and which links
to individual issues, is here:
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
In it, I asked people to email me objections I might have missed. I would
still appreciate it if people do that; it is impossible to keep up with
this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and
also have time to respond thoughtfully to the objections raised.
I would very much like to find some concrete course of action that we can
come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
how much transaction volume the main Bitcoin blockchain will be able to
support over the next eleven years."
I've been pretty clear on what I think is a reasonable compromise (a
one-time increase scheduled for early next year), and I have tried to
explain why I think it it is the right set of tradeoffs.
There ARE tradeoffs here, and the hard question is what process do we use
to decide those tradeoffs? How do we come to consensus? Is it worth my
time to spend hours responding thoughtfully to every new objection raised
here, or will the same thing happen that happened last year and the year
before-- everybody eventually gets tired of arguing
angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
I AM considering contributing some version of the bigger blocksize-limit
hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a
fast Internet connection, and assume Nelson's law to increase over time),
and then encouraging merchants and exchanges and web wallets and
individuals who think it strikes a reasonable balance to run it.
And then, assuming it became a super-majority of nodes on the network,
encourage miners to roll out a soft-fork to start producing bigger blocks
and eventually trigger the hard fork.
Because ultimately consensus comes down to what software people choose to
run.
--
--
Gavin Andresen
--001a11c3c1be12fa1505157f1144
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">For reference: the blog post th=
at (re)-started this debate, and which links to individual issues, is here:=
</div><div class=3D"gmail_extra">=C2=A0=C2=A0<a href=3D"http://gavinandrese=
n.ninja/time-to-roll-out-bigger-blocks">http://gavinandresen.ninja/time-to-=
roll-out-bigger-blocks</a></div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">In it, I asked people to email me objections I might h=
ave missed. I would still appreciate it if people do that; it is impossible=
to keep up with this mailing list, /r/bitcoin posts and comments, and #bit=
coin-wizards and also have time to respond thoughtfully to the objections r=
aised.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
>I would very much like to find some concrete course of action that we can =
come to consensus on. Some compromise so we can tell entrepreneurs "TH=
IS is how much transaction volume the main Bitcoin blockchain will be able =
to support over the next eleven years."<br><br>I've been pretty cl=
ear on what I think is a reasonable compromise (a one-time increase schedul=
ed for early next year), and I have tried to explain why I think it it is t=
he right set of tradeoffs.</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">There ARE tradeoffs here, and the hard question is wha=
t process do we use to decide those tradeoffs?=C2=A0 How do we come to cons=
ensus? Is it worth my time to spend hours responding thoughtfully to every =
new objection raised here, or will the same thing happen that happened last=
year and the year before-- everybody eventually gets tired of arguing ange=
ls-dancing-on-the-head-of-a-pin, and we're left with the status quo?</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I AM con=
sidering contributing some version of the bigger blocksize-limit hard-fork =
patch to the Bitcoin-Xt fork (probably =C2=A0"target a hobbyist with a=
fast Internet connection, and assume Nelson's law to increase over tim=
e), and then encouraging merchants and exchanges and web wallets and indivi=
duals who think it strikes a reasonable balance to run it.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">And then, assuming it=
became a super-majority of nodes on the network, encourage miners to roll =
out a soft-fork to start producing bigger blocks and eventually trigger the=
hard fork.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">Because ultimately consensus comes down to what software people choos=
e to run.</div><div class=3D"gmail_extra"><div><br></div>-- <br><div class=
=3D"gmail_signature">--<br>Gavin Andresen<br></div><div class=3D"gmail_sign=
ature"><br></div>
</div></div>
--001a11c3c1be12fa1505157f1144--
--===============4760500443120036853==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
--===============4760500443120036853==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--===============4760500443120036853==--
--eJnRUKwClWJh1Khz--
|