BIP 8: Fix misspellings

1 files changed, 3 insertions, 3 deletions

diff --git a/bip-0008.mediawiki b/bip-0008.mediawiki
index 2ac8b0d..4d7c85f 100644
--- a/bip-0008.mediawiki
+++ b/bip-0008.mediawiki
@@ -24,7 +24,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and result in veto by a small minority of non-signalling hashrate. Super majority hashrate based activation triggers allow for accelerated activation where the majority hash power enforces the new rules in lieu of full nodes upgrading. Since all consensus rules are ultimately enforced by full nodes, eventually any new soft fork will be enforced by the economy. This proposal combines these two aspects to provide eventual flag day activation after a reasonable time (recommended a year), as well as for accelerated activation by majority of hash rate before the flag date.
 
-Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of siginificant hashrate could interfere with a late activation.
+Due to using timestamps rather than block heights, it was found to be a risk that a sudden loss of significant hashrate could interfere with a late activation.
 
 Block time is somewhat unreliable and may be intentionally or unintentionally inaccurate, so thresholds based on block time are not ideal. Secondly, BIP9 specified triggers based on the first retarget after a given time, which is non-intuitive. Since each new block must increase the height by one, thresholds based on block height are much more reliable and intuitive and can be calculated exactly for difficulty retarget.
 
@@ -48,7 +48,7 @@ The following guidelines are suggested for selecting these parameters for a soft
 # '''bit''' should be selected such that no two concurrent softforks use the same bit.
 # '''startheight''' should be set to some block height in the future, approximately 30 days (or 4320 blocks) after a software release date including the soft fork.  This allows for some release delays, while preventing triggers as a result of parties running pre-release software, and ensures a reasonable number of full nodes have upgraded prior to activation. It should be rounded up to the next height which begins a retarget period for simplicity.
 # '''timeoutheight''' should be 1 year, or 52416 blocks (26 retarget intervals) after '''startheight'''.
-# '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligable percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
+# '''lockinontimeout''' should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners. (It can be set after the initial deployment, but cannot be cleared once set.)
 
 A later deployment using the same bit is possible as long as the startheight is after the previous one's
 timeoutheight or activation, but it is discouraged until necessary, and even then recommended to have a pause in between to detect buggy software.
@@ -124,7 +124,7 @@ We remain in the initial state until either we pass the start block height or th
 After a period in the STARTED state, if we're past the timeout, we switch to LOCKED_IN or FAILING. If not, we tally the bits set,
 and transition to LOCKED_IN if a sufficient number of blocks in the past period set the deployment bit in their
 version numbers. The threshold is ≥1916 blocks (95% of 2016), or ≥1512 for testnet (75% of 2016).
-The transition to FAILING takes precendence, as otherwise an ambiguity can arise.
+The transition to FAILING takes precedence, as otherwise an ambiguity can arise.
 There could be two non-overlapping deployments on the same bit, where the first one transitions to LOCKED_IN while the
 other one simultaneously transitions to STARTED, which would mean both would demand setting the bit.