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:
parent
5ad92f06de
commit
ac9c8b73ed
1 changed files with 11 additions and 6 deletions
|
@ -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.
|
||||
|
||||
|
|
Loading…
Add table
Reference in a new issue