Merge bitcoin/bitcoin#26402: doc: Fix typos

180eac0 Fix: typos (omahs)

Pull request description:

  Fix: typos

ACKs for top commit:
  aureleoules:
    ACK 180eac0

Tree-SHA512: 23150f3408a2eb9cb298c6add16d1bcb149da277238786f053c2896c803f896b07555b3dc71e15cd8d390023800c8e006f931f415f887bab69ee5bd4b0420581

Author: MacroFake

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.
 

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.