From 5ad92f06de1036b650bf0bd40c7f89eb5059cb2d Mon Sep 17 00:00:00 2001 From: Jeff Garzik Date: Wed, 8 Mar 2017 11:46:12 -0500 Subject: Add BIP 100, as currently implemented. --- bip-0100.mediawiki | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 bip-0100.mediawiki (limited to 'bip-0100.mediawiki') diff --git a/bip-0100.mediawiki b/bip-0100.mediawiki new file mode 100644 index 0000000..67c2b4c --- /dev/null +++ b/bip-0100.mediawiki @@ -0,0 +1,66 @@ +
+  BIP: 100
+  Title: Dynamic maximum block size by miner vote
+  Author: Jeff Garzik 
+          Tom Harding 
+          Dagur Valberg Johannsson 
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-06-11
+  License: BSD-2-Clause
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100
+
+ +==Abstract== + +Replace the static 1M block size hard limit with a hard limit set by coinbase vote, conducted on the same schedule as difficulty retargeting. + +==Motivation== + +Miners directly feel the effects, both positive and negative, of any maximum block size change imposed by their peers. Larger blocks allow more growth in the on-chain ecosystem, while smaller blocks reduce resource requirements network-wide. Miners also act as an efficient proxy for the rest of the ecosystem, since they are paid in the tokens collected for the blocks they create. + +A simple deterministic system is specified, whereby a 75% mining supermajority may activate a change to the maximum block size each 2016 blocks. Each change is limited to a 5% increase from the previous block size hard limit, or a decrease of similar magnitude. Among adopting nodes, there will be no disagreement on the evolution of the maximum block size. + +The system is compatible with emergent consensus, but whereas under that system a miner may choose to accept any size block, a miner following BIP100 observes the 75% supermajority rule, and the 5% change limit rule. Excessive-block values signaled by emergent consensus blocks are considered in the calculation of the BIP100 block size hard limit, and the BIP100 calculated maximum block size is signaled as an excessive-block value for the benefit of all observers. + +==Specification== + +===Dynamic Maximum Block Size=== +# Initial value of hardLimit is 1000000 bytes, preserving current system. +# Changing hardLimit is accomplished by encoding a proposed value, a vote, within a block's coinbase scriptSig, and by processing the votes contained in the previous retargeting period.

+## Vote encoding +### A vote is represented as a positive megabyte value using the BIP100 pattern

/BIP100/B[0-9]+/

Example: /BIP100/B8/ is a vote for a 8000000-byte hardLimit.

+### If the block height is encoded at the start of the coinbase scriptSig, as per BIP34, it is ignored. +### Only the first BIP100 pattern match is processed in "Maximum block size recalculation" below. +### A valid megabyte value is represented by consecutive base-ten digits. +### If no BIP100 pattern is matched, the first matching emergent consensus pattern /EB[0-9]+/, if any, is accepted as the megabyte vote.

+## Maximum block size recalculation +### A new hardLimit is calculated after each difficulty adjustment period of 2016 blocks, and applies to the next 2016 blocks. +### Absent/invalid votes are counted as votes for the current hardLimit. +### The votes of the previous 2016 blocks are sorted by megabyte vote. +### Raising hardLimit

+#### The raise value is defined as the vote of the 1512th highest block, converted to bytes. +#### If the resultant raise value is greater than (current hardLimit * 1.05) rounded down to the nearest byte, it is set to that value. +#### If the resultant raise value is greater than current hardLimit, the raise value becomes the new hardLimit and the recalculation is complete.

+### Lowering hardlimit

+#### The lower value is defined as the vote of the 1512th lowest block, converted to bytes. +#### If the resultant lower value is less than (current hardLimit / 1.05) rounded down to the nearest byte, it is set to that value. +#### If the resultant lower value is less than current hardLimit, the lower value becomes the new hardLimit and the recalculation is complete.

+### Otherwise, new hardLimit remains the same as current hardLimit. + +===Signature Hashing Operations Limits=== +# The per-block signature hashing operations limit is scaled to (hardLimit rounded up to nearest megabyte)/50. +# A maximum serialized transaction size of 1000000 bytes is imposed. + +===Publication of hardLimit=== +# For the benefit of emergent consensus nodes, hardLimit is published. Example: a complete coinbase string might read

/BIP100/B8/EB2.123456/

which indicates a vote for 8M maximum block size, and an enforced hardLimit of 2.123456 megabytes for the block containing the coinbase string. + +==Deployment== + +This BIP is presumed deployed and activated as of block height 449568 by implementing nodes on the bitcoin mainnet. It has no effect until a raise value different from 1M is observed, which requires at least 1512 of 2016 blocks to vote differently from 1M. + +==Backward compatibility== + +The first block larger than 1M will create a network partition, as nodes with a fixed 1M hard limit reject that block. + -- cgit v1.2.3 From ac9c8b73ed7ee7d5b2055bf926b1da5e76025c49 Mon Sep 17 00:00:00 2001 From: Tom Harding Date: Thu, 4 May 2017 18:47:32 -0400 Subject: bip100: Improve header metadata. Vote search edge cases. jgarzik/bip100.git commits: b82d840733b09104fca3f8805ffa6f2459193201 4ed2a0e4523b06d97e32259e6e180734a794e24f --- bip-0100.mediawiki | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'bip-0100.mediawiki') diff --git a/bip-0100.mediawiki b/bip-0100.mediawiki index 67c2b4c..fdb62a4 100644 --- a/bip-0100.mediawiki +++ b/bip-0100.mediawiki @@ -1,5 +1,6 @@ 
   BIP: 100
+  Layer: Consensus (hard fork)
   Title: Dynamic maximum block size by miner vote
   Author: Jeff Garzik 
           Tom Harding 
@@ -8,8 +9,6 @@
   Type: Standards Track
   Created: 2015-06-11
   License: BSD-2-Clause
-  Comments-Summary: No comments yet.
-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100
==Abstract== @@ -30,14 +29,14 @@ The system is compatible with emergent consensus, but whereas under that system # Initial value of hardLimit is 1000000 bytes, preserving current system. # Changing hardLimit is accomplished by encoding a proposed value, a vote, within a block's coinbase scriptSig, and by processing the votes contained in the previous retargeting period.

## Vote encoding -### A vote is represented as a positive megabyte value using the BIP100 pattern

/BIP100/B[0-9]+/

Example: /BIP100/B8/ is a vote for a 8000000-byte hardLimit.

+### A vote is represented as a megabyte value using the BIP100 pattern

/BIP100/B[0-9]+/

Example: /BIP100/B8/ is a vote for a 8000000-byte hardLimit.

### If the block height is encoded at the start of the coinbase scriptSig, as per BIP34, it is ignored. ### Only the first BIP100 pattern match is processed in "Maximum block size recalculation" below. -### A valid megabyte value is represented by consecutive base-ten digits. +### A megabyte value is represented by consecutive base-ten digits. ### If no BIP100 pattern is matched, the first matching emergent consensus pattern /EB[0-9]+/, if any, is accepted as the megabyte vote.

## Maximum block size recalculation ### A new hardLimit is calculated after each difficulty adjustment period of 2016 blocks, and applies to the next 2016 blocks. -### Absent/invalid votes are counted as votes for the current hardLimit. +### Absent/zero-valued votes are counted as votes for the current hardLimit. ### The votes of the previous 2016 blocks are sorted by megabyte vote. ### Raising hardLimit

#### The raise value is defined as the vote of the 1512th highest block, converted to bytes. @@ -50,7 +49,7 @@ The system is compatible with emergent consensus, but whereas under that system ### Otherwise, new hardLimit remains the same as current hardLimit. ===Signature Hashing Operations Limits=== -# The per-block signature hashing operations limit is scaled to (hardLimit rounded up to nearest megabyte)/50. +# The per-block signature hashing operations limit is scaled to (actual block size rounded up to nearest megabyte)/50. # A maximum serialized transaction size of 1000000 bytes is imposed. ===Publication of hardLimit=== @@ -64,3 +63,9 @@ This BIP is presumed deployed and activated as of block height 449568 by impleme The first block larger than 1M will create a network partition, as nodes with a fixed 1M hard limit reject that block. +==Reference Implementation== +https://github.com/bitcoinxt/bitcoinxt/pull/188 + +==Copyright== +This document is licensed under the BSD 2-clause license. + -- cgit v1.2.3 From 7ea5bfccde202b523738a26278afc746fdbf5aa4 Mon Sep 17 00:00:00 2001 From: Tom Harding Date: Fri, 5 May 2017 07:41:57 -0400 Subject: bip100: restore Comments header --- bip-0100.mediawiki | 1 + 1 file changed, 1 insertion(+) (limited to 'bip-0100.mediawiki') diff --git a/bip-0100.mediawiki b/bip-0100.mediawiki index fdb62a4..ceb24ad 100644 --- a/bip-0100.mediawiki +++ b/bip-0100.mediawiki @@ -5,6 +5,7 @@ Author: Jeff Garzik Tom Harding Dagur Valberg Johannsson + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100 Status: Draft Type: Standards Track Created: 2015-06-11 -- cgit v1.2.3 From 7c23bf14ee14beb8339b26914475cb50c95465e8 Mon Sep 17 00:00:00 2001 From: Tom Harding Date: Sat, 6 May 2017 12:29:54 -0400 Subject: bip100: Clarifications --- bip-0100.mediawiki | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) (limited to 'bip-0100.mediawiki') diff --git a/bip-0100.mediawiki b/bip-0100.mediawiki index ceb24ad..6b322d0 100644 --- a/bip-0100.mediawiki +++ b/bip-0100.mediawiki @@ -5,6 +5,7 @@ Author: Jeff Garzik Tom Harding Dagur Valberg Johannsson + Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100 Status: Draft Type: Standards Track @@ -41,20 +42,22 @@ The system is compatible with emergent consensus, but whereas under that system ### The votes of the previous 2016 blocks are sorted by megabyte vote. ### Raising hardLimit

#### The raise value is defined as the vote of the 1512th highest block, converted to bytes. -#### If the resultant raise value is greater than (current hardLimit * 1.05) rounded down to the nearest byte, it is set to that value. +#### If the resultant raise value is greater than (current hardLimit * 1.05) rounded down, it is set to that value. #### If the resultant raise value is greater than current hardLimit, the raise value becomes the new hardLimit and the recalculation is complete.

-### Lowering hardlimit

+### Lowering hardLimit

#### The lower value is defined as the vote of the 1512th lowest block, converted to bytes. -#### If the resultant lower value is less than (current hardLimit / 1.05) rounded down to the nearest byte, it is set to that value. +#### If the resultant lower value is less than (current hardLimit / 1.05) rounded down, it is set to that value. #### If the resultant lower value is less than current hardLimit, the lower value becomes the new hardLimit and the recalculation is complete.

### Otherwise, new hardLimit remains the same as current hardLimit. ===Signature Hashing Operations Limits=== -# The per-block signature hashing operations limit is scaled to (actual block size rounded up to nearest megabyte)/50. +# The per-block signature hashing operations limit is scaled to (actual block size, fractional megabyte rounded to next higher megabyte) / 50. # A maximum serialized transaction size of 1000000 bytes is imposed. +==Recommendations== + ===Publication of hardLimit=== -# For the benefit of emergent consensus nodes, hardLimit is published. Example: a complete coinbase string might read

/BIP100/B8/EB2.123456/

which indicates a vote for 8M maximum block size, and an enforced hardLimit of 2.123456 megabytes for the block containing the coinbase string. +# For the benefit of all observers, it is recommended that hardLimit be published. Example: a complete coinbase string might read

/BIP100/B8/EB2.123456/

which indicates a vote for 8M maximum block size, and an enforced hardLimit of 2.123456 megabytes for the block containing the coinbase string. ==Deployment== @@ -64,8 +67,10 @@ This BIP is presumed deployed and activated as of block height 449568 by impleme The first block larger than 1M will create a network partition, as nodes with a fixed 1M hard limit reject that block. -==Reference Implementation== -https://github.com/bitcoinxt/bitcoinxt/pull/188 +==Implementations== +https://github.com/bitcoinxt/bitcoinxt/pull/188
+https://github.com/bitcoinxt/bitcoin/pull/1
+https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/398
==Copyright== This document is licensed under the BSD 2-clause license. -- cgit v1.2.3 From b1b248fc6ade930c4c716eb9fed1b48be6796356 Mon Sep 17 00:00:00 2001 From: Luke Dashjr Date: Tue, 24 Sep 2019 19:33:03 +0000 Subject: Update BIP 100 status Draft->Rejected --- bip-0100.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'bip-0100.mediawiki') diff --git a/bip-0100.mediawiki b/bip-0100.mediawiki index 6b322d0..aaf6beb 100644 --- a/bip-0100.mediawiki +++ b/bip-0100.mediawiki @@ -7,7 +7,7 @@ Dagur Valberg Johannsson Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0100 - Status: Draft + Status: Rejected Type: Standards Track Created: 2015-06-11 License: BSD-2-Clause -- cgit v1.2.3