markdownlint (tendermint#9834)

Co-authored-by: Sergio Mena <[email protected]>

CHANGELOG_PENDING.md

@@ -18,11 +18,11 @@
 - Blockchain Protocol
 
 - Data Storage
-  - [state] \#6541 Move pruneBlocks from consensus/state to state/execution. (@JayT106)
+    - [state] \#6541 Move pruneBlocks from consensus/state to state/execution. (@JayT106)
 
 - Tooling
-  - [tools/tm-signer-harness] \#6498 Set OS home dir to instead of the hardcoded PATH. (@JayT106)
-  - [metrics] \#9682 move state-syncing and block-syncing metrics to their respective packages (@cmwaters)
+    - [tools/tm-signer-harness] \#6498 Set OS home dir to instead of the hardcoded PATH. (@JayT106)
+    - [metrics] \#9682 move state-syncing and block-syncing metrics to their respective packages (@cmwaters)
     labels have moved from block_syncing -> blocksync_syncing and state_syncing -> statesync_syncing
   - [inspect] \#9655 Add a new `inspect` command for introspecting the state and block store of a crashed tendermint node. (@williambanfield)
 
@@ -56,24 +56,24 @@ Friendly reminder, we have a [bug bounty program](https://hackerone.com/tendermi
 ### BREAKING CHANGES
 
 - CLI/RPC/Config
-  - [config] \#9259 Rename the fastsync section and the fast_sync key blocksync and block_sync respectively
+    - [config] \#9259 Rename the fastsync section and the fast_sync key blocksync and block_sync respectively
 
 - Apps
-  - [abci/counter] \#6684 Delete counter example app
-  - [abci] \#5783 Make length delimiter encoding consistent (`uint64`) between ABCI and P2P wire-level protocols
-  - [abci] \#9145 Removes unused Response/Request `SetOption` from ABCI (@samricotta)
-  - [abci/params] \#9287 Deduplicate `ConsensusParams` and `BlockParams` so only `types` proto definitions are used (@cmwaters)
-    - Remove `TimeIotaMs` and use a hard-coded 1 millisecond value to ensure monotonically increasing block times.
-    - Rename `AppVersion` to `App` so as to not stutter.
-  - [types] \#9287 Reduce the use of protobuf types in core logic. (@cmwaters)
-    - `ConsensusParams`, `BlockParams`, `ValidatorParams`, `EvidenceParams`, `VersionParams` have become native types.
+    - [abci/counter] \#6684 Delete counter example app
+    - [abci] \#5783 Make length delimiter encoding consistent (`uint64`) between ABCI and P2P wire-level protocols
+    - [abci] \#9145 Removes unused Response/Request `SetOption` from ABCI (@samricotta)
+    - [abci/params] \#9287 Deduplicate `ConsensusParams` and `BlockParams` so only `types` proto definitions are used (@cmwaters)
+        - Remove `TimeIotaMs` and use a hard-coded 1 millisecond value to ensure monotonically increasing block times.
+        - Rename `AppVersion` to `App` so as to not stutter.
+    - [types] \#9287 Reduce the use of protobuf types in core logic. (@cmwaters)
+        - `ConsensusParams`, `BlockParams`, `ValidatorParams`, `EvidenceParams`, `VersionParams` have become native types.
       They still utilize protobuf when being sent over the wire or written to disk.
-    - Moved `ValidateConsensusParams` inside (now native type) `ConsensusParams`, and renamed it to `ValidateBasic`.
-  - [abci] \#9301 New ABCI methods `PrepareProposal` and `ProcessProposal` which give the app control over transactions proposed and allows for verification of proposed blocks.
-  - [abci] \#8216 Renamed `EvidenceType` to `MisbehaviorType` and `Evidence` to `Misbehavior` as a more accurate label of their contents. (@williambanfield, @sergio-mena)
-  - [abci] \#9122 Renamed `LastCommitInfo` to `CommitInfo` in preparation for vote extensions. (@cmwaters)
-  - [abci] \#8656, \#8901 Added cli commands for `PrepareProposal` and `ProcessProposal`. (@jmalicevic, @hvanz)
-  - [abci] \#6403 Change the `key` and `value` fields from `[]byte` to `string` in the `EventAttribute` type. (@alexanderbez)
+        - Moved `ValidateConsensusParams` inside (now native type) `ConsensusParams`, and renamed it to `ValidateBasic`.
+    - [abci] \#9301 New ABCI methods `PrepareProposal` and `ProcessProposal` which give the app control over transactions proposed and allows for verification of proposed blocks.
+    - [abci] \#8216 Renamed `EvidenceType` to `MisbehaviorType` and `Evidence` to `Misbehavior` as a more accurate label of their contents. (@williambanfield, @sergio-mena)
+    - [abci] \#9122 Renamed `LastCommitInfo` to `CommitInfo` in preparation for vote extensions. (@cmwaters)
+    - [abci] \#8656, \#8901 Added cli commands for `PrepareProposal` and `ProcessProposal`. (@jmalicevic, @hvanz)
+    - [abci] \#6403 Change the `key` and `value` fields from `[]byte` to `string` in the `EventAttribute` type. (@alexanderbez)
 
 - P2P Protocol
 
@@ -89,6 +89,7 @@ Friendly reminder, we have a [bug bounty program](https://hackerone.com/tendermi
 - [abci] \#9301 New ABCI methods `PrepareProposal` and `ProcessProposal` which give the app control over transactions proposed and allows for verification of proposed blocks.
 
 ### IMPROVEMENTS
+
 - [crypto] \#9250 Update to use btcec v2 and the latest btcutil. (@wcsiu)
 
 - [cli] \#9171 add `--hard` flag to rollback command (and a boolean to the `RollbackState` method). This will rollback

README.md

@@ -148,7 +148,7 @@ Currently supported versions include:
 - [Tendermint Core Blog](https://medium.com/tendermint/tagged/tendermint-core)
 - [Cosmos Blog](https://blog.cosmos.network/tendermint/home)
 
-## Join us!
+## Join us
 
 Tendermint Core is maintained by [Interchain GmbH](https://interchain.io).
 If you'd like to work full-time on Tendermint Core,

RELEASES.md

@@ -50,6 +50,7 @@ the 0.38.x line.
    in order to do this).
 
 3. Create and push the backport branch:
+
    ```sh
    git checkout -b v0.38.x
    git push origin v0.38.x
@@ -81,6 +82,7 @@ the 0.38.x line.
    * `docs.tendermint.com/main` -> `docs.tendermint.com/v0.38`
 
    Once you have updated all of the relevant documentation:
+
    ```sh
    # Create and push the PR.
    git checkout -b update-docs-v038x
@@ -113,22 +115,22 @@ create an alpha or beta version, or release candidate (RC) for our friends and
 partners to test out. We use git tags to create pre-releases, and we build them
 off of backport branches, for example:
 
-- `v0.38.0-alpha.1` - The first alpha release of `v0.38.0`. Subsequent alpha
+* `v0.38.0-alpha.1` - The first alpha release of `v0.38.0`. Subsequent alpha
   releases will be numbered `v0.38.0-alpha.2`, `v0.38.0-alpha.3`, etc.
 
   Alpha releases are to be considered the _most_ unstable of pre-releases, and
   are most likely not yet properly QA'd. These are made available to allow early
   adopters to start integrating and testing new functionality before we're done
   with QA.
 
-- `v0.38.0-beta.1` - The first beta release of `v0.38.0`. Subsequent beta
+* `v0.38.0-beta.1` - The first beta release of `v0.38.0`. Subsequent beta
   releases will be numbered `v0.38.0-beta.2`, `v0.38.0-beta.3`, etc.
 
   Beta releases can be considered more stable than alpha releases in that we
   will have QA'd them better than alpha releases, but there still may be
   minor breaking API changes if users have strong demands for such changes.
 
-- `v0.38.0-rc1` - The first release candidate (RC) of `v0.38.0`. Subsequent RCs
+* `v0.38.0-rc1` - The first release candidate (RC) of `v0.38.0`. Subsequent RCs
   will be numbered `v0.38.0-rc2`, `v0.38.0-rc3`, etc.
 
   RCs are considered more stable than beta releases in that we will have
@@ -146,18 +148,18 @@ backport branch (see above). Otherwise:
 1. Start from the backport branch (e.g. `v0.38.x`).
 2. Run the integration tests and the E2E nightlies
    (which can be triggered from the GitHub UI;
-   e.g., https://github.com/tendermint/tendermint/actions/workflows/e2e-nightly-37x.yml).
+   e.g., <https://github.com/tendermint/tendermint/actions/workflows/e2e-nightly-37x.yml>).
 3. Prepare the pre-release documentation:
-   - Ensure that all relevant changes are in the `CHANGELOG_PENDING.md` file.
+   * Ensure that all relevant changes are in the `CHANGELOG_PENDING.md` file.
      This file's contents must only be included in the `CHANGELOG.md` when we
      cut final releases.
-   - Ensure that `UPGRADING.md` is up-to-date and includes notes on any breaking changes
+   * Ensure that `UPGRADING.md` is up-to-date and includes notes on any breaking changes
       or other upgrading flows.
 4. Prepare the versioning:
-   - Bump TMVersionDefault version in  `version.go`
-   - Bump P2P and block protocol versions in  `version.go`, if necessary.
+   * Bump TMVersionDefault version in  `version.go`
+   * Bump P2P and block protocol versions in  `version.go`, if necessary.
      Check the changelog for breaking changes in these components.
-   - Bump ABCI protocol version in `version.go`, if necessary
+   * Bump ABCI protocol version in `version.go`, if necessary
 5. Open a PR with these changes against the backport branch.
 6. Once these changes have landed on the backport branch, be sure to pull them back down locally.
 7. Once you have the changes locally, create the new tag, specifying a name and a tag "message":
@@ -179,33 +181,33 @@ Before performing these steps, be sure the
 1. Start on the backport branch (e.g. `v0.38.x`)
 2. Run integration tests (`make test_integrations`) and the e2e nightlies.
 3. Prepare the release:
-   - "Squash" changes from the changelog entries for the pre-releases into a
+   * "Squash" changes from the changelog entries for the pre-releases into a
      single entry, and add all changes included in `CHANGELOG_PENDING.md`.
      (Squashing includes both combining all entries, as well as removing or
      simplifying any intra-pre-release changes. It may also help to alphabetize
      the entries by package name.)
-   - Run `python ./scripts/linkify_changelog.py CHANGELOG.md` to add links for
+   * Run `python ./scripts/linkify_changelog.py CHANGELOG.md` to add links for
      all PRs
-   - Ensure that `UPGRADING.md` is up-to-date and includes notes on any breaking changes
+   * Ensure that `UPGRADING.md` is up-to-date and includes notes on any breaking changes
       or other upgrading flows.
-   - Bump TMVersionDefault version in  `version.go`
-   - Bump P2P and block protocol versions in  `version.go`, if necessary
-   - Bump ABCI protocol version in `version.go`, if necessary
+   * Bump TMVersionDefault version in  `version.go`
+   * Bump P2P and block protocol versions in  `version.go`, if necessary
+   * Bump ABCI protocol version in `version.go`, if necessary
 4. Open a PR with these changes against the backport branch.
 5. Once these changes are on the backport branch, push a tag with prepared release details.
    This will trigger the actual release `v0.38.0`.
-   - `git tag -a v0.38.0 -m 'Release v0.38.0'`
-   - `git push origin v0.38.0`
+   * `git tag -a v0.38.0 -m 'Release v0.38.0'`
+   * `git push origin v0.38.0`
 6. Make sure that `main` is updated with the latest `CHANGELOG.md`, `CHANGELOG_PENDING.md`, and `UPGRADING.md`.
 7. Add the release to the documentation site generator config (see
    [DOCS\_README.md](./docs/DOCS_README.md) for more details). In summary:
-   - Start on branch `main`.
-   - Add a new line at the bottom of [`docs/versions`](./docs/versions) to
+   * Start on branch `main`.
+   * Add a new line at the bottom of [`docs/versions`](./docs/versions) to
      ensure the newest release is the default for the landing page.
-   - Add a new entry to `themeConfig.versions` in
+   * Add a new entry to `themeConfig.versions` in
      [`docs/.vuepress/config.js`](./docs/.vuepress/config.js) to include the
 	 release in the dropdown versions menu.
-   - Commit these changes to `main` and backport them into the backport
+   * Commit these changes to `main` and backport them into the backport
      branch for this release.
 
 ## Patch release
@@ -222,21 +224,21 @@ To create a patch release:
 1. Checkout the long-lived backport branch: `git checkout v0.38.x`
 2. Run integration tests (`make test_integrations`) and the nightlies.
 3. Check out a new branch and prepare the release:
-   - Copy `CHANGELOG_PENDING.md` to top of `CHANGELOG.md`
-   - Run `python ./scripts/linkify_changelog.py CHANGELOG.md` to add links for all issues
-   - Run `bash ./scripts/authors.sh` to get a list of authors since the latest release, and add the GitHub aliases of external contributors to the top of the CHANGELOG. To lookup an alias from an email, try `bash ./scripts/authors.sh <email>`
-   - Reset the `CHANGELOG_PENDING.md`
-   - Bump the TMDefaultVersion in `version.go`
-   - Bump the ABCI version number, if necessary.
+   * Copy `CHANGELOG_PENDING.md` to top of `CHANGELOG.md`
+   * Run `python ./scripts/linkify_changelog.py CHANGELOG.md` to add links for all issues
+   * Run `bash ./scripts/authors.sh` to get a list of authors since the latest release, and add the GitHub aliases of external contributors to the top of the CHANGELOG. To lookup an alias from an email, try `bash ./scripts/authors.sh <email>`
+   * Reset the `CHANGELOG_PENDING.md`
+   * Bump the TMDefaultVersion in `version.go`
+   * Bump the ABCI version number, if necessary.
      (Note that ABCI follows semver, and that ABCI versions are the only versions
      which can change during patch releases, and only field additions are valid patch changes.)
 4. Open a PR with these changes that will land them back on `v0.38.x`
 5. Once this change has landed on the backport branch, make sure to pull it locally, then push a tag.
-   - `git tag -a v0.38.1 -m 'Release v0.38.1'`
-   - `git push origin v0.38.1`
+   * `git tag -a v0.38.1 -m 'Release v0.38.1'`
+   * `git push origin v0.38.1`
 6. Create a pull request back to main with the CHANGELOG & version changes from the latest release.
-   - Remove all `R:patch` labels from the pull requests that were included in the release.
-   - Do not merge the backport branch into main.
+   * Remove all `R:patch` labels from the pull requests that were included in the release.
+   * Do not merge the backport branch into main.
 
 ## Minor Release Checklist
 

abci/example/kvstore/README.md

@@ -4,7 +4,7 @@ There are two app's here: the KVStoreApplication and the PersistentKVStoreApplic
 
 ## KVStoreApplication
 
-The KVStoreApplication is a simple merkle key-value store. 
+The KVStoreApplication is a simple merkle key-value store.
 Transactions of the form `key=value` are stored as key-value pairs in the tree.
 Transactions without an `=` sign set the value to the key.
 The app has no replay protection (other than what the mempool provides).
@@ -27,4 +27,4 @@ Validator set changes are effected using the following transaction format:
 
 where `pubkeyN` is a base64-encoded 32-byte ed25519 key and `powerN` is a new voting power for the validator with `pubkeyN` (possibly a new one).
 To remove a validator from the validator set, set power to `0`.
-There is no sybil protection against new validators joining. 
+There is no sybil protection against new validators joining.

consensus/README.md

@@ -1,3 +1,3 @@
-# Consensus 
+# Consensus
 
-See the [consensus spec](https://github.com/tendermint/tendermint/tree/main/spec/consensus) for more information.
+See the [consensus spec](https://github.com/tendermint/tendermint/tree/main/spec/consensus) for more information.

crypto/merkle/README.md

@@ -1,4 +1,4 @@
 # Merkle Tree
 
-For smaller static data structures that don't require immutable snapshots or mutability; 
+For smaller static data structures that don't require immutable snapshots or mutability;
 for instance the transactions and validation signatures of a block can be hashed using this simple merkle tree logic.

docs/app-dev/abci-cli.md

@@ -262,7 +262,7 @@ deployment, the role of sending messages is taken by Tendermint, which
 connects to the app using three separate connections, each with its own
 pattern of messages.
 
-For examples of running an ABCI app with Tendermint, see the 
+For examples of running an ABCI app with Tendermint, see the
 [getting started guide](./getting-started.md).
 
 ## Bounties

docs/app-dev/getting-started.md

@@ -23,7 +23,7 @@ using Tendermint.
 
 The first apps we will work with are written in Go. To install them, you
 need to [install Go](https://golang.org/doc/install), put
-`$GOPATH/bin` in your `$PATH` and enable go modules. If you use `bash`, 
+`$GOPATH/bin` in your `$PATH` and enable go modules. If you use `bash`,
 follow these instructions:
 
 ```bash

docs/app-dev/indexing-transactions.md

@@ -84,7 +84,7 @@ the `psql` indexer type.
 Example:
 
 ```shell
-$ psql ... -f state/indexer/sink/psql/schema.sql
+psql ... -f state/indexer/sink/psql/schema.sql
 ```
 
 ## Default Indexes

docs/introduction/architecture.md

@@ -39,7 +39,7 @@ When writing a p2p service, there are two primary responsibilities:
 The first responsibility is handled by the Switch:
 
 - Responsible for routing connections between peers
-- Notably _only handles TCP connections_; RPC/HTTP is separate
+- Notably *only handles TCP connections*; RPC/HTTP is separate
 - Is a dependency for every reactor; all reactors expose a function `setSwitch`
 - Holds onto channels (channels on the TCP connection--NOT Go channels) and uses them to route
 - Is a global object, with a global namespace for messages
@@ -56,7 +56,7 @@ The second responsibility is handled by a combination of the PEX and the Address
 Here are some relevant facts about TCP:
 
 1. All TCP connections have a "frame window size" which represents the packet size to the "confidence;" i.e., if you are sending packets along a new connection, you must start out with small packets. As the packets are received successfully, you can start to send larger and larger packets. (This curve is illustrated below.) This means that TCP connections are slow to spin up.
-2. The syn/ack process also means that there's a high overhead for small, frequent messages 
+2. The syn/ack process also means that there's a high overhead for small, frequent messages
 3. Sockets are represented by file descriptors.
 
 ![tcp](../imgs/tcp-window.png)
@@ -114,7 +114,7 @@ Furthermore, all reactors expose:
 
 The `receive` method can be called many times by the mconnection. It has the same signature across all reactors.
 
-The `addReactor` call does a for loop over all the channels on the reactor and creates a map of channel IDs->reactors. The switch holds onto this map, and passes it to the _transport_, a thin wrapper around TCP connections.
+The `addReactor` call does a for loop over all the channels on the reactor and creates a map of channel IDs->reactors. The switch holds onto this map, and passes it to the *transport*, a thin wrapper around TCP connections.
 
 The following is an exhaustive (?) list of reactors: