summaryrefslogtreecommitdiff
path: root/bip-0101.mediawiki
diff options
context:
space:
mode:
authorGavin Andresen <gavinandresen@gmail.com>2015-07-15 09:56:53 -0400
committerGavin Andresen <gavinandresen@gmail.com>2015-07-15 09:56:53 -0400
commit3248c9f67bd7fcd1d05b8db7c5c56e4788deebfe (patch)
tree0f6af9beed9ca647f650c6dd1a997a72a60c059f /bip-0101.mediawiki
parentfd99a8ce04dbad96fb275e0300a7ee669e70f418 (diff)
Changed version number to 0x20000007 for more compatibility with existing version 1/2/3 blocks
Diffstat (limited to 'bip-0101.mediawiki')
-rw-r--r--bip-0101.mediawiki6
1 files changed, 3 insertions, 3 deletions
diff --git a/bip-0101.mediawiki b/bip-0101.mediawiki
index 0a08d79..9a78255 100644
--- a/bip-0101.mediawiki
+++ b/bip-0101.mediawiki
@@ -44,7 +44,7 @@ Expressed in pseudo-code, using integer math, assuming that block_timestamp is a
Deployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is 2016-01-11 00:00:00 UTC.
-Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits 3 and 14 set (0x20000004 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC.
+Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits 1,2,3 and 14 set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC.
Block version numbers are used only for activation; once activation is achieved, the maximum block size shall be as described in the specification section, regardless of the version number of the block.
@@ -58,7 +58,7 @@ Test network parameters are the same as the main network, except starting earlie
==Rationale==
-The initial size of 8,000,000 bytes was chosen after testing the current reference implementation code with larger block sizes and receiving feedback from miners stuck behind bandwidth-constrained networks (in particular, Chinese miners behind the Great Firewall of China).
+The initial size of 8,000,000 bytes was chosen after testing the current reference implementation code with larger block sizes and receiving feedback from miners on bandwidth-constrained networks (in particular, Chinese miners behind the Great Firewall of China).
The doubling interval was chosen based on long-term growth trends for CPU power, storage, and Internet bandwidth. The 20-year limit was chosen because exponential growth cannot continue forever. If long-term trends do not continue, maximum block sizes can be reduced by miner consensus (a soft-fork).
@@ -110,7 +110,7 @@ However, a one-time increase requires just as much care in testing and deploymen
===Dynamic limit proposals===
-BIP 100 proposes a dynamic limit determined by miner preferences expressed in coinbase transactions, with limits on the rate of growth. It gives miners more direct control over the maximum block size, which some people see as an advantage over this proposal and some see as a disadvantage. It is a little more complex to implement.
+BIP 100 proposes a dynamic limit determined by miner preferences expressed in coinbase transactions, with limits on the rate of growth. It gives miners more direct control over the maximum block size, which some people see as an advantage over this proposal and some see as a disadvantage. It is more complex to implement, because the maximum allowed size for a block depends on information contained in coinbase transactions from previous blocks (which may not be immediately known if block contents are being fetched out-of-order in a 'headers-first' mode).
[https://bitcointalk.org/index.php?topic=1078521.0 Meni Rosenfeld has proposed] that miners sacrifice mining reward to "pay for" bigger blocks, so there is an incentive to create bigger blocks only if transaction fees cover the cost of creating a larger block. This proposal is significantly more complex to implement, and it is not clear if a set of parameters for setting the cost of making a block bigger can be found that is not equivalent to a centrally-controlled network-wide minimum transaction fee.