Fix broken links after apply of MD034

cosmos · mergify · Feb 10, 2022 · Feb 2, 2022 · Feb 3, 2022 · Feb 3, 2022
commit 6bd37936ca7a9fd26fba6339769888de5f2c94ac
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -3089,7 +3089,7 @@ BUG FIXES
     * [docs] Fixed light client section links
 
 * SDK
-    * [\#1988](https://github.com/cosmos/cosmos-sdk/issues/1988) Make us compile on OpenBSD (disable ledger) [#1988] (<https://github.com/cosmos/cosmos-sdk/issues/1988)>
+    * [\#1988](https://github.com/cosmos/cosmos-sdk/issues/1988) Make us compile on OpenBSD (disable ledger) [#1988] (<https://github.com/cosmos/cosmos-sdk/issues/1988>)
     * [\#2105](https://github.com/cosmos/cosmos-sdk/issues/2105) Fix DB Iterator leak, which may leak a go routine.
     * [ledger] [\#2064](https://github.com/cosmos/cosmos-sdk/issues/2064) Fix inability to sign and send transactions via the LCD by
     loading a Ledger device at runtime.

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -207,7 +207,7 @@ For example, in vscode your `.vscode/settings.json` should look like:
 
 ## Branching Model and Release
 
-User-facing repos should adhere to the trunk based development branching model: <https://trunkbaseddevelopment.com/.> User branches should start with a user name, example: `{moniker}/{issue#}-branch-name`.
+User-facing repos should adhere to the trunk based development branching model: <https://trunkbaseddevelopment.com/>. User branches should start with a user name, example: `{moniker}/{issue#}-branch-name`.
 
 The Cosmos SDK repository is a [multi Go module](https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository) repository. It means that we have more than one Go module in a single repository.
 

diff --git a/docs/DOCS_README.md b/docs/DOCS_README.md
@@ -84,7 +84,7 @@ Install the theme and all dependencies.
 npm run serve
 ```
 
-Run `pre` and `post` hooks and start a hot-reloading web-server. See output of this command for the URL (it is often <https://localhost:8080).>
+Run `pre` and `post` hooks and start a hot-reloading web-server. See output of this command for the URL (it is often <https://localhost:8080>).
 
 To build documentation as a static website run `npm run build`. You will find the website in `.vuepress/dist` directory.
 

diff --git a/docs/architecture/adr-002-docs-structure.md b/docs/architecture/adr-002-docs-structure.md
@@ -70,7 +70,7 @@ Accepted
 - Developers only have to update `/docs` folder when they open a PR (and not `/examples` for example).
 - Easier for developers to find what they need to update in the docs thanks to reworked architecture.
 - Cleaner vuepress build for website docs.
-- Will help build an executable doc (cf <https://github.com/cosmos/cosmos-sdk/issues/2611)>
+- Will help build an executable doc (cf <https://github.com/cosmos/cosmos-sdk/issues/2611>)
 
 ### Neutral
 

diff --git a/docs/architecture/adr-016-validator-consensus-key-rotation.md b/docs/architecture/adr-016-validator-consensus-key-rotation.md
@@ -7,7 +7,7 @@
 
 ## Context
 
-Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. <https://github.com/tendermint/tendermint/issues/1136).> So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos SDK.
+Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. <https://github.com/tendermint/tendermint/issues/1136>). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos SDK.
 
 We don't need to make any update on consensus logic in Tendermint because Tendermint does not have any mapping information of consensus key and validator operator key, meaning that from Tendermint point of view, a consensus key rotation of a validator is simply a replacement of a consensus key to another.
 
@@ -109,7 +109,7 @@ Proposed
 ### Positive
 
 - Validators can immediately or periodically rotate their consensus key to have better security policy
-- improved security against Long-Range attacks (<https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule)> given a validator throws away the old consensus key(s)
+- improved security against Long-Range attacks (<https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule>) given a validator throws away the old consensus key(s)
 
 ### Negative
 

diff --git a/docs/architecture/adr-020-protobuf-transaction-encoding.md b/docs/architecture/adr-020-protobuf-transaction-encoding.md
@@ -270,7 +270,7 @@ processors because:
   not `TxBody`)
 
 There are also scenarios where we may choose to safely ignore unknown fields
-(<https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188)> to
+(<https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188>) to
 provide graceful forwards compatibility with newer clients.
 
 We propose that field numbers with bit 11 set (for most use cases this is

diff --git a/docs/architecture/adr-028-public-key-addresses.md b/docs/architecture/adr-028-public-key-addresses.md
@@ -29,7 +29,7 @@ a security break of one account type shouldn't impact the security of other acco
 One initial proposal was extending the address length and
 adding prefixes for different types of addresses.
 
-@ethanfrey explained an alternate approach originally used in <https://github.com/iov-one/weave:>
+@ethanfrey explained an alternate approach originally used in <https://github.com/iov-one/weave>:
 
 > I spent quite a bit of time thinking about this issue while building weave... The other cosmos Sdk.
 > Basically I define a condition to be a type and format as human readable string with some binary data appended. This condition is hashed into an Address (again at 20 bytes). The use of this prefix makes it impossible to find a preimage for a given address with a different condition (eg ed25519 vs secp256k1).

diff --git a/docs/architecture/adr-039-epoched-staking.md b/docs/architecture/adr-039-epoched-staking.md
@@ -44,7 +44,7 @@ There is a design consideration for whether to apply a slash immediately or at t
 Applying it immediately can be viewed as offering greater consensus layer security, at potential costs to the aforementioned usecases. The benefits of immediate slashing for consensus layer security can be all be obtained by executing the validator jailing immediately (thus removing it from the validator set), and delaying the actual slash change to the validator's weight until the epoch boundary. For the use cases mentioned above, workarounds can be integrated to avoid problems, as follows:
 
 - For threshold based cryptography, this setting will have the threshold cryptography use the original epoch weights, while consensus has an update that lets it more rapidly benefit from additional security. If the threshold based cryptography blocks liveness of the chain, then we have effectively raised the liveness threshold of the remaining validators for the rest of the epoch. (Alternatively, jailed nodes could still contribute shares) This plan will fail in the extreme case that more than 1/3rd of the validators have been jailed within a single epoch. For such an extreme scenario, the chain already have its own custom incident response plan, and defining how to handle the threshold cryptography should be a part of that.
-- For light client efficiency, there can be a bit included in the header indicating an intra-epoch slash (ala <https://github.com/tendermint/spec/issues/199).>
+- For light client efficiency, there can be a bit included in the header indicating an intra-epoch slash (ala <https://github.com/tendermint/spec/issues/199>).
 - For fairness of deterministic leader election, applying a slash or jailing within an epoch would break the guarantee we were seeking to provide. This then re-introduces a new (but significantly simpler) problem for trying to provide fairness guarantees. Namely, that validators can adversarially elect to remove themself from the set of proposers. From a security perspective, this could potentially be handled by two different mechanisms (or prove to still be too difficult to achieve). One is making a security statement acknowledging the ability for an adversary to force an ahead-of-time fixed threshold of users to drop out of the proposer set within an epoch. The second method would be to  parameterize such that the cost of a slash within the epoch far outweights benefits due to being a proposer. However, this latter criterion is quite dubious, since being a proposer can have many advantageous side-effects in chains with complex state machines. (Namely, DeFi games such as Fomo3D)
 - For staking derivative design, there is no issue introduced. This does not increase the state size of staking records, since whether a slash has occured is fully queryable given the validator address.
 

diff --git a/docs/architecture/adr-042-group-module.md b/docs/architecture/adr-042-group-module.md
@@ -24,7 +24,7 @@ The legacy amino multi-signature mechanism of the Cosmos SDK has certain limitat
 While the group module is not meant to be a total replacement for the current multi-signature accounts, it provides a solution to the limitations described above, with a more flexible key management system where keys can be added, updated or removed, as well as configurable thresholds.
 It's meant to be used with other access control modules such as [`x/feegrant`](./adr-029-fee-grant-module.md) ans [`x/authz`](adr-030-authz-module.md) to simplify key management for individuals and organizations.
 
-The proof of concept of the group module can be found in <https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1> and <https://github.com/regen-network/regen-ledger/tree/master/x/group.>
+The proof of concept of the group module can be found in <https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1> and <https://github.com/regen-network/regen-ledger/tree/master/x/group>.
 
 ## Decision
 
@@ -267,8 +267,8 @@ Inter-module communication introduced by [ADR-033](adr-033-protobuf-inter-module
 
 - Convergence of `/group` and `x/gov` as both support proposals and voting: <https://github.com/cosmos/cosmos-sdk/discussions/9066>
 - `x/group` possible future improvements:
-    - Execute proposals on submission (<https://github.com/regen-network/regen-ledger/issues/288)>
-    - Withdraw a proposal (<https://github.com/regen-network/cosmos-modules/issues/41)>
+    - Execute proposals on submission (<https://github.com/regen-network/regen-ledger/issues/288>)
+    - Withdraw a proposal (<https://github.com/regen-network/cosmos-modules/issues/41>)
     - Make `Tally` more flexible and support non-binary choices
 
 ## References

diff --git a/docs/architecture/adr-043-nft-module.md b/docs/architecture/adr-043-nft-module.md
@@ -21,7 +21,7 @@ This ADR defines the `x/nft` module which is a generic implementation of NFTs, r
 
 ## Context
 
-NFTs are more than just crypto art, which is very helpful for accruing value to the Cosmos ecosystem. As a result, Cosmos Hub should implement NFT functions and enable a unified mechanism for storing and sending the ownership representative of NFTs as discussed in <https://github.com/cosmos/cosmos-sdk/discussions/9065.>
+NFTs are more than just crypto art, which is very helpful for accruing value to the Cosmos ecosystem. As a result, Cosmos Hub should implement NFT functions and enable a unified mechanism for storing and sending the ownership representative of NFTs as discussed in <https://github.com/cosmos/cosmos-sdk/discussions/9065>.
 
 As discussed in [#9065](https://github.com/cosmos/cosmos-sdk/discussions/9065), several potential solutions can be considered:
 

diff --git a/store/README.md b/store/README.md
@@ -56,7 +56,7 @@ type Store struct {
 2. Iteration efficiently returns the sorted elements within the range
 3. Each tree version is immutable and can be retrieved even after a commit(depending on the pruning settings)
 
-Specification and implementation of IAVL tree can be found in [here](https://github.com/tendermint/iavl).
+Specification and implementation of IAVL tree can be found in <https://github.com/tendermint/iavl>.
 
 ## GasKV
 

diff --git a/x/auth/spec/05_vesting.md b/x/auth/spec/05_vesting.md
@@ -8,12 +8,6 @@ order: 5
     - [Intro and Requirements](#intro-and-requirements)
     - [Note](#note)
     - [Vesting Account Types](#vesting-account-types)
-        - [BaseVestingAccount](#basevestingaccount)
-        - [ContinuousVestingAccount](#continuousvestingaccount)
-        - [DelayedVestingAccount](#delayedvestingaccount)
-        - [Period](#period)
-        - [PeriodicVestingAccount](#periodicvestingaccount)
-        - [PermanentLockedAccount](#permanentlockedaccount)
     - [Vesting Account Specification](#vesting-account-specification)
         - [Determining Vesting & Vested Amounts](#determining-vesting--vested-amounts)
             - [Continuously Vesting Accounts](#continuously-vesting-accounts)

diff --git a/x/gov/spec/01_concepts.md b/x/gov/spec/01_concepts.md
@@ -193,4 +193,4 @@ Once a block contains more than 2/3rd _precommits_ where a common
 nodes, non-validating full nodes and light-nodes) are expected to switch to the
 new version of the software.
 
-_Note: Not clear how the flip is handled programmatically_.
+_Note: Not clear how the flip is handled programmatically._