Fix typos in BIPs 87/88/98 (#1716)

* typo bip-0087.mediawiki

* typos bip-0088.mediawiki

* typo bip-0098.mediawiki

bip-0087.mediawiki

@@ -105,7 +105,7 @@ Hardened derivation is used at this level.
 
 It is crucial that this level is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
 For example, before sending a new key record to a coordinator, the wallet must increment the <code>account'</code> level.
-This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and inbetween the same wallet types.
+This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and in between the same wallet types.
 
 ===Change===
 

bip-0088.mediawiki

@@ -27,7 +27,7 @@ This BIP is licensed under the 2-clause BSD license.
 
 BIP32 derivation path format is universal, and a number of schemes for derivation were proposed
 in BIP43 and other documents, such as BIPs 44,45,49,84. The flexibility of the format also allowed
-industry participants to implement custom derivation shemes that fit particular purposes,
+industry participants to implement custom derivation schemes that fit particular purposes,
 but not necessarily useful in general.
 
 Even when existing BIPs for derivation schemes are used, their usage is not uniform across
@@ -42,14 +42,14 @@ The problem is common enough to warrant the creation of a dedicated website
 ([https://walletsrecovery.org/ walletsrecovery.org]) that tracks paths used by different wallets.
 
 At the time of writing, this website has used their own format to succinctly describe multiple
-derivation paths. As far as author knows, it was the only publicitly used format to describe
+derivation paths. As far as author knows, it was the only publicly used format to describe
 path templates before introduction of this BIP. The format was not specified anywhere beside
 the main page of the website. It used <code>|</code> to denote alternative derivation indexes
 (example: <code>m/|44'|49'|84'/0'/0'</code>) or whole alternative paths (<code>m/44'/0'/0'|m/44'/1'/0'</code>).
 
 It was not declared as a template format to use for processing by software, and seems to be
 an ad-hoc format only intended for illustration. In contrast to this ad-hoc format, the format
-described in this BIP is intended for unambigouos parsing by software, and to be easily read by humans
+described in this BIP is intended for unambiguous parsing by software, and to be easily read by humans
 at the same time. Humans can visually detect the 'templated' parts of the path more easily than the use
 of <code>|</code> in the template could allow. Wider range of paths can be defined in a single template more
 succinctly and unambiguously.

bip-0098.mediawiki

@@ -63,7 +63,7 @@ Nodes with single children are not allowed.
 
 The ''double-SHA256'' cryptographic hash function takes an arbitrary-length data as input and produces a 32-byte hash by running the data through the SHA-256 hash function as specified in FIPS 180-4[3], and then running the same hash function again on the 32-byte result, as a protection against length-extension attacks.
 
-The ''fast-SHA256'' cryptographic hash function takes two 32-byte hash values, concatenates these to produce a 64-byte buffer, and applies a single run of the SHA-256 hash function with a custom 'initialization vector' (IV) and without message paddding.
+The ''fast-SHA256'' cryptographic hash function takes two 32-byte hash values, concatenates these to produce a 64-byte buffer, and applies a single run of the SHA-256 hash function with a custom 'initialization vector' (IV) and without message padding.
 The result is a 32-byte 'midstate' which is the combined hash value and the label of the inner node.
 The changed IV protects against path-length extension attacks (grinding to interpret a hash as both an inner node and a leaf).
 fast-SHA256 is only defined for two 32-byte inputs.