Add BIP 100, as currently implemented.

1 files changed, 66 insertions, 0 deletions

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 @@
+<pre>
+  BIP: 100
+  Title: Dynamic maximum block size by miner vote
+  Author: Jeff Garzik <jgarzik@gmail.com>
+          Tom Harding <tomh@thinlink.com>
+          Dagur Valberg Johannsson <dagurval@pvv.ntnu.no>
+  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
+</pre>
+
+==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 <code>hardLimit</code> is 1000000 bytes, preserving current system.
+# Changing <code>hardLimit</code> 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.<br /><br />
+## Vote encoding
+### A vote is represented as a positive megabyte value using the BIP100 pattern<br /><br /><code>/BIP100/B[0-9]+/</code><br /><br />Example: <code>/BIP100/B8/</code> is a vote for a 8000000-byte <code>hardLimit</code>.<br /><br />
+### 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 <code>/EB[0-9]+/</code>, if any, is accepted as the megabyte vote.<br /><br />
+## Maximum block size recalculation
+### A <code>new hardLimit</code> 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 <code>current hardLimit</code>.
+### The votes of the previous 2016 blocks are sorted by megabyte vote.
+### Raising <code>hardLimit</code><br /><br />
+#### The <code>raise value</code> is defined as the vote of the 1512th highest block, converted to bytes.
+#### If the resultant <code>raise value</code> is greater than (<code>current hardLimit</code> * 1.05) rounded down to the nearest byte, it is set to that value.
+#### If the resultant <code>raise value</code> is greater than <code>current hardLimit</code>, the <code>raise value</code> becomes the <code>new hardLimit</code> and the recalculation is complete.<br /><br />
+### Lowering <code>hardlimit</code><br /><br />
+#### The <code>lower value</code> is defined as the vote of the 1512th lowest block, converted to bytes.
+#### If the resultant <code>lower value</code> is less than (<code>current hardLimit</code> / 1.05) rounded down to the nearest byte, it is set to that value.
+#### If the resultant <code>lower value</code> is less than <code>current hardLimit</code>, the <code>lower value</code> becomes the <code>new hardLimit</code> and the recalculation is complete.<br /><br />
+### Otherwise, <code>new hardLimit</code> remains the same as <code>current hardLimit</code>.
+
+===Signature Hashing Operations Limits===
+# The per-block signature hashing operations limit is scaled to (<code>hardLimit</code> rounded up to nearest megabyte)/50.
+# A maximum serialized transaction size of 1000000 bytes is imposed.
+
+===Publication of <code>hardLimit</code>===
+# For the benefit of emergent consensus nodes, <code>hardLimit</code> is published.  Example: a complete coinbase string might read <br /><br /><code>/BIP100/B8/EB2.123456/</code><br /><br /> which indicates a vote for 8M maximum block size, and an enforced <code>hardLimit</code> 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.
+