From b82d840733b09104fca3f8805ffa6f2459193201 Mon Sep 17 00:00:00 2001
From: Tom Harding <tomh@thinlink.com>
Date: Mon, 1 May 2017 10:59:01 -0700
Subject: [PATCH 1/2] Vote search edge cases

Clarify that 0-valued votes are explicit votes for current limit.
Remove "valid" wording as redundant to pattern match specificaton.
Remove "positive" qualifier for B vote search; a vote of zero
in either B or EB is distinct from garbage.
---
 bip-0100.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-0100.mediawiki b/bip-0100.mediawiki
index f9981d3..bc77bbb 100644
--- a/bip-0100.mediawiki
+++ b/bip-0100.mediawiki
@@ -27,14 +27,14 @@ The system is compatible with emergent consensus, but whereas under that system
 # 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 />
+### A vote is represented as a 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.
+### A 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>.
+### Absent/zero-valued 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.

From 4ed2a0e4523b06d97e32259e6e180734a794e24f Mon Sep 17 00:00:00 2001
From: Tom Harding <tomh@thinlink.com>
Date: Thu, 4 May 2017 11:33:23 -0700
Subject: [PATCH 2/2] Update headers, copyright, reference impl

---
 bip-0100.mediawiki | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/bip-0100.mediawiki b/bip-0100.mediawiki
index bc77bbb..fdb62a4 100644
--- a/bip-0100.mediawiki
+++ b/bip-0100.mediawiki
@@ -1,5 +1,6 @@
 <pre>
   BIP: 100
+  Layer: Consensus (hard fork)
   Title: Dynamic maximum block size by miner vote
   Author: Jeff Garzik <jgarzik@gmail.com>
           Tom Harding <tomh@thinlink.com>
@@ -7,6 +8,7 @@
   Status: Draft
   Type: Standards Track
   Created: 2015-06-11
+  License: BSD-2-Clause
 </pre>
 
 ==Abstract==
@@ -61,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.
+