summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke-Jr <luke_github1@dashjr.org>2015-09-03 22:35:53 +0000
committerLuke-Jr <luke_github1@dashjr.org>2015-09-03 22:35:53 +0000
commita87bf5c5c18a203d63a4dc1a7250fa1e25860634 (patch)
tree7b5024716d9c97e67846d3a49c8f8d024185ee8f
parent77f4c9d9f8bd47a03f3012481a943a61b2f71405 (diff)
parentff3d0a98b0637b6116aaba137257c304b850270e (diff)
downloadbips-a87bf5c5c18a203d63a4dc1a7250fa1e25860634.tar.xz
Merge pull request #187 from btcdrak/bip-cbbsra
BIP105: Consensus based block size retargeting algorithm
-rw-r--r--bip-0105.mediawiki100
1 files changed, 100 insertions, 0 deletions
diff --git a/bip-0105.mediawiki b/bip-0105.mediawiki
new file mode 100644
index 0000000..7aaef04
--- /dev/null
+++ b/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.