path: root/67/8fe62ef092c5713b1e6f3b9a54a2621487e511

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--