mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 21:35:13 +01:00
Code Issues Projects Releases Wiki Activity

Merge pull request #262 from jgarzik/bip102_updates

Browse Source 
BIP 102: update to match implementation
This commit is contained in:
Jeff Garzik 2016-01-19 15:24:22 +08:00
commit db1f646035
1 changed files with 12 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
bip-0102.mediawiki
View File

@ -13,28 +13,29 @@ Simple, one-time increase in total amount of transaction data permitted in a blo
==Motivation==
# Enable network growth.
# Continue current economic policy of low fee pressure on average.
# Exercise network upgrade procedure.
# Continue current economic policy.
# Exercise hard fork network upgrade.
==Specification==
# Maximum block size permitted to be valid is 1MB.
# Increase this maximum to 2MB as soon as 75% of the last 1,000 blocks have signaled support.
# MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.
# Increase maximum block sigops by similar factor, preserving SIZE/50 formula.
# Trigger: (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support.
==Backward compatibility==
Older clients are not compatible with this change. The first block exceeding 1,000,000 bytes will partition older clients off the new network.
Fully validating older clients are not compatible with this change.
The first block exceeding 1,000,000 bytes will partition older clients
off the new network.
==Discussion==
In the short term, an increase is needed to continue to facilitate
network growth, and buy time for more comprehensive solutions to be
developed. This continues the current economic policies with regards to
fees, matching market expectations and preventing market disruption.
In the short term, an increase is needed to continue to current
economic policies with regards to fees and block space, matching
market expectations and preventing market disruption.
In the long term, continued direct management of this limit is a moral hazard that clouds free market input and prevents a healthy fee market from developing. This area of code should be transitioned away from direct management.
In the long term, this limit should focus on reflecting the maximum
network engineering limit.
==Implementation==