bip100: Improve header metadata. Vote search edge cases.

jgarzik/bip100.git commits:
b82d840733b09104fca3f8805ffa6f2459193201
4ed2a0e4523b06d97e32259e6e180734a794e24f

1 files changed, 11 insertions, 6 deletions

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 @@
 <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>
@@ -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
 </pre>
 
 ==Abstract==
@@ -30,14 +29,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.
@@ -50,7 +49,7 @@ The system is compatible with emergent consensus, but whereas under that system
 ### 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.
+# 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 <code>hardLimit</code>===
@@ -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.
+