From 180eac0f73b7d96861f9626ebb701d9a46585a5b Mon Sep 17 00:00:00 2001
From: omahs <73983677+omahs@users.noreply.github.com>
Date: Thu, 27 Oct 2022 20:59:01 +0200
Subject: [PATCH] Fix: typos

Fix: typos

Fix: typos

Fix: typos
---
 doc/tracing.md         | 8 ++++----
 src/net_processing.cpp | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/tracing.md b/doc/tracing.md
index b6e3b9263a9..6e60901496b 100644
--- a/doc/tracing.md
+++ b/doc/tracing.md
@@ -76,7 +76,7 @@ the passed message.
 
 #### Tracepoint `net:outbound_message`
 
-Is called when a message is send to a peer over the P2P network. Passes
+Is called when a message is sent to a peer over the P2P network. Passes
 information about our peer, the connection and the message as arguments.
 
 Arguments passed:
@@ -116,7 +116,7 @@ added to and removed (spent) from the cache when we connect a new block.
 (`chainstate.CoinsTip()`). For example, the RPCs `generateblock` and
 `getblocktemplate` call `TestBlockValidity()`, which applies the UTXO set
 changes to a temporary cache. Similarly, mempool consistency checks, which are
-frequent on regtest, also apply the the UTXO set changes to a temporary cache.
+frequent on regtest, also apply the UTXO set changes to a temporary cache.
 Changes to the _main_ UTXO cache and to temporary caches trigger the tracepoints.
 We can't tell if a temporary cache or the _main_ cache was changed.
 
@@ -253,8 +253,8 @@ TRACE6(net, inbound_message,
 
 ### Guidelines and best practices
 
-#### Clear motivation and use-case
-Tracepoints need a clear motivation and use-case. The motivation should
+#### Clear motivation and use case
+Tracepoints need a clear motivation and use case. The motivation should
 outweigh the impact on, for example, code readability. There is no point in
 adding tracepoints that don't end up being used.
 
diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index 363f2fde717..e2d70fc2c82 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -2714,7 +2714,7 @@ void PeerManagerImpl::UpdatePeerStateForReceivedHeaders(CNode& pfrom,
             // This peer has too little work on their headers chain to help
             // us sync -- disconnect if it is an outbound disconnection
             // candidate.
-            // Note: We compare their tip to the minumum chain work (rather than
+            // Note: We compare their tip to the minimum chain work (rather than
             // m_chainman.ActiveChain().Tip()) because we won't start block download
             // until we have a headers chain that has at least
             // the minimum chain work, even if a peer has a chain past our tip,
@@ -3901,7 +3901,7 @@ void PeerManagerImpl::ProcessMessage(CNode& pfrom, const std::string& msg_type,
         // Note that if we were to be on a chain that forks from the checkpointed
         // chain, then serving those headers to a peer that has seen the
         // checkpointed chain would cause that peer to disconnect us. Requiring
-        // that our chainwork exceed the mimimum chain work is a protection against
+        // that our chainwork exceed the minimum chain work is a protection against
         // being fed a bogus chain when we started up for the first time and
         // getting partitioned off the honest network for serving that chain to
         // others.