From c3e8379b611a53114544b0ed7af5307b022b8ac8 Mon Sep 17 00:00:00 2001
From: Varunram <vrg2009@ymail.com>
Date: Sat, 14 Apr 2018 11:16:32 +0530
Subject: [trivial] Correct typos across bips

BIPs 11, 16, 61, 98, 116, 117, 143, 157
---
 bip-0098.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

(limited to 'bip-0098.mediawiki')

diff --git a/bip-0098.mediawiki b/bip-0098.mediawiki
index 118a8e2..8540d1a 100644
--- a/bip-0098.mediawiki
+++ b/bip-0098.mediawiki
@@ -57,8 +57,8 @@ The following image depicts an example unbalanced hash-tree:
 
 '''A''', '''B''', and '''C''' are leaf labels, 32-byte double-SHA256 hashes of the data associated with the leaf.
 '''Node''' and '''Root''' are inner nodes, whose labels are fast-SHA256 (defined below) hashes of their respective children's labels.
-'''Node''' is labelled with the fast-SHA256 hash of the concatination of '''B''' and '''C'''.
-'''Root''' is labelled with the fast-SHA256 hash of the concatination of '''A''' and '''Node''', and is the ''Merkle root'' of the tree.
+'''Node''' is labelled with the fast-SHA256 hash of the concatenation of '''B''' and '''C'''.
+'''Root''' is labelled with the fast-SHA256 hash of the concatenation of '''A''' and '''Node''', and is the ''Merkle root'' of the tree.
 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.
@@ -96,7 +96,7 @@ The application of fast-SHA256 to inner node label updates is safe in this limit
 so the sorts of attacks prevented by message padding and double-hashing do not apply.
 
 The 'initialization vector' for fast-SHA256 is changed in order to prevent a category of attacks on higher level protocols where a partial collision can serve as both a leaf hash and as an inner node commitment to another leaf hash.
-The IV is computed using standard SHA-256 plus midstate extraction so as to preserve compatability with cryptographic library interfaces that do not support custom IVs, at the cost of a 2x performance hit if neither custom IVs nor resuming from midstate are supported.
+The IV is computed using standard SHA-256 plus midstate extraction so as to preserve compatibility with cryptographic library interfaces that do not support custom IVs, at the cost of a 2x performance hit if neither custom IVs nor resuming from midstate are supported.
 The data hashed is a nothing-up-my-sleeve number that is unlikely to have a known hash preimage.
 The prime 23 was chosen as the leading fractional bits of the first eight (8) primes, two (2) through nineteen (19), are constants used in the setup of SHA-256 itself.
 Using the next prime in sequence reduces the likelihood of introducing weakness due to reuse of a constant factor.
-- 
cgit v1.2.3

