path: root/61/cd0bf5b88706005ad7e03ce078404bbe8a423b

Return-Path: <will.madden@novauri.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 40496ABF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 13:06:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com
	[209.85.220.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7991A1C4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 13:06:45 +0000 (UTC)
Received: by qkeo142 with SMTP id o142so21232527qke.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jun 2015 06:06:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:content-type:mime-version:subject:from
	:in-reply-to:date:cc:content-transfer-encoding:message-id:references
	:to; bh=/AN2WWuNrl2CtKtF61p7KvbkJr/147EynwEYGZAMb+s=;
	b=bTL+njLvGCJVmoVaigh1ckzpRdoCBMoL0l2M23WjVGTQmmi+3khAe1cZf9uJH//VKN
	b4GlglrucQizRoeMW8CO2xdBbogOWudWvNvvgk+pEdI6T66kMwzjEOPDrz892Fsn8fQb
	qXHYFdLm74xAhG9eTixz4uVgL1pHp4D1Z9FFC4cknW9wbv20KbMHQwHkIH54/AiyhuXD
	N4XG0wNoxcjKmJNOY8qAqF9BF1xdyS0LyFi9k3MM7WdFS1BO2Ye+ZIFgo/FIb2mYLYdk
	Z9tK8GlEd7wetmRLrfYiYanI+1nfhkHG6REzUPEBJIvdfmgglplMZqW248BQS0QiwNpA
	3Lmg==
X-Gm-Message-State: ALoCoQkZz1PK52Iec73LGl7gOZ7768mKgz4gcErEzNyNu2a/npDBm28UHWEE02VCTHV779z0eK5x
X-Received: by 10.55.26.133 with SMTP id l5mr65315466qkh.40.1435151204177;
	Wed, 24 Jun 2015 06:06:44 -0700 (PDT)
Received: from [192.168.0.17] (cpe-142-105-230-1.twcny.res.rr.com.
	[142.105.230.1])
	by mx.google.com with ESMTPSA id 16sm3067747qhd.11.2015.06.24.06.06.42
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 24 Jun 2015 06:06:43 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-26E99BC2-750F-4D87-8BDA-E715EC572737
Mime-Version: 1.0 (1.0)
From: Will <will.madden@novauri.com>
X-Mailer: iPhone Mail (12F70)
In-Reply-To: <CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@mail.gmail.com>
Date: Wed, 24 Jun 2015 09:06:40 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <2DC61141-96C9-4727-81D6-3CF572BC6BD7@novauri.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com>
	<CADm_WcZ52_fvNk_rWzu+Nw1CBz2o6t6cMkEfOm3BpdjH7iQKrw@mail.gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	MIME_QP_LONG_LINE,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"
	<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: Wed, 24 Jun 2015 13:06:51 -0000


--Apple-Mail-26E99BC2-750F-4D87-8BDA-E715EC572737
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Yes, but with a key distinction.   Today miners may collude to (or unintenti=
onally) lower the block size limit for blocks they win.  BIP-100 introduces t=
he possibility of lowering the block size limit for everyone over the next 1=
2,000 blocks.

Another gap involves laziness.  What is a far more likely issue is not a con=
spiracy but that miners will be lazy and hard code their vote values, requir=
ing arm twisting later to change them.  Preventing this headache introduces t=
he need for more complexity, either by making the default a non-vote (which m=
akes it easier to game the system with less voting power), or by making the d=
efault vote =3D MAX_BLOCK_SIZE * 1.09 (which makes the default similar is to=
 Gavin's proposal).

I think with a default vote that is ~9% larger than the previous max block s=
ize and no option to lower the max block size then BIP-100 could work withou=
t added risk or defeating the intended purpose.  Still, one has to ask if th=
e benefit is there to justify the additional moving parts.

> On Jun 23, 2015, at 11:49 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
>=20
> Miners can collude today to lower the block size limit.
>=20
> In fact, this largely happens already out of laziness - miners often follo=
w the "soft" default limit set by Bitcoin Core, to the point where you can c=
hart when miners upgrade to new software: http://hashingit.com/analysis/39-t=
he-myth-of-the-megabyte-bitcoin-block
>=20
>=20
>=20
>> On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri.com>=
 wrote:
>> Here are refutations of the approach in BIP-100 here:
>> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>>=20
>> To recap BIP-100:
>>=20
>> 1) Hard form to remove static 1MB block size limit
>> 2) Add new floating block size limit set to 1MB
>> 3) Historical 32MB message limit remains
>> 4) Hard form on testnet 9/1/2015
>> 5) Hard form on main 1/11/2016
>> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
>> threshold by 90% of blocks
>> 7) Limit increase or decrease may not exceed 2x in any one step
>> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
>> scriptSig, e.g. "/BV8000000/" to vote for 8M.
>> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
>> most common floor (minimum) is chosen.
>>=20
>> 8MB limits doubling just under every 2 years makes a static value grow
>> in a predictable manner.
>>=20
>> BIP-100 makes a static value grow (or more importantly potentially
>> shrink) in an unpredictable manner based on voting mechanics that are
>> untested in this capacity in the bitcoin network.  Introducing a highly
>> variable and untested dynamic into an already complex system is
>> unnecessarily risky.
>>=20
>> For example, the largely arbitrary voting rules listed in 9 above can be
>> gamed.  If I control pools or have affiliates involved in pools that
>> mine slightly more than 20% of blocks, I could wait until block sizes
>> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
>> "/BV5000001/" for the remaining 10%.  If others don't consistently vote
>> for the same "/BV#/" value, vote too consistently and have their value
>> thrown out as the top 20%, I could win the resize to half capacity
>> "/BV5000001/" because it was the lowest repeated value not in the bottom
>> 20%.
>>=20
>> I could use this to force an exodus to my sidechain/alt coin, or to
>> choke out the bitcoin network.  A first improvement would be to only let
>> BIP-100 raise the cap and not lower it, but if I can think of a
>> vulnerability off the top of my head, there will be others on the other
>> side of the equation that have not been thought of.  Why bother
>> introducing a rube goldberg machine like voting when a simple 8mb cap
>> with predictable growth gets the job done, potentially permanently?
>>=20
>>=20
>> On 6/23/2015 9:43 PM, odinn wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > 1) Hard fork not (necessarily) needed
>> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
>> > your stuff," but rather simply to say, "Better you should work with
>> > Garzik to implement BIP-100, that would be good")
>> > 3) See points 1 and 2 above
>> > 4) If still reading... changes should be (as you seem to have been
>> > trying to lean towards)... lean towards gradual change; hence, changes
>> > that would flow from this BIP would be better off oriented in a
>> > process that dies not require the "way you have done it."
>> >
>> > You did address that, to be fair - in your TODO, this link:
>> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>> >
>> > contained the following link:
>> >
>> > http://gavinandresen.ninja/bigger-blocks-another-way
>> >
>> > However, in reading that, I didn't see any meaningful statements that
>> > would refute the approach in Garzik's BIP-100.
>> >
>> > Maybe a better way to say this is,
>> >
>> > Work with Jeff Garzik (which I am sure you are already having such
>> > discussions in private) as well as the list discussions,
>> > Move forward on BIP-100 with Garzik and other developers (not such a
>> > bad plan really) and don't get caught up in XT.  (If you feel you can
>> > develop XT further, that is your thing but it would perhaps make you
>> > lose focus, work together with other developers.)
>> >
>> > Relax into the process.  Things will be ok.
>> >
>> > Respectfully,
>> >
>> > - -O
>> >
>> > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
>> >> I promised to write a BIP after I'd implemented
>> >> increase-the-maximum-block-size code, so here it is. It also lives
>> >> at:
>> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki=

>> >>
>> >>  I don't expect any proposal to please everybody; there are
>> >> unavoidable tradeoffs to increasing the maximum block size. I
>> >> prioritize implementation simplicity -- it is hard to write
>> >> consensus-critical code, so simpler is better.
>> >>
>> >>
>> >>
>> >>
>> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
>> >> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status:
>> >> Draft Type: Standards Track Created: 2015-06-22
>> >>
>> >> =3D=3DAbstract=3D=3D
>> >>
>> >> This BIP proposes replacing the fixed one megabyte maximum block
>> >> size with a maximum size that grows over time at a predictable
>> >> rate.
>> >>
>> >> =3D=3DMotivation=3D=3D
>> >>
>> >> Transaction volume on the Bitcoin network has been growing, and
>> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
>> >> the one megabyte maximum block size. Increasing the maximum size
>> >> reduces the impact of that limit on Bitcoin adoption and growth.
>> >>
>> >> =3D=3DSpecification=3D=3D
>> >>
>> >> After deployment on the network (see the Deployment section for
>> >> details), the maximum allowed size of a block on the main network
>> >> shall be calculated based on the timestamp in the block header.
>> >>
>> >> The maximum size shall be 8,000,000 bytes at a timestamp of
>> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
>> >> every 63,072,000 seconds (two years, ignoring leap years), until
>> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
>> >> blocks in between doublings will increase linearly based on the
>> >> block's timestamp. The maximum size of blocks after 2036-01-06
>> >> 00:00:00 UTC shall be 8,192,000,000 bytes.
>> >>
>> >> Expressed in pseudo-code, using integer math:
>> >>
>> >> function max_block_size(block_timestamp):
>> >>
>> >> time_start =3D 1452470400 time_double =3D 60*60*24*365*2 size_start =3D=

>> >> 8000000 if block_timestamp >=3D time_start+time_double*10 return
>> >> size_start * 2^10
>> >>
>> >> // Piecewise-linear-between-doublings growth: time_delta =3D
>> >> block_timestamp - t_start doublings =3D time_delta / time_double
>> >> remainder =3D time_delta % time_double interpolate =3D (size_start *
>> >> 2^doublings * remainder) / time_double max_size =3D size_start *
>> >> 2^doublings + interpolate
>> >>
>> >> return max_size
>> >>
>> >> =3D=3DDeployment=3D=3D
>> >>
>> >> Deployment shall be controlled by hash-power supermajority vote
>> >> (similar to the technique used in BIP34), but the earliest possible
>> >> activation time is 2016-01-11 00:00:00 UTC.
>> >>
>> >> Activation is achieved when 750 of 1,000 consecutive blocks in the
>> >> best chain have a version number with bits 3 and 14 set (0x20000004
>> >> in hex). The activation time will be the timestamp of the 750'th
>> >> block plus a two week (1,209,600 second) grace period to give any
>> >> remaining miners or services time to upgrade to support larger
>> >> blocks. If a supermajority is achieved more than two weeks before
>> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
>> >> 00:00:00 UTC.
>> >>
>> >> Block version numbers are used only for activation; once activation
>> >> is achieved, the maximum block size shall be as described in the
>> >> specification section, regardless of the version number of the
>> >> block.
>> >>
>> >>
>> >> =3D=3DRationale=3D=3D
>> >>
>> >> The initial size of 8,000,000 bytes was chosen after testing the
>> >> current reference implementation code with larger block sizes and
>> >> receiving feedback from miners stuck behind bandwidth-constrained
>> >> networks (in particular, Chinese miners behind the Great Firewall
>> >> of China).
>> >>
>> >> The doubling interval was chosen based on long-term growth trends
>> >> for CPU power, storage, and Internet bandwidth. The 20-year limit
>> >> was chosen because exponential growth cannot continue forever.
>> >>
>> >> Calculations are based on timestamps and not blockchain height
>> >> because a timestamp is part of every block's header. This allows
>> >> implementations to know a block's maximum size after they have
>> >> downloaded it's header, but before downloading any transactions.
>> >>
>> >> The deployment plan is taken from Jeff Garzik's proposed BIP100
>> >> block size increase, and is designed to give miners, merchants,
>> >> and full-node-running-end-users sufficient time to upgrade to
>> >> software that supports bigger blocks. A 75% supermajority was
>> >> chosen so that one large mining pool does not have effective veto
>> >> power over a blocksize increase. The version number scheme is
>> >> designed to be compatible with Pieter's Wuille's proposed "Version
>> >> bits" BIP.
>> >>
>> >> TODO: summarize objections/arguments from
>> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
>> >>
>> >> TODO: describe other proposals and their advantages/disadvantages
>> >> over this proposal.
>> >>
>> >>
>> >> =3D=3DCompatibility=3D=3D
>> >>
>> >> This is a hard-forking change to the Bitcoin protocol; anybody
>> >> running code that fully validates blocks must upgrade before the
>> >> activation time or they will risk rejecting a chain containing
>> >> larger-than-one-megabyte blocks.
>> >>
>> >> Simplified Payment Verification software is not affected, unless
>> >> it makes assumptions about the maximum depth of a transaction's
>> >> merkle branch based on the minimum size of a transaction and the
>> >> maximum block size.
>> >>
>> >> =3D=3DImplementation=3D=3D
>> >>
>> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
>> >>
>> >>
>> >>
>> >> _______________________________________________ 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
>> >
>> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
>> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
>> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
>> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
>> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
>> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=3D
>> > =3Dft62
>> > -----END PGP SIGNATURE-----
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20

--Apple-Mail-26E99BC2-750F-4D87-8BDA-E715EC572737
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><span></span></div><div><div>Yes, but w=
ith a key distinction. &nbsp; Today miners may collude to (or unintentionall=
y) lower the block size limit for blocks they win. &nbsp;BIP-100 introduces t=
he possibility of lowering the block size limit for everyone over the next 1=
2,000 blocks.</div><div><br></div><div>Another gap involves laziness. &nbsp;=
What is a far more likely issue is not a conspiracy but that miners will be l=
azy and hard code their vote values, requiring arm twisting later to change t=
hem. &nbsp;Preventing this headache introduces the need for more complexity,=
 either by making the default a non-vote (which makes it easier to game the s=
ystem with less voting power), or by making the default vote =3D&nbsp;<span s=
tyle=3D"background-color: rgba(255, 255, 255, 0);">MAX_BLOCK_SIZE * 1.09 (</=
span>which makes the default similar is to Gavin's proposal).</div><div><br>=
</div><div>I think with a default vote that is ~9% larger than the previous m=
ax block size and no option to lower the max block size then BIP-100 could w=
ork without added risk or defeating the intended purpose. &nbsp;Still, one h=
as to ask if the benefit is there to justify the additional moving parts.</d=
iv><div><br>On Jun 23, 2015, at 11:49 PM, Jeff Garzik &lt;<a href=3D"mailto:=
jgarzik@gmail.com">jgarzik@gmail.com</a>&gt; wrote:<br><br></div><blockquote=
 type=3D"cite"><div><div dir=3D"ltr">Miners can collude today to lower the b=
lock size limit.<div><br></div><div>In fact, this largely happens already ou=
t of laziness - miners often follow the "soft" default limit set by Bitcoin C=
ore, to the point where you can chart when miners upgrade to new software:&n=
bsp;<a href=3D"http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bit=
coin-block">http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoi=
n-block</a></div><div><br></div><div><br></div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Tue, Jun 23, 2015 at 8:05 PM, William M=
adden <span dir=3D"ltr">&lt;<a href=3D"mailto:will.madden@novauri.com" targe=
t=3D"_blank">will.madden@novauri.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">Here are refutations of the approach in BIP-100 here:<br>
<a href=3D"http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf"=
 rel=3D"noreferrer" target=3D"_blank">http://gtf.org/garzik/bitcoin/BIP100-b=
locksizechangeproposal.pdf</a><br>
<br>
To recap BIP-100:<br>
<br>
1) Hard form to remove static 1MB block size limit<br>
2) Add new floating block size limit set to 1MB<br>
3) Historical 32MB message limit remains<br>
4) Hard form on testnet 9/1/2015<br>
5) Hard form on main 1/11/2016<br>
6) 1MB limit changed via one-way lock in upgrade with a 12,000 block<br>
threshold by 90% of blocks<br>
7) Limit increase or decrease may not exceed 2x in any one step<br>
8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase<br>
scriptSig, e.g. "/BV8000000/" to vote for 8M.<br>
9) Votes are evaluated by dropping bottom 20% and top 20%, and then the<br>
most common floor (minimum) is chosen.<br>
<br>
8MB limits doubling just under every 2 years makes a static value grow<br>
in a predictable manner.<br>
<br>
BIP-100 makes a static value grow (or more importantly potentially<br>
shrink) in an unpredictable manner based on voting mechanics that are<br>
untested in this capacity in the bitcoin network.&nbsp; Introducing a highly=
<br>
variable and untested dynamic into an already complex system is<br>
unnecessarily risky.<br>
<br>
For example, the largely arbitrary voting rules listed in 9 above can be<br>=

gamed.&nbsp; If I control pools or have affiliates involved in pools that<br=
>
mine slightly more than 20% of blocks, I could wait until block sizes<br>
are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and<br>
"/BV5000001/" for the remaining 10%.&nbsp; If others don't consistently vote=
<br>
for the same "/BV#/" value, vote too consistently and have their value<br>
thrown out as the top 20%, I could win the resize to half capacity<br>
"/BV5000001/" because it was the lowest repeated value not in the bottom<br>=

20%.<br>
<br>
I could use this to force an exodus to my sidechain/alt coin, or to<br>
choke out the bitcoin network.&nbsp; A first improvement would be to only le=
t<br>
BIP-100 raise the cap and not lower it, but if I can think of a<br>
vulnerability off the top of my head, there will be others on the other<br>
side of the equation that have not been thought of.&nbsp; Why bother<br>
introducing a rube goldberg machine like voting when a simple 8mb cap<br>
with predictable growth gets the job done, potentially permanently?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On 6/23/2015 9:43 PM, odinn wrote:<br>
&gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
&gt; Hash: SHA1<br>
&gt;<br>
&gt; 1) Hard fork not (necessarily) needed<br>
&gt; 2) See Garzik's BIP 100, better (this is not meant to say "superior to<=
br>
&gt; your stuff," but rather simply to say, "Better you should work with<br>=

&gt; Garzik to implement BIP-100, that would be good")<br>
&gt; 3) See points 1 and 2 above<br>
&gt; 4) If still reading... changes should be (as you seem to have been<br>
&gt; trying to lean towards)... lean towards gradual change; hence, changes<=
br>
&gt; that would flow from this BIP would be better off oriented in a<br>
&gt; process that dies not require the "way you have done it."<br>
&gt;<br>
&gt; You did address that, to be fair - in your TODO, this link:<br>
&gt; <a href=3D"http://gavinandresen.ninja/time-to-roll-out-bigger-blocks" r=
el=3D"noreferrer" target=3D"_blank">http://gavinandresen.ninja/time-to-roll-=
out-bigger-blocks</a><br>
&gt;<br>
&gt; contained the following link:<br>
&gt;<br>
&gt; <a href=3D"http://gavinandresen.ninja/bigger-blocks-another-way" rel=3D=
"noreferrer" target=3D"_blank">http://gavinandresen.ninja/bigger-blocks-anot=
her-way</a><br>
&gt;<br>
&gt; However, in reading that, I didn't see any meaningful statements that<b=
r>
&gt; would refute the approach in Garzik's BIP-100.<br>
&gt;<br>
&gt; Maybe a better way to say this is,<br>
&gt;<br>
&gt; Work with Jeff Garzik (which I am sure you are already having such<br>
&gt; discussions in private) as well as the list discussions,<br>
&gt; Move forward on BIP-100 with Garzik and other developers (not such a<br=
>
&gt; bad plan really) and don't get caught up in XT.&nbsp; (If you feel you c=
an<br>
&gt; develop XT further, that is your thing but it would perhaps make you<br=
>
&gt; lose focus, work together with other developers.)<br>
&gt;<br>
&gt; Relax into the process.&nbsp; Things will be ok.<br>
&gt;<br>
&gt; Respectfully,<br>
&gt;<br>
&gt; - -O<br>
&gt;<br>
&gt; On 06/22/2015 11:18 AM, Gavin Andresen wrote:<br>
&gt;&gt; I promised to write a BIP after I'd implemented<br>
&gt;&gt; increase-the-maximum-block-size code, so here it is. It also lives<=
br>
&gt;&gt; at:<br>
&gt;&gt; <a href=3D"https://github.com/gavinandresen/bips/blob/blocksize/bip=
-8MB.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/gavi=
nandresen/bips/blob/blocksize/bip-8MB.mediawiki</a><br>
&gt;&gt;<br>
&gt;&gt;&nbsp; I don't expect any proposal to please everybody; there are<br=
>
&gt;&gt; unavoidable tradeoffs to increasing the maximum block size. I<br>
&gt;&gt; prioritize implementation simplicity -- it is hard to write<br>
&gt;&gt; consensus-critical code, so simpler is better.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen<b=
r>
&gt;&gt; &lt;<a href=3D"mailto:gavinandresen@gmail.com">gavinandresen@gmail.=
com</a> &lt;mailto:<a href=3D"mailto:gavinandresen@gmail.com">gavinandresen@=
gmail.com</a>&gt;&gt; Status:<br>
&gt;&gt; Draft Type: Standards Track Created: 2015-06-22<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DAbstract=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; This BIP proposes replacing the fixed one megabyte maximum block<br=
>
&gt;&gt; size with a maximum size that grows over time at a predictable<br>
&gt;&gt; rate.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DMotivation=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; Transaction volume on the Bitcoin network has been growing, and<br>=

&gt;&gt; will soon reach the one-megabyte-every-ten-minutes limit imposed by=
<br>
&gt;&gt; the one megabyte maximum block size. Increasing the maximum size<br=
>
&gt;&gt; reduces the impact of that limit on Bitcoin adoption and growth.<br=
>
&gt;&gt;<br>
&gt;&gt; =3D=3DSpecification=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; After deployment on the network (see the Deployment section for<br>=

&gt;&gt; details), the maximum allowed size of a block on the main network<b=
r>
&gt;&gt; shall be calculated based on the timestamp in the block header.<br>=

&gt;&gt;<br>
&gt;&gt; The maximum size shall be 8,000,000 bytes at a timestamp of<br>
&gt;&gt; 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double<br=
>
&gt;&gt; every 63,072,000 seconds (two years, ignoring leap years), until<br=
>
&gt;&gt; 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of=
<br>
&gt;&gt; blocks in between doublings will increase linearly based on the<br>=

&gt;&gt; block's timestamp. The maximum size of blocks after 2036-01-06<br>
&gt;&gt; 00:00:00 UTC shall be 8,192,000,000 bytes.<br>
&gt;&gt;<br>
&gt;&gt; Expressed in pseudo-code, using integer math:<br>
&gt;&gt;<br>
&gt;&gt; function max_block_size(block_timestamp):<br>
&gt;&gt;<br>
&gt;&gt; time_start =3D 1452470400 time_double =3D 60*60*24*365*2 size_start=
 =3D<br>
&gt;&gt; 8000000 if block_timestamp &gt;=3D time_start+time_double*10 return=
<br>
&gt;&gt; size_start * 2^10<br>
&gt;&gt;<br>
&gt;&gt; // Piecewise-linear-between-doublings growth: time_delta =3D<br>
&gt;&gt; block_timestamp - t_start doublings =3D time_delta / time_double<br=
>
&gt;&gt; remainder =3D time_delta % time_double interpolate =3D (size_start *=
<br>
&gt;&gt; 2^doublings * remainder) / time_double max_size =3D size_start *<br=
>
&gt;&gt; 2^doublings + interpolate<br>
&gt;&gt;<br>
&gt;&gt; return max_size<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DDeployment=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; Deployment shall be controlled by hash-power supermajority vote<br>=

&gt;&gt; (similar to the technique used in BIP34), but the earliest possible=
<br>
&gt;&gt; activation time is 2016-01-11 00:00:00 UTC.<br>
&gt;&gt;<br>
&gt;&gt; Activation is achieved when 750 of 1,000 consecutive blocks in the<=
br>
&gt;&gt; best chain have a version number with bits 3 and 14 set (0x20000004=
<br>
&gt;&gt; in hex). The activation time will be the timestamp of the 750'th<br=
>
&gt;&gt; block plus a two week (1,209,600 second) grace period to give any<b=
r>
&gt;&gt; remaining miners or services time to upgrade to support larger<br>
&gt;&gt; blocks. If a supermajority is achieved more than two weeks before<b=
r>
&gt;&gt; 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11<br>=

&gt;&gt; 00:00:00 UTC.<br>
&gt;&gt;<br>
&gt;&gt; Block version numbers are used only for activation; once activation=
<br>
&gt;&gt; is achieved, the maximum block size shall be as described in the<br=
>
&gt;&gt; specification section, regardless of the version number of the<br>
&gt;&gt; block.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DRationale=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; The initial size of 8,000,000 bytes was chosen after testing the<br=
>
&gt;&gt; current reference implementation code with larger block sizes and<b=
r>
&gt;&gt; receiving feedback from miners stuck behind bandwidth-constrained<b=
r>
&gt;&gt; networks (in particular, Chinese miners behind the Great Firewall<b=
r>
&gt;&gt; of China).<br>
&gt;&gt;<br>
&gt;&gt; The doubling interval was chosen based on long-term growth trends<b=
r>
&gt;&gt; for CPU power, storage, and Internet bandwidth. The 20-year limit<b=
r>
&gt;&gt; was chosen because exponential growth cannot continue forever.<br>
&gt;&gt;<br>
&gt;&gt; Calculations are based on timestamps and not blockchain height<br>
&gt;&gt; because a timestamp is part of every block's header. This allows<br=
>
&gt;&gt; implementations to know a block's maximum size after they have<br>
&gt;&gt; downloaded it's header, but before downloading any transactions.<br=
>
&gt;&gt;<br>
&gt;&gt; The deployment plan is taken from Jeff Garzik's proposed BIP100<br>=

&gt;&gt; block size increase, and is designed to give miners, merchants,<br>=

&gt;&gt; and full-node-running-end-users sufficient time to upgrade to<br>
&gt;&gt; software that supports bigger blocks. A 75% supermajority was<br>
&gt;&gt; chosen so that one large mining pool does not have effective veto<b=
r>
&gt;&gt; power over a blocksize increase. The version number scheme is<br>
&gt;&gt; designed to be compatible with Pieter's Wuille's proposed "Version<=
br>
&gt;&gt; bits" BIP.<br>
&gt;&gt;<br>
&gt;&gt; TODO: summarize objections/arguments from<br>
&gt;&gt; <a href=3D"http://gavinandresen.ninja/time-to-roll-out-bigger-block=
s" rel=3D"noreferrer" target=3D"_blank">http://gavinandresen.ninja/time-to-r=
oll-out-bigger-blocks</a>.<br>
&gt;&gt;<br>
&gt;&gt; TODO: describe other proposals and their advantages/disadvantages<b=
r>
&gt;&gt; over this proposal.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DCompatibility=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; This is a hard-forking change to the Bitcoin protocol; anybody<br>
&gt;&gt; running code that fully validates blocks must upgrade before the<br=
>
&gt;&gt; activation time or they will risk rejecting a chain containing<br>
&gt;&gt; larger-than-one-megabyte blocks.<br>
&gt;&gt;<br>
&gt;&gt; Simplified Payment Verification software is not affected, unless<br=
>
&gt;&gt; it makes assumptions about the maximum depth of a transaction's<br>=

&gt;&gt; merkle branch based on the minimum size of a transaction and the<br=
>
&gt;&gt; maximum block size.<br>
&gt;&gt;<br>
&gt;&gt; =3D=3DImplementation=3D=3D<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"https://github.com/gavinandresen/bitcoinxt/tree/blocksiz=
e_fork" rel=3D"noreferrer" target=3D"_blank">https://github.com/gavinandrese=
n/bitcoinxt/tree/blocksize_fork</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________ bitcoin-dev mailing=
<br>
&gt;&gt; list <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.o=
rg/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt;<br>
&gt;<br>
&gt; - --<br>
&gt; <a href=3D"http://abis.io" rel=3D"noreferrer" target=3D"_blank">http://=
abis.io</a> ~<br>
&gt; "a protocol concept to enable decentralization<br>
&gt; and expansion of a giving economy, and a new social good"<br>
&gt; <a href=3D"https://keybase.io/odinn" rel=3D"noreferrer" target=3D"_blan=
k">https://keybase.io/odinn</a><br>
&gt; -----BEGIN PGP SIGNATURE-----<br>
&gt; Version: GnuPG v1<br>
&gt;<br>
&gt; iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175<br>
&gt; Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+<br>
&gt; K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw<br>
&gt; OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN<br>
&gt; fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s<br>
&gt; CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=3D<br>
&gt; =3Dft62<br>
&gt; -----END PGP SIGNATURE-----<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/m=
ailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div></body></html>=

--Apple-Mail-26E99BC2-750F-4D87-8BDA-E715EC572737--