summaryrefslogtreecommitdiff
path: root/bip-0105.mediawiki
diff options
context:
space:
mode:
Diffstat (limited to 'bip-0105.mediawiki')
-rw-r--r--bip-0105.mediawiki24
1 files changed, 12 insertions, 12 deletions
diff --git a/bip-0105.mediawiki b/bip-0105.mediawiki
index 3643562..af41691 100644
--- a/bip-0105.mediawiki
+++ b/bip-0105.mediawiki
@@ -13,21 +13,21 @@
==Abstract==
-A method of altering the maximum allowed block size of the Bitcoin protocol
+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
+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
+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.
@@ -36,14 +36,14 @@ 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.
+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
+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
@@ -63,7 +63,7 @@ honest.
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
+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 transaction scriptSig.
@@ -77,7 +77,7 @@ 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
+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.