diff options
Diffstat (limited to 'bip-0107.mediawiki')
| -rw-r--r-- | bip-0107.mediawiki | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki index b82db61..915657a 100644 --- a/bip-0107.mediawiki +++ b/bip-0107.mediawiki @@ -24,7 +24,7 @@ Over the next few years, large infrastructure investments will be made into: # Layer 2 services and networks for off-chain transactions # General efficiency improvements to transactions and the blockchain -* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. +* While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. * In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'. * These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network. @@ -40,7 +40,7 @@ Over the next few years, large infrastructure investments will be made into: * '''Phase 2''' ** In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume ** Every 4032 blocks (~4 weeks), a CHECK will be performed to determine if a raise in the maximum block size should occur -*** This calculates to a theoretical maximum of 13 increases per year +*** This calculates to a theoretical maximum of 13 increases per year ** IF of the last >= 3025 blocks were >=60% full, the maximum block size will be increased by 10% ** The maximum block size can only ever be increased, not decreased * The default <code>limitfreerelay</code> will also be raised in proportion to maximum block size increases @@ -49,8 +49,8 @@ Over the next few years, large infrastructure investments will be made into: For example: * When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size will be 6 MB -* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. -* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. +* IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. +* The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. ==Rationale== @@ -63,19 +63,19 @@ For example: *** Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place *** Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size **** If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered -*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit. +*** Therefore, we need a ''safe distance'' away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit. ** Why 3025 blocks? *** The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1 *** Increases in the maximum block size should only occur after a sustained trend can be observed in order to: ***# Demonstrate a market-driven secular elevation in the transaction volume -***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions +***# Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions *** In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand ** Why 10% increase in the block size? *** Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunities to increase the block size per year -*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community +*** Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community ==Deployment== -Similar deployment model to BIP101: +Similar deployment model to BIP101: <blockquote>Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks.</blockquote> ==Acknowledgements== |