From ba4062ab0d1b88e598487e1db5ae6113dd65b3f8 Mon Sep 17 00:00:00 2001 From: BtcDrak Date: Fri, 28 Aug 2015 01:34:48 +0100 Subject: [PATCH 1/4] Initial commit Transferring from gist https://gist.github.com/btcdrak/1c3a323100a912b605b5 --- bip-cbbrsa.mediawiki | 95 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 bip-cbbrsa.mediawiki diff --git a/bip-cbbrsa.mediawiki b/bip-cbbrsa.mediawiki new file mode 100644 index 00000000..bbc72881 --- /dev/null +++ b/bip-cbbrsa.mediawiki @@ -0,0 +1,95 @@ +
+  BIP: XX
+  Title: Consensus based block size retargeting algorithm
+  Author: BtcDrak 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-08-21
+
+ +==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. + + +==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. + + +==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. From 2a91434263790dca69799d2517edcbaab8340f14 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E0=B8=BFtcDrak?= Date: Wed, 2 Sep 2015 00:56:09 +0100 Subject: [PATCH 2/4] Update with BIP 105 assignment. --- bip-cbbrsa.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-cbbrsa.mediawiki b/bip-cbbrsa.mediawiki index bbc72881..201ab72a 100644 --- a/bip-cbbrsa.mediawiki +++ b/bip-cbbrsa.mediawiki @@ -1,5 +1,5 @@
-  BIP: XX
+  BIP: 105
   Title: Consensus based block size retargeting algorithm
   Author: BtcDrak 
   Status: Draft

From 314a488b382b92e93b78d61d509fdcf58fa8f62c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E0=B8=BFtcDrak?= 
Date: Wed, 2 Sep 2015 00:57:10 +0100
Subject: [PATCH 3/4] Rename bip-cbbrsa.mediawiki to bip-0105.mediawiki

---
 bip-cbbrsa.mediawiki => bip-0105.mediawiki | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename bip-cbbrsa.mediawiki => bip-0105.mediawiki (100%)

diff --git a/bip-cbbrsa.mediawiki b/bip-0105.mediawiki
similarity index 100%
rename from bip-cbbrsa.mediawiki
rename to bip-0105.mediawiki

From ff3d0a98b0637b6116aaba137257c304b850270e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E0=B8=BFtcDrak?= 
Date: Wed, 2 Sep 2015 01:15:35 +0100
Subject: [PATCH 4/4] Add bounded limits to blocksize

Choosing 8MB because currently the consensus among miners
is 8MB is the largest tolerable size.
---
 bip-0105.mediawiki | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/bip-0105.mediawiki b/bip-0105.mediawiki
index 201ab72a..7aaef044 100644
--- a/bip-0105.mediawiki
+++ b/bip-0105.mediawiki
@@ -48,6 +48,11 @@ 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==
 
@@ -81,7 +86,7 @@ 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.
+The base block size limit may not reduce below 1MB or increase above 8MB.
 
 
 ==Acknowledgements==