1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-04 11:08:05 +01:00

bip100: Improve header metadata. Vote search edge cases.

jgarzik/bip100.git commits:
b82d840733b09104fca3f8805ffa6f2459193201
4ed2a0e4523b06d97e32259e6e180734a794e24f
This commit is contained in:
Tom Harding 2017-05-04 18:47:32 -04:00 committed by Jeff Garzik
parent 5ad92f06de
commit ac9c8b73ed

View file

@ -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.