From ba4062ab0d1b88e598487e1db5ae6113dd65b3f8 Mon Sep 17 00:00:00 2001 From: BtcDrak Date: Fri, 28 Aug 2015 01:34:48 +0100 Subject: 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 0000000..bbc7288 --- /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. -- cgit v1.2.3 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: 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 bbc7288..201ab72 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
-- 
cgit v1.2.3


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: Rename bip-cbbrsa.mediawiki to bip-0105.mediawiki

---
 bip-0105.mediawiki   | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 bip-cbbrsa.mediawiki | 95 ----------------------------------------------------
 2 files changed, 95 insertions(+), 95 deletions(-)
 create mode 100644 bip-0105.mediawiki
 delete mode 100644 bip-cbbrsa.mediawiki

diff --git a/bip-0105.mediawiki b/bip-0105.mediawiki
new file mode 100644
index 0000000..201ab72
--- /dev/null
+++ b/bip-0105.mediawiki
@@ -0,0 +1,95 @@
+
+  BIP: 105
+  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.
diff --git a/bip-cbbrsa.mediawiki b/bip-cbbrsa.mediawiki
deleted file mode 100644
index 201ab72..0000000
--- a/bip-cbbrsa.mediawiki
+++ /dev/null
@@ -1,95 +0,0 @@
-
-  BIP: 105
-  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.
-- 
cgit v1.2.3


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: 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 201ab72..7aaef04 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==
-- 
cgit v1.2.3