From 1eefea0456d661b4c51f3a40b7262d6a99161edd Mon Sep 17 00:00:00 2001
From: Alexander Cyon <alex.cyon@gmail.com>
Date: Tue, 28 May 2024 19:25:46 +0200
Subject: Fix typos on 17 files.

---
 bip-0119.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

(limited to 'bip-0119.mediawiki')

diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki
index d661f4c..be1f70c 100644
--- a/bip-0119.mediawiki
+++ b/bip-0119.mediawiki
@@ -193,7 +193,7 @@ Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial.
 The Bitcoin Core reference implementation includes the below parameters,
 configured to match Speedy Trial, as that is the current activation mechanism
 implemented in Bitcoin Core. Should another method become favored by the wider
-Bitcoin comminity, that might be used instead.
+Bitcoin community, that might be used instead.
 
 The start time and bit in the implementation are currently set to bit 5 and
 NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft.
@@ -314,7 +314,7 @@ We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decodi
 to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also
 friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that
 the max inputs in a block is further restricted by the block size to around 25,000, which would fit
-into a `uint16_t`, but that is an uneccessary abstraction leak.
+into a `uint16_t`, but that is an unnecessary abstraction leak.
 
 =====Committing to the Sequences Hash=====
 
@@ -362,7 +362,7 @@ scripts cannot be spent at the same index, which implies that they cannot be spe
 This makes it safer to design wallet vault contracts without half-spend vulnerabilities.
 
 Committing to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can
-be spent at multiple indicies. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped
+be spent at multiple indices. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped
 in an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are
 added to Bitcoin, the index may simply be passed in by the witness before hashing.
 
@@ -476,7 +476,7 @@ An example of a script that could experience an DoS issue without caching is:
 
     <H> CTV CTV CTV... CTV
 
-Such a script would cause the intepreter to compute hashes (supposing N CTV's) over O(N*T) data.
+Such a script would cause the interpreter to compute hashes (supposing N CTV's) over O(N*T) data.
 If the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N)
 times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations
 over all variable length fields in a transaction.
@@ -616,7 +616,7 @@ sponsors might be considered.
 
 An opcode which verifies the exact amount that is being spent in the
 transaction, the amount paid as fees, or made available in a given output could
-be used to make safer OP_CHECKTEMPLATEVERIFY addressses. For instance, if the
+be used to make safer OP_CHECKTEMPLATEVERIFY addresses. For instance, if the
 OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1
 satoshis would result in a frozen UTXO and sending S+n satoshis would result in
 n satoshis being paid to fee. A range check could restrict the program to only
-- 
cgit v1.2.3

