Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 40496ABF for ; 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 ; Wed, 24 Jun 2015 13:06:45 +0000 (UTC) Received: by qkeo142 with SMTP id o142so21232527qke.1 for ; 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 X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 24 Jun 2015 09:06:40 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2DC61141-96C9-4727-81D6-3CF572BC6BD7@novauri.com> References: <558A0B4A.7090205@riseup.net> <558A1E8E.30306@novauri.com> To: Jeff Garzik 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 = 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 >> >> > 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
Yes, but w= ith a key distinction.   Today miners may collude to (or unintentionall= y) 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 conspiracy but that miners will be l= azy and hard code their vote values, requiring arm twisting later to change t= hem.  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 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 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.  Still, one h= as to ask if the benefit is there to justify the additional moving parts.

On Jun 23, 2015, at 11:49 PM, Jeff Garzik <jgarzik@gmail.com> wrote:

Miners can collude today to lower the b= lock size limit.

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;http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoi= n-block



On Tue, Jun 23, 2015 at 8:05 PM, William M= adden <will.madden@novauri.com> wrote:
Here are refutations of the approach in BIP-100 here:
http://gtf.org/garzik/bitcoin/BIP100-b= locksizechangeproposal.pdf

To recap BIP-100:

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.

8MB limits doubling just under every 2 years makes a static value grow
in a predictable manner.

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.

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

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 le= t
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?


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<= br> > 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<= br> > 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-anot= her-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 c= an
> 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<= br> >> at:
>> https://github.com/gavi= nandresen/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<= br> >> 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<= br> >> bits" BIP.
>>
>> TODO: summarize objections/arguments from
>> http://gavinandresen.ninja/time-to-r= oll-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/gavinandrese= n/bitcoinxt/tree/blocksize_fork
>>
>>
>>
>> _______________________________________________ bitcoin-dev mailing=
>> list bitco= in-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.o= rg/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@li= sts.linuxfoundation.org
> https://lists.linuxfoundation.org/m= ailman/listinfo/bitcoin-dev
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.l= inuxfoundation.org
https://lists.linuxfoundation.org/mailma= n/listinfo/bitcoin-dev

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