chore: ignore links that fail markdown-link-check

docs/architecture/adr-012-sequence-length-encoding.md

@@ -46,7 +46,9 @@ Inefficient space usage. Unlike compact share sequences which are bounded (i.e.
   - 8 bytes is capable of storing a uint64. A uint64 can contain a max sequence length of 18,446,744,073,709,551,615 bytes so pebibyte scale.
 - If we choose this option, we should decide on big endian vs. little endian? Proposal: big endian because it seems more user friendly and more common on the network
   - Integers in Fuel are big endian. See <https://fuellabs.github.io/fuel-specs/master/vm/index.html?highlight=endian#semantics>.
+  <!-- markdown-link-check-disable -->
   - Bitcoin is little endian. Ref: <https://learnmeabitcoin.com/technical/little-endian>.
+  <!-- markdown-link-check-enable -->
   - Ethereum uints are little endian. Ref: <https://jeancvllr.medium.com/solidity-tutorial-all-about-bytes-9d88fdb22676>
 
 Pros

docs/architecture/adr-015-namespace-id-size.md

@@ -232,7 +232,9 @@ Note: to verify the number of SHA256 compression invocations, we analyzed the nu
 [^2]: <https://eager.io/blog/how-long-does-an-id-need-to-be/>
 [^3]: <https://kevingal.com/apps/collision.html>
 [^4]: <https://www.johndcook.com/blog/2017/01/10/probability-of-secure-hash-collisions/>
+<!-- markdown-link-check-disable -->
 [^5]: <https://ycharts.com/indicators/ethereum_cumulative_unique_addresses>
+<!-- markdown-link-check-enable -->
 [^6]: <https://docs.google.com/spreadsheets/d/1vrRM4gAsmC142KrdUI1aCBS5IVFdJeU0q6gwwnM3Ekc/edit?usp=sharing>
 [^7]: <https://www.wolframalpha.com/input?i=4.05871E%2B15+%2F+2%5E160>
 [^8]: <https://www.wolframalpha.com/input?i=4.05871E%2B15+%2F+2%5E64>

specs/src/specs/public_key_cryptography.md

@@ -22,7 +22,9 @@ Cosmos [addresses](https://github.com/cosmos/cosmos-sdk/blob/v0.46.15/docs/basic
 
 ### Signatures
 
+<!-- markdown-link-check-disable -->
 Deterministic signatures ([RFC-6979](https://tools.ietf.org/rfc/rfc6979.txt)) should be used when signing, but this is not enforced at the protocol level as it cannot be for Secp256k1 signatures.
+<!-- markdown-link-check-enable -->
 
 Signatures are represented as the `r` and `s` (each 32 bytes) values of the signature. `r` and `s` take on their usual meaning (see: [SEC 1, 4.1.3 Signing Operation](https://www.secg.org/sec1-v2.pdf)). Signatures are encoded with protobuf as described [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.15/docs/core/encoding.md).