Github: https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBloc=
kSize.mediawiki

<pre>
  BIP: 1xx
  Title: Dynamically Controlled Bitcoin Block Size Max Cap
  Author: Upal Chakraborty <bitcoin=
@upalc.com>
  Status: Draft
  Type: Standards Track
  Created: 2015-08-24
</pre>

=3D=3DAbstract=3D=3D

This BIP proposes replacing the fixed one megabyte maximum block size with =
a dynamically controlled maximum block size that may increase or decrease w=
ith difficulty change depending on various network factors. I have two prop=
osals regarding this...

i. Depending only on previous block size calculation.

ii. Depending on previous block size calculation and previous Tx fee collec=
ted by miners.

=3D=3DMotivation=3D=3D

With increased adoption, transaction volume on bitcoin network is bound to =
grow. If the one megabyte max cap is not changed to a flexible one which ch=
anges itself with changing network demand, then adoption will hamper and bi=
tcoin's growth may choke up. Following graph shows the change in averag=
e block size since inception...

https://blockchain.info/charts/avg-block-size?t=
imespan=3Dall&showDataPoints=3Dfalse&daysAverageString=3D1&show=
_header=3Dtrue&scale=3D0&address=3D

=3D=3DSpecification=3D=3D

=3D=3D=3DProposal 1 : Depending only on previous block size calculation=3D=
=3D=3D

  If more than 50% of block's size, found in the first 2000 of the last=
 difficulty period, is more than 90% MaxBlockSize
      Double MaxBlockSize
  Else if more than 90% of block's size, found in the first 2000 of the=
 last difficulty period, is less than 50% MaxBlockSize
      Half MaxBlockSize
  Else
      Keep the same MaxBlockSize

=3D=3D=3DProposal 2 : Depending on previous block size calculation and prev=
ious Tx fee collected by miners=3D=3D=3D
 =20
  TotalBlockSizeInLastButOneDifficulty =3D Sum of all Block size of first 2=
008 blocks in last 2 difficulty period
  TotalBlockSizeInLastDifficulty =3D Sum of all Block size of second 2008 b=
locks in last 2 difficulty period (This actually includes 8 blocks from las=
t but one difficulty)
 =20
  TotalTxFeeInLastButOneDifficulty =3D Sum of all Tx fees of first 2008 blo=
cks in last 2 difficulty period
  TotalTxFeeInLastDifficulty =3D Sum of all Tx fees of second 2008 blocks i=
n last 2 difficulty period (This actually includes 8 blocks from last but o=
ne difficulty)
 =20
  If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 &g=
t; 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastB=
utOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInL=
astButOneDifficulty) )
      MaxBlockSize =3D TotalBlockSizeInLastDifficulty * MaxBlockSize / Tota=
lBlockSizeInLastButOneDifficulty
  Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/40=
16 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeIn=
LastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSi=
zeInLastButOneDifficulty) )
      MaxBlockSize =3D TotalBlockSizeInLastDifficulty * MaxBlockSize / Tota=
lBlockSizeInLastButOneDifficulty
  Else
      Keep the same MaxBlockSize

=3D=3DRationale=3D=3D

These two proposals have been derived after discussion on [https://bitcointalk.org/ind=
ex.php?topic=3D1154536.0 BitcoinTalk] and [http://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitc=
oin-dev mailing list]. The original idea and its evolution in the light of =
various arguements can be found [http://upalc.com/maxblocksize.php here].

=3D=3D=3DProposal 1 : Depending only on previous block size calculation=3D=
=3D=3D

This solution is derived directly from the indication of the problem. If tr=
ansaction volume increases, then we will naturally see bigger blocks. On th=
e contrary, if there are not enough transaction volume, but maximum block s=
ize is high, then only few blocks may sweep the mempool. Hence, if block si=
ze is itself taken into consideration, then maximum block size can most rat=
ionally be derived. Moreover, this solution not only increases, but also de=
creases the maximum block size, just like difficulty.

=3D=3D=3DProposal 2 : Depending on previous block size calculation and prev=
ious Tx fee collected by miners=3D=3D=3D

This solution takes care of stable mining subsidy. It will not increase max=
imum block size, if Tx fee collection is not increasing and thereby creatin=
g a Tx fee pressure on the market. On the other hand, though the block size=
 max cap is dynamically controlled, it is very difficult to game by any par=
ty because the increase or decrease of block size max cap will take place i=
n the same ratio of average block size increase or decrease.

=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 the=
y will risk rejecting a chain containing larger-than-one-megabyte blocks.

=3D=3DOther solutions considered=3D=3D

[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Mak=
ing Decentralized Economic Policy] - by Jeff Garzik

[https://bi=
tcointalk.org/index.php?topic=3D1078521.0 Elastic block cap with rollov=
er penalties] - by Meni Rosenfeld

[https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki Increas=
e maximum block size] - by Gavin Andresen

[https://gist=
.github.com/sipa/c65665fc360ca7a176a6 Block size following technologica=
l growth] - by Pieter Wuille

[https://=
lightning.network/lightning-network-paper.pdf The Bitcoin Lightning Net=
work: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus =
Dryja

=3D=3DDeployment=3D=3D

If consensus is achieved, deployment can be made at a future block number a=
t which difficulty will change.