Merge pull request #187 from btcdrak/bip-cbbsra

BIP105: Consensus based block size retargeting algorithm

bip-0105.mediawiki

@@ -0,0 +1,100 @@
+<pre>
+  BIP: 105
+  Title: Consensus based block size retargeting algorithm
+  Author: BtcDrak <btcdrak@gmail.com>
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-08-21
+</pre>
+
+==Abstract==
+
+A method of altering the maximum allowed block size of the Bitcoin protocol 
+using a consensus based approach.
+
+==Motivation==
+
+There is a belief that Bitcoin cannot easily respond to raising the 
+blocksize limit if popularity was to suddenly increase due to a mass adoption 
+curve, because co-ordinating a hard fork takes considerable time, and being 
+unable to respond in a timely manner would irreparably harm the credibility of 
+bitcoin.
+
+Additionally, predetermined block size increases are problematic because they
+attempt to predict the future, and if too large could have unintended 
+consequences like damaging the possibility for a fee market to develop 
+as block subsidy decreases substantially over the next 9 years; introducing 
+or exacerbating mining attack vectors; or somehow affect the network in unknown
+or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
+extensive.
+
+Dynamic block size adjustments also suffer from the potential to be gamed by the
+larger hash power.
+
+Free voting as suggested by BIP100 allows miners to sell their votes out of band
+at no risk, and enable the sponsor the ability to manipulate the blocksize. 
+It also provides a cost free method or the larger pools to vote in ways to
+manipulate the blocksize such to disadvantage or attack smaller pools.
+
+
+==Rationale==
+
+By introducing a cost to increase the block size ensures the mining community 
+will collude to increase it only when there is a clear necessity, and reduce it
+when it is unnecessary. Larger miners cannot force their wishes so easily
+because not only will they have to pay extra a difficulty target, then can be
+downvoted at no cost by the objecting hash power.
+
+Using difficulty as a penalty is better than a fixed cost in bitcoins because it
+is less predictable.
+
+In order to prevent miners having complete control over blocksize, an upper
+limit is required at protocol level. This feature ensures full nodes retain
+control over consensus, remembering full nodes are the mechanism to keep miners
+honest.
+
+
+==Specification==
+
+The initial block size limit shall be 1MB.
+
+Each time a miner creates a block, they may vote to increase or decrease the
+blocksize by a maximum of 10% of the current block size limit. These votes will 
+be used to recalculate the new block size limit every 2016 blocks.
+
+Votes are cast using the block's coinbase field.
+
+The first 4 bytes of the coinbase field shall be repurposed for voting as an
+unsigned long integer which will be the block size in bytes.
+
+If a miner votes for an increase, the block hash must meet a difficulty target
+which is proportionally larger than the standard difficulty target based on the
+percentage increase they voted for.
+
+Votes proposing decreasing the block size limit do not need to meet a higher 
+difficulty target.
+
+Miners can vote for no change by voting for the current block size.
+
+For blocks to be valid the blockhash must meet the required difficulty target
+for the vote otherwise the block is invalid and will be rejected.
+
+Every 2016 blocks, the block size limit will be recalculated by the median of
+all votes in the last 2016 blocks. This will redefine the block size limit for
+the next 2016 blocks.
+
+Blocks that are larger than the calculated base block size limit are invalid and
+will be rejected.
+
+The base block size limit may not reduce below 1MB or increase above 8MB.
+
+
+==Acknowledgements==
+
+This proposal is based on ideas and concepts derived from the writings of
+Meni Rosenfeld and Gregory Maxwell.
+
+
+==Copyright==
+
+This work is placed in the public domain.