chore: lint repo (use american english) (#9144)

docs/architecture/README.md

@@ -77,7 +77,7 @@ Note the context/background should be written in the present tense.
 - [ADR-006: Trust-Metric](./adr-006-trust-metric.md)
 - [ADR-024: Sign-Bytes](./adr-024-sign-bytes.md)
 - [ADR-035: Documentation](./adr-035-documentation.md)
-- [ADR-039: Peer-Behaviour](./adr-039-peer-behaviour.md)
+- [ADR-039: Peer-Behaviour](./adr-039-peer-behavior.md)
 - [ADR-060: Go-API-Stability](./adr-060-go-api-stability.md)
 - [ADR-061: P2P-Refactor-Scope](./adr-061-p2p-refactor-scope.md)
 - [ADR-065: Custom Event Indexing](./adr-065-custom-event-indexing.md)

docs/architecture/adr-007-trust-metric-usage.md

@@ -10,8 +10,8 @@ As the node becomes well connected to the rest of the network, it can dial lesse
 quality peers and help assess their quality. Similarly, when queried for peers, a node should make
 sure they dont return low quality peers.
 
-Peer quality can be tracked using a trust metric that flags certain behaviours as good or bad. When enough
-bad behaviour accumulates, we can mark the peer as bad and disconnect.
+Peer quality can be tracked using a trust metric that flags certain behaviors as good or bad. When enough
+bad behavior accumulates, we can mark the peer as bad and disconnect.
 For example, when the PEXReactor makes a request for peers network addresses from an already known peer, and the returned network addresses are unreachable, this undesirable behavior should be tracked. Returning a few bad network addresses probably shouldn’t cause a peer to be dropped, while excessive amounts of this behavior does qualify the peer for removal. The originally proposed approach and design document for the trust metric can be found in the [ADR 006](adr-006-trust-metric.md) document.
 
 The trust metric implementation allows a developer to obtain a peer's trust metric from a trust metric store, and track good and bad events relevant to a peer's behavior, and at any time, the peer's metric can be queried for a current trust value. The current trust value is calculated with a formula that utilizes current behavior, previous behavior, and change between the two. Current behavior is calculated as the percentage of good behavior within a time interval. The time interval is short; probably set between 30 seconds and 5 minutes. On the other hand, the historic data can estimate a peer's behavior over days worth of tracking. At the end of a time interval, the current behavior becomes part of the historic data, and a new time interval begins with the good and bad counters reset to zero.
@@ -77,7 +77,7 @@ When a peer receives a pexRequestMessage, it returns a random sample of high qua
 Peer quality is tracked in the connection and across the reactors by storing the TrustMetric in the peer's
 thread safe Data store.
 
-Peer behaviour is then defined as one of the following:
+Peer behavior is then defined as one of the following:
 
 - Fatal - something outright malicious that causes us to disconnect the peer and ban it from the address book for some amount of time
 - Bad - Any kind of timeout, messages that don't unmarshal, fail other validity checks, or messages we didn't ask for or aren't expecting (usually worth one bad event)
@@ -85,7 +85,7 @@ Peer behaviour is then defined as one of the following:
 - Correct - Normal correct behavior (worth one good event)
 - Good - some random majority of peers per reactor sending us useful messages (worth more than one good event).
 
-Note that Fatal behaviour causes us to remove the peer, and neutral behaviour does not affect the score.
+Note that Fatal behavior causes us to remove the peer, and neutral behavior does not affect the score.
 
 ## Status
 

docs/architecture/adr-009-ABCI-design.md

@@ -74,7 +74,7 @@ convenient to work with address information, and for it to be simple to do so.
 ### AbsentValidators
 
 Tendermint also provides a list of validators in BeginBlock who did not sign the
-last block. This allows applications to reflect availability behaviour in the
+last block. This allows applications to reflect availability behavior in the
 application, for instance by punishing validators for not having votes included
 in commits.
 

docs/architecture/adr-016-protocol-versions.md

@@ -75,14 +75,14 @@ to connect to peers with older version.
 
 ### P2PVersion
 
-- All p2p and reactor messaging (messages, detectable behaviour)
+- All p2p and reactor messaging (messages, detectable behavior)
 - Will change gradually as reactors evolve to improve performance and support new features - eg proposed new message types BatchTx in the mempool and HasBlockPart in the consensus
 - It's easy to determine the version of a peer from its first serialized message/s
 - New versions must be compatible with at least one old version to allow gradual upgrades
 
 ### AppVersion
 
-- The ABCI state machine (txs, begin/endblock behaviour, commit hashing)
+- The ABCI state machine (txs, begin/endblock behavior, commit hashing)
 - Behaviour and message types will change abruptly in the course of the life of a chain
 - Need to minimize complexity of the code for supporting different AppVersions at different heights
 - Ideally, each version of the software supports only a _single_ AppVersion at one time

docs/architecture/adr-023-ABCI-propose-tx.md

@@ -28,14 +28,14 @@ Due to the requirements of [Minimal Viable Plasma (MVP)](https://ethresear.ch/t/
 
    `exit` transactions may also be treated in a similar manner, wherein the
    input is the UTXO being exited on the Root Chain, and the output belongs to
-   a reserved "burn" address, e.g., `0x0`. In such cases, it is favourable for
+   a reserved "burn" address, e.g., `0x0`. In such cases, it is favorable for
    the containing block to only hold a single transaction that may receive
    special treatment.
 
 2. Other "internal" transactions on the child chain, which may be initiated
    unilaterally. The most basic example of is a coinbase transaction
    implementing validator node incentives, but may also be app-specific. In
-   these cases, it may be favourable for such transactions to
+   these cases, it may be favorable for such transactions to
    be ordered in a specific manner, e.g., coinbase transactions will always be
    at index 0. In general, such strategies increase the determinism and
    predictability of blockchain applications.

docs/architecture/adr-039-peer-behaviour.md

@@ -6,20 +6,20 @@
 
 ## Context
 
-The responsibility for signaling and acting upon peer behaviour lacks a single 
+The responsibility for signaling and acting upon peer behavior lacks a single 
 owning component and is heavily coupled with the network stack[<sup>1</sup>](#references). Reactors
 maintain a reference to the `p2p.Switch` which they use to call 
 `switch.StopPeerForError(...)` when a peer misbehaves and 
 `switch.MarkAsGood(...)` when a peer contributes in some meaningful way. 
 While the switch handles `StopPeerForError` internally, the `MarkAsGood` 
 method delegates to another component, `p2p.AddrBook`. This scheme of delegation 
-across Switch obscures the responsibility for handling peer behaviour
+across Switch obscures the responsibility for handling peer behavior
 and ties up the reactors in a larger dependency graph when testing.
 
 ## Decision
 
 Introduce a `PeerBehaviour` interface and concrete implementations which
-provide methods for reactors to signal peer behaviour without direct
+provide methods for reactors to signal peer behavior without direct
 coupling `p2p.Switch`.  Introduce a ErrorBehaviourPeer to provide
 concrete reasons for stopping peers. Introduce GoodBehaviourPeer to provide
 concrete ways in which a peer contributes.
@@ -139,10 +139,10 @@ Accepted
 
 ### Positive
 
-    * De-couple signaling from acting upon peer behaviour.
+    * De-couple signaling from acting upon peer behavior.
     * Reduce the coupling of reactors and the Switch and the network
       stack
-    * The responsibility of managing peer behaviour can be migrated to
+    * The responsibility of managing peer behavior can be migrated to
       a single component instead of split between the switch and the
       address book.
 

docs/architecture/adr-042-state-sync.md

@@ -146,7 +146,7 @@ subjectivity](https://github.com/tendermint/tendermint/pull/3795)) and
 can compare any subset of keys called a chunk against the merkle root.
 The advantage of light client validation is that the block headers are
 signed by validators which have something to lose for malicious
-behaviour. If a validator were to provide an invalid proof, they can be
+behavior. If a validator were to provide an invalid proof, they can be
 slashed.
 
 Majority of peer validation: A manifest file containing a list of chunks

docs/architecture/adr-045-abci-evidence.md

@@ -22,7 +22,7 @@ main chain - so called Fork-Lite. See the
 document for more details. For a sequential lite client, this can happen via
 equivocation or amnesia attacks. For a skipping lite client this can also happen
 via lunatic validator attacks. There must be some way for applications to punish
-all forms of misbehaviour.
+all forms of misbehavior.
 
 The essential question is whether Tendermint should manage the evidence
 verification, or whether it should treat evidence more like a transaction (ie.
@@ -52,7 +52,7 @@ Arguments in favor of leaving evidence handling in Tendermint:
   currently](https://github.com/tendermint/tendermint/blob/c67154232ca8be8f5c21dff65d154127adc4f7bb/docs/spec/consensus/fork-detection.md)
   is via a centralized
   monitor service that is trusted for liveness to aggregate data from
-  current and past validators, but which produces a proof of misbehaviour (ie.
+  current and past validators, but which produces a proof of misbehavior (ie.
   via amnesia) that can be verified by anyone, including the blockchain.
   Validators must submit all the votes they saw for the relevant consensus
   height to justify their precommits. This is quite specific to the Tendermint

docs/architecture/adr-059-evidence-composition-and-lifecycle.md

@@ -189,7 +189,7 @@ After verification we persist the evidence with the key `height/hash` to the pen
 
 #### ABCI Evidence
 
-Both evidence structures contain data (such as timestamp) that are necessary to be passed to the application but do not strictly constitute evidence of misbehaviour. As such, these fields are verified last. If any of these fields are invalid to a node i.e. they don't correspond with their state, nodes will reconstruct a new evidence struct from the existing fields and repopulate the abci specific fields with their own state data.
+Both evidence structures contain data (such as timestamp) that are necessary to be passed to the application but do not strictly constitute evidence of misbehavior. As such, these fields are verified last. If any of these fields are invalid to a node i.e. they don't correspond with their state, nodes will reconstruct a new evidence struct from the existing fields and repopulate the abci specific fields with their own state data.
 
 #### Broadcasting and receiving evidence
 

docs/architecture/adr-075-rpc-subscription.md

@@ -48,7 +48,7 @@ to the node.  Unlike the other methods of the service, for which each call is
 serviced by a short-lived HTTP round trip, subscription delivers a continuous
 stream of events to the client by hijacking the HTTP channel for a websocket.
 The stream (and hence the HTTP request) persists until either the subscription
-is explicitly cancelled, or the connection is closed.
+is explicitly canceled, or the connection is closed.
 
 There are several problems with this API:
 

docs/introduction/what-is-tendermint.md

@@ -67,7 +67,7 @@ configuration, service discovery, locking, leader-election, and so on.
 Tendermint is in essence similar software, but with two key differences:
 
 - It is Byzantine Fault Tolerant, meaning it can only tolerate up to a
-  1/3 of failures, but those failures can include arbitrary behaviour -
+  1/3 of failures, but those failures can include arbitrary behavior -
   including hacking and malicious attacks. - It does not specify a
   particular application, like a fancy key-value store. Instead, it
   focuses on arbitrary state machine replication, so developers can build
@@ -101,13 +101,13 @@ Another example of a cryptocurrency application built on Tendermint is
 
 [Fabric](https://github.com/hyperledger/fabric) takes a similar approach
 to Tendermint, but is more opinionated about how the state is managed,
-and requires that all application behaviour runs in potentially many
+and requires that all application behavior runs in potentially many
 docker containers, modules it calls "chaincode". It uses an
 implementation of [PBFT](http://pmg.csail.mit.edu/papers/osdi99.pdf).
 from a team at IBM that is [augmented to handle potentially
 non-deterministic
 chaincode](https://www.zurich.ibm.com/~cca/papers/sieve.pdf) It is
-possible to implement this docker-based behaviour as a ABCI app in
+possible to implement this docker-based behavior as a ABCI app in
 Tendermint, though extending Tendermint to handle non-determinism
 remains for future work.
 

docs/tendermint-core/running-in-production.md

@@ -17,7 +17,7 @@ Tendermint keeps multiple distinct databases in the `$TMROOT/data`:
 - `blockstore.db`: Keeps the entire blockchain - stores blocks,
   block commits, and block meta data, each indexed by height. Used to sync new
   peers.
-- `evidence.db`: Stores all verified evidence of misbehaviour.
+- `evidence.db`: Stores all verified evidence of misbehavior.
 - `state.db`: Stores the current blockchain state (ie. height, validators,
   consensus params). Only grows if consensus params or validators change. Also
   used to temporarily store intermediate results during block processing.