summaryrefslogtreecommitdiff
path: root/67/8fe62ef092c5713b1e6f3b9a54a2621487e511
blob: b751565098b9ac9dec4347e08df51da1f040aede (plain)
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
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
Return-Path: <clem.ds@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 76198305
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 13:18:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com
	[209.85.160.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A4C47190
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 13:18:48 +0000 (UTC)
Received: by ykdt205 with SMTP id t205so125815805ykd.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Aug 2015 06:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc:content-type;
	bh=9AtEgIinq8iLp2b4vYtApc1GVRn9kBEJ0lWsgqOBWX8=;
	b=yZiw8fBk25wpwCOLYpOT5g5hTG6uXncO5DVp5fiZqcwPX+CQ76tStjrYRjJCuD2QFc
	Chc+ZDl1O9Fk603Mk8BaYYhbHFMzj5pTVMWDDkJXaz74olBx8mHWyluezmQXeE6UAcgi
	mEJt5+dwGrGhEfb0J1yy6Yv8Rum50G4MUOGXHiSNzw064ilmKfBJ+Pbp5A/D+mCKekzJ
	iiht5EWok8hg3fSfKso4gOjri1QklbFbXgz+iOB+hD6KA082EK5G2Ta5WoIB9n/uPbZV
	5OZzJeajmGAmBEav8dbv0+I7bnkkFWbMnat6dcOhf9VgmCUo8jXMno6rfv2y/DzT/wAu
	sS/Q==
X-Received: by 10.129.74.135 with SMTP id x129mr1337296ywa.98.1439817527991;
	Mon, 17 Aug 2015 06:18:47 -0700 (PDT)
MIME-Version: 1.0
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com>
	<CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@mail.gmail.com>
	<0CAB4453-0C88-4CCB-86C1-DA192D4F77A1@gmail.com>
	<CALqxMTHQCWSg5Px5iLzNisZchuyzWJ2KwtwbWycywDSjF+4GBA@mail.gmail.com>
	<CAE-z3OXEUE8b_u9Pf8DbPL4jWTqyR7CDJRqKFKoTGpGxnr1QoA@mail.gmail.com>
	<55946E68.5070805@riseup.net>
	<CAE-z3OX47uh6TDcfm7VO-venh5BTU_crVxvSZMVvMn5wBPg3uw@mail.gmail.com>
In-Reply-To: <CAE-z3OX47uh6TDcfm7VO-venh5BTU_crVxvSZMVvMn5wBPg3uw@mail.gmail.com>
From: =?UTF-8?Q?Cl=C3=A9ment_Elbaz?= <clem.ds@gmail.com>
Date: Mon, 17 Aug 2015 13:18:38 +0000
Message-ID: <CAP63atYR7RdoAHWycNnx2DN9vuX9bKhDC9bLCMjTs7oFs4_u4A@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a114d90be4c3895051d81a4a3
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
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: Mon, 17 Aug 2015 13:18:50 -0000

--001a114d90be4c3895051d81a4a3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The "only bigblock" patch you want is actually available here :
https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

Le lun. 17 ao=C3=BBt 2015 =C3=A0 15:16, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> One of the comments made by the mining pools is that they won't run XT
> because it is "experimental".
>
> Has there been any consideration to making available a version of XT with
> only the blocksize changes?
>
> The least "experimental" version would be one that makes the absolute
> minimum changes to core.
>
> The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest ti=
p
> changes.  This saves creating a new function.
>
> Without the consensus measuring code, the patch would be even easier.
> Satoshi's proposal was just a block height comparison (a year in advance)=
.
>
> The state storing code is also another complication.  If the standard
> "counting" upgrade system was used, then no state would need to be stored
> in the database.
>
> On Wed, Jul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla@riseup.net>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> (My replies below)
>>
>> On 06/26/2015 06:47 AM, Tier Nolan wrote:
>> > On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org
>> > <mailto:adam@cypherspace.org>> wrote:
>> >
>> > The hard-cap serves the purpose of a safety limit in case our
>> > understanding about the economics, incentives or game-theory is
>> > wrong worst case.
>> >
>> >
>> > True.
>>
>> Yep.
>>
>> >
>> > BIP 100 and 101 could be combined.  Would that increase consensus?
>>
>> Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100
>> is a better alternative to Gavin's proposal(s), but that I didn't
>> think that this should be taken to mean that I am saying one thing is
>> "superior" to Gavin's work, rather, I emphasized that Gavin work with
>> Jeff and Adam.
>>
>> At least, at this stage the things are in a BIP process.
>>
>> If the BIP 100 and BIP 101 would be combined, what would that look
>> like on paper?
>>
>> >
>> > - Miner vote threshold reached - Wait notice period or until
>> > earliest start time - Block size default target set to 1 MB - Soft
>> > limit set to 1MB - Hard limit set to 8MB + double every 2 years -
>> > Miner vote to decide soft limit (lowest size ignoring bottom 20%
>> > but 1MB minimum)
>> >
>> > Block size updates could be aligned with the difficulty setting
>> > and based on the last 2016 blocks.
>> >
>> > Miners could leave the 1MB limit in place initially.  The vote is
>> > to get the option to increase the block size.
>> >
>> > Legacy clients would remain in the network until >80% of miners
>> > vote to raise the limit and a miner produces a >1MB block.
>> >
>> > If the growth rate over-estimates hardware improvements, the devs
>> > could add a limit into the core client.  If they give notice and
>> > enough users update, then miners would have to accept it.
>> >
>> > The block size becomes min(miner's vote, core devs).  Even if 4
>> > years notice is given, blocks would only be 4X optimal.
>> >
>> >
>> > _______________________________________________ bitcoin-dev mailing
>> > list bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>> - --
>> http://abis.io ~
>> "a protocol concept to enable decentralization
>> and expansion of a giving economy, and a new social good"
>> https://keybase.io/odinn
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb
>> hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC
>> 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP
>> wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH
>> YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ
>> 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=3D
>> =3DrtTH
>> -----END PGP SIGNATURE-----
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a114d90be4c3895051d81a4a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The &quot;only bigblock&quot; patch you want is actually a=
vailable here :=C2=A0<a href=3D"https://github.com/bitcoinxt/bitcoinxt/tree=
/only-bigblocks">https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks=
</a></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0lun. 17 a=
o=C3=BBt 2015 =C3=A0=C2=A015:16, Tier Nolan via bitcoin-dev &lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><div><div><div>One of the comments made by the mini=
ng pools is that they won&#39;t run XT because it is &quot;experimental&quo=
t;.<br><br></div>Has there been any consideration to making available a ver=
sion of XT with only the blocksize changes?<br><br></div>The least &quot;ex=
perimental&quot; version would be one that makes the absolute minimum chang=
es to core.<br><br></div></div><div>The MAX_BLOCK_SIZE parameter could be o=
verwritten whenever the longest tip changes.=C2=A0 This saves creating a ne=
w function.<br><br>Without the consensus measuring code, the patch would be=
 even easier.=C2=A0 Satoshi&#39;s proposal was just a block height comparis=
on (a year in advance).<br><br></div><div>The state storing code is also an=
other complication.=C2=A0 If the standard &quot;counting&quot; upgrade syst=
em was used, then no state would need to be stored in the database.<br></di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, J=
ul 1, 2015 at 11:49 PM, odinn <span dir=3D"ltr">&lt;<a href=3D"mailto:odinn=
.cyberguerrilla@riseup.net" target=3D"_blank">odinn.cyberguerrilla@riseup.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>-----BEGIN=
 PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span>(My replies below)<br>
<span><br>
On 06/26/2015 06:47 AM, Tier Nolan wrote:<br>
&gt; On Thu, Jun 25, 2015 at 3:07 PM, Adam Back &lt;<a href=3D"mailto:adam@=
cypherspace.org" target=3D"_blank">adam@cypherspace.org</a><br>
</span><span>&gt; &lt;mailto:<a href=3D"mailto:adam@cypherspace.org" target=
=3D"_blank">adam@cypherspace.org</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt; The hard-cap serves the purpose of a safety limit in case our<br>
&gt; understanding about the economics, incentives or game-theory is<br>
&gt; wrong worst case.<br>
&gt;<br>
&gt;<br>
&gt; True.<br>
<br>
</span>Yep.<br>
<span><br>
&gt;<br>
&gt; BIP 100 and 101 could be combined.=C2=A0 Would that increase consensus=
?<br>
<br>
</span>Possibly ~ In my past message(s), I&#39;ve suggested that Jeff&#39;s=
 BIP 100<br>
is a better alternative to Gavin&#39;s proposal(s), but that I didn&#39;t<b=
r>
think that this should be taken to mean that I am saying one thing is<br>
&quot;superior&quot; to Gavin&#39;s work, rather, I emphasized that Gavin w=
ork with<br>
Jeff and Adam.<br>
<br>
At least, at this stage the things are in a BIP process.<br>
<br>
If the BIP 100 and BIP 101 would be combined, what would that look<br>
like on paper?<br>
<span><br>
&gt;<br>
&gt; - Miner vote threshold reached - Wait notice period or until<br>
&gt; earliest start time - Block size default target set to 1 MB - Soft<br>
&gt; limit set to 1MB - Hard limit set to 8MB + double every 2 years -<br>
&gt; Miner vote to decide soft limit (lowest size ignoring bottom 20%<br>
&gt; but 1MB minimum)<br>
&gt;<br>
&gt; Block size updates could be aligned with the difficulty setting<br>
&gt; and based on the last 2016 blocks.<br>
&gt;<br>
&gt; Miners could leave the 1MB limit in place initially.=C2=A0 The vote is=
<br>
&gt; to get the option to increase the block size.<br>
&gt;<br>
&gt; Legacy clients would remain in the network until &gt;80% of miners<br>
&gt; vote to raise the limit and a miner produces a &gt;1MB block.<br>
&gt;<br>
&gt; If the growth rate over-estimates hardware improvements, the devs<br>
&gt; could add a limit into the core client.=C2=A0 If they give notice and<=
br>
&gt; enough users update, then miners would have to accept it.<br>
&gt;<br>
&gt; The block size becomes min(miner&#39;s vote, core devs).=C2=A0 Even if=
 4<br>
&gt; years notice is given, blocks would only be 4X optimal.<br>
&gt;<br>
&gt;<br>
</span><span>&gt; _______________________________________________ bitcoin-d=
ev mailing<br>
&gt; list <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
<br>
</span><span>- --<br>
<a href=3D"http://abis.io" rel=3D"noreferrer" target=3D"_blank">http://abis=
.io</a> ~<br>
&quot;a protocol concept to enable decentralization<br>
and expansion of a giving economy, and a new social good&quot;<br>
<a href=3D"https://keybase.io/odinn" rel=3D"noreferrer" target=3D"_blank">h=
ttps://keybase.io/odinn</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
</span>iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb<br>
hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC<br>
5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP<br>
wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH<br>
YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ<br>
0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=3D<br>
=3DrtTH<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div>
_______________________________________________<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>
</blockquote></div>

--001a114d90be4c3895051d81a4a3--