Docs: remove duplication words

abci/client/client.go

@@ -107,7 +107,7 @@ func NewReqRes(req *types.Request) *ReqRes {
 	}
 }
 
-// Sets sets the callback. If reqRes is already done, it will call the cb
+// Sets the callback. If reqRes is already done, it will call the cb
 // immediately. Note, reqRes.cb should not change if reqRes.done and only one
 // callback is supported.
 func (r *ReqRes) SetCallback(cb func(res *types.Response)) {

blockchain/v0/pool.go

@@ -35,7 +35,7 @@ const (
 	requestRetrySeconds       = 30
 
 	// Minimum recv rate to ensure we're receiving blocks from a peer fast
-	// enough. If a peer is not sending us data at at least that rate, we
+	// enough. If a peer is not sending us data at least that rate, we
 	// consider them to have timedout and we disconnect.
 	//
 	// Assuming a DSL connection (not a good choice) 128 Kbps (upload) ~ 15 KB/s,

blockchain/v1/peer.go

@@ -197,7 +197,7 @@ func BpPeerDefaultParams() *BpPeerParams {
 		timeout: 15 * time.Second,
 
 		// Minimum recv rate to ensure we're receiving blocks from a peer fast
-		// enough. If a peer is not sending data at at least that rate, we
+		// enough. If a peer is not sending data at least that rate, we
 		// consider them to have timedout and we disconnect.
 		//
 		// Assuming a DSL connection (not a good choice) 128 Kbps (upload) ~ 15 KB/s,

consensus/reactor_test.go

@@ -709,7 +709,7 @@ func timeoutWaitGroup(t *testing.T, n int, f func(int), css []*State) {
 		close(done)
 	}()
 
-	// we're running many nodes in-process, possibly in in a virtual machine,
+	// we're running many nodes in-process, possibly in a virtual machine,
 	// and spewing debug messages - making a block could take a while,
 	timeout := time.Second * 120
 

spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md

@@ -105,7 +105,7 @@ then the time `b.time` in the block `b` that is signed by `c` satisfies
 - `beginConsensus(k) - PRECISION <= b.time < endConsensus(k) + PRECISION + MSGDELAY`.
 
 
-> [PBTS-CONSENSUS-TIME-VALID.0] is based on an analysis where the proposer is faulty (and does does not count towards `beginConsensus(k)` and `endConsensus(k)`), and we estimate the times at which correct validators receive and `accept` the `propose` message. If the proposer is correct we obtain
+> [PBTS-CONSENSUS-TIME-VALID.0] is based on an analysis where the proposer is faulty (and does not count towards `beginConsensus(k)` and `endConsensus(k)`), and we estimate the times at which correct validators receive and `accept` the `propose` message. If the proposer is correct we obtain
 
 #### **[PBTS-CONSENSUS-LIVE-VALID-CORR-PROP.0]**
 

spec/light-client/accountability/README.md

@@ -231,7 +231,7 @@ Execution
 
 Consequences:
 
-* The validators in F1 will be detectable by the the fork accountability mechanisms.
+* The validators in F1 will be detectable by the fork accountability mechanisms.
 * The validators in F2 cannot be detected using this mechanism.
 Only in case they signed something which conflicts with the application this can be used against them. Otherwise they do not do anything incorrect. <!-- markdown-link-check-disable-next-line -->
 * This case is not covered by the report <https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit?usp=sharing> as it only assumes at most 2/3 of faulty validators.

spec/light-client/detection/detection_001_reviewed.md

@@ -722,7 +722,7 @@ func CreateEvidenceForPeer(peer PeerID, root LightBlock, trace LightStore)
 #### Argument for [[LCD-DIST-INV-ATTACK.1]](#LCD-DIST-INV-ATTACK1)
 
 Under the assumption that root and trace are a verification trace,
-when in `CreateEvidenceForPeer` the detector the detector creates
+when in `CreateEvidenceForPeer` the detector creates
 evidence, then the lightclient has seen two different headers (one via
 `trace` and one via `VerifyToTarget` for the same height that can both
 be verified in one step.