From d218b6470f1afeb503e4cafc8b0bb49b596bc1a3 Mon Sep 17 00:00:00 2001 From: UpalChakraborty Date: Fri, 4 Sep 2015 17:38:32 +0530 Subject: [PATCH 1/2] Create BIP-1xx.mediawiki --- BIP-1xx.mediawiki | 80 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 BIP-1xx.mediawiki diff --git a/BIP-1xx.mediawiki b/BIP-1xx.mediawiki new file mode 100644 index 0000000000..c642b014bf --- /dev/null +++ b/BIP-1xx.mediawiki @@ -0,0 +1,80 @@ +
+  BIP: 1xx
+  Title: Dynamically Controlled Bitcoin Block Size Max Cap
+  Author: Upal Chakraborty 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-08-24
+
+ +==Abstract== + +This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... + +i. Depending only on previous block size calculation. + +ii. Depending on previous block size calculation and previous Tx fee collected by miners. + +==Motivation== + +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 changes itself with changing network demand, then adoption will hamper and bitcoin's growth may choke up. Following graph shows the change in average block size since inception... + +https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address= + +==Specification== + +===Proposal 1 : Depending only on previous block size calculation=== + + 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 + +===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== + + TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period + TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) + + TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period + TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) + + If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) ) + MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty + Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) ) + MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty + Else + Keep the same MaxBlockSize + +==Rationale== + +These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguements can be found [http://upalc.com/maxblocksize.php here]. + +===Proposal 1 : Depending only on previous block size calculation=== + +This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. + +===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== + +This solution takes care of stable mining subsidy. It will not increase maximum block size, if Tx fee collection is not increasing and thereby creating 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 party because the increase or decrease of block size max cap will take place in the same ratio of average block size increase or decrease. + +==Compatibility== + +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. + +==Other solutions considered== + +[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf Making Decentralized Economic Policy] - by Jeff Garzik + +[https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap with rollover penalties] - by Meni Rosenfeld + +[https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki Increase maximum block size] - by Gavin Andresen + +[https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following technological growth] - by Pieter Wuille + +[https://lightning.network/lightning-network-paper.pdf The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus Dryja + +==Deployment== + +If consensus is achieved, deployment can be made at a future block number at which difficulty will change. From 1e6e07809d6756091025dab472b9392f054c4244 Mon Sep 17 00:00:00 2001 From: UpalChakraborty Date: Sun, 6 Sep 2015 01:22:34 +0530 Subject: [PATCH 2/2] Update and rename BIP-1xx.mediawiki to bip-0106.mediawiki --- BIP-1xx.mediawiki => bip-0106.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename BIP-1xx.mediawiki => bip-0106.mediawiki (99%) diff --git a/BIP-1xx.mediawiki b/bip-0106.mediawiki similarity index 99% rename from BIP-1xx.mediawiki rename to bip-0106.mediawiki index c642b014bf..e9018fac9f 100644 --- a/BIP-1xx.mediawiki +++ b/bip-0106.mediawiki @@ -1,5 +1,5 @@ 
-  BIP: 1xx
+  BIP: 106
   Title: Dynamically Controlled Bitcoin Block Size Max Cap
   Author: Upal Chakraborty 
   Status: Draft