Fixes

- Spelling mistakes
- Change in the deployment model
- Corrected my acknowledgement to Austin 'Williams'

1 files changed, 8 insertions, 8 deletions

diff --git a/bip-0107.mediawiki b/bip-0107.mediawiki
index 88a2c99..4e96173 100644
--- a/bip-0107.mediawiki
+++ b/bip-0107.mediawiki
@@ -16,11 +16,11 @@ This BIP proposes a dynamic limit to the block size based on transaction volume.
 Over the next few years, large infrastructure investments will be made into:
 
 # Improving global network connectivity
-# Improving block propogation across the Bitcoin network
+# Improving block propagation across the Bitcoin network
 # 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 agument 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.
 
@@ -44,7 +44,7 @@ Over the next few years, large infrastructure investments will be made into:
 ** <code>limitfreerelay</code> also helps counter attempts to trigger a block size increase by 'penny-flooding'
 
 For example:
-* When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size wil be 6 MB
+* 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. 
 
@@ -59,7 +59,7 @@ 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 distrance 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:
@@ -67,16 +67,16 @@ For example:
 ***# 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 opportunitites to increase the block size per year
+*** 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 
 
 ==Deployment==
-''From BIP66:''
-We reuse the double-threshold switchover mechanism from BIP 34, with the same thresholds, but for nVersion = ''n''. The new rules are in effect for every block (at height H) with nVersion = ''n'' and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = ''n''. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = ''n'', nVersion = ''n-1'' blocks become invalid, and all further blocks enforce the new rules.
+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==
 
-Thanks to Austin Hill, Brian Hoffman, Angel Leon, Bulukani Mlalazi, Chris Pacia, and Ryan Shea for their comments.
+Thanks to Austin Williams, Brian Hoffman, Angel Leon, Bulukani Mlalazi, Chris Pacia, and Ryan Shea for their comments.
 
 ==Copyright==