fixed broken links

dev/abft.md

@@ -74,7 +74,7 @@ _address_.
 Each player owns exactly one _participation keypair_. A participation
 keypair consists of a _public key_ $\pk$ and a _secret key_ $\sk$.
 A keypair is an opaque object which is defined in the [specification
-of participation keys in Algorand][partkey-spec].
+of participation keys in Algorand](./partkey.md).
 
 Let $m, m'$ be arbitrary sequences of bits, $B_k, \Bbar$ be 64-bit integers,
 $\tau, \taubar$ be 32-bit integers, and $Q$ be a 256-bit string.  Let
@@ -1075,6 +1075,3 @@ attempts to resynchronize.  Then,
 Finally, the player broadcasts all $\Vote(I, r, p, \Late, v) \in V$, all
 $\Vote(I, r, p, \Redo, v) \in V$, and all $\Vote(I, r, p, \Down, \bot) \in V$
 that it has observed.
-
-
-[partkey-spec]: https://github.com/algorand/spec/partkey.md

dev/crypto.md

@@ -52,14 +52,14 @@ below specifies each prefix (in quotation marks):
     - "MA": An internal node in a [Merkle tree](#merkle-tree).
     - "MB": A bottem leaf in a vector commitment [vector commitment](#vector-commitment).
     - "KP": Is a public key used by the Merkle siganture scheme [Merkle Siganture Scheme](merklesignaturescheme)
- - In the [Algorand Ledger][ledger-spec]:
+ - In the [Algorand Ledger](./ledger.md):
     - "BH": A _Block Header_.
     - "BR": A _Balance Record_.
     - "GE": A _Genesis_ configuration.
     - "STIB": A _SignedTxnInBlock_ that appears as part of the leaf in the Merkle tree of transactions.
     - "TL": A leaf in the Merkle tree of transactions.
     - "TX": A _Transaction_.
- - In the [Algorand Byzantine Fault Tolerance protocol][abft-spec]:
+ - In the [Algorand Byzantine Fault Tolerance protocol](./abft.md):
     - "AS": An _Agreement Selector_, which is also a [VRF][Verifiable
       Random Function] input.
     - "CR": A _Credential_.
@@ -94,7 +94,7 @@ for the Byzantine Fault Tolerance protocol, and (2) rerandomize its
 random seed.
 
 ### SUBSET-SUM
-Algorand uses [SUBSET-SUM algorithm][sumhash] which is a quantum-resilient hash function.
+Algorand uses [SUBSET-SUM algorithm](./cryptographic-specs/sumhash-spec.pdf) which is a quantum-resilient hash function.
 This function is used by the [Merkle Keystore](merklekeystore) to commit on
 ephemeral public keys. It is also used to create Merkle trees for the StateProofs. 
 
@@ -140,7 +140,7 @@ Algorand changes the ed25519 verification algorithm in the following way  (using
 
 ### FALCON
 
-Algorand uses a [deterministic][deterministic-falcon] version of [falcon scheme][falcon]. Falcon is quantum resilient and a SNARK friendly digital signature scheme used to sign in StateProofs. Falcon signatures contains 
+Algorand uses a [deterministic](./cryptographic-specs/falcon-deterministic.pdf) version of [falcon scheme][falcon]. Falcon is quantum resilient and a SNARK friendly digital signature scheme used to sign in StateProofs. Falcon signatures contains
 salt version. Algorand only accepts signatures with salt version = 0.
 
 The library defines the following sizes:
@@ -285,18 +285,10 @@ def verify(elems, proof, root):
 
 ## Vector commitment
 
-Algorand uses [Vector Commitments][vector-commitment], which allows for concisely committing to an ordered (indexed) vector of data entries, based on Merkle trees.
+Algorand uses [Vector Commitments](./cryptographic-specs/merkle-vc-full.pdf), which allows for concisely committing to an ordered (indexed) vector of data entries, based on Merkle trees.
 
 
-
-[ledger-spec]: https://github.com/algorand/spec/ledger.md
-[abft-spec]: https://github.com/algorand/spec/abft.md
-
 [sha]: https://doi.org/10.6028/NIST.FIPS.180-4
-[sumhash]: https://github.com/algorandfoundation/specs/blob/master/dev/cryptographic-specs/sumhash-spec.pdf
 [ed25519]: https://tools.ietf.org/html/rfc8032
 [msgpack]: https://github.com/msgpack/msgpack/blob/master/spec.md
-[merklesignaturescheme]: https://github.com/algorandfoundation/specs/blob/master/dev/partkey.md
 [falcon]: https://falcon-sign.info/falcon.pdf
-[deterministic-falcon]: https://github.com/algorandfoundation/specs/blob/master/dev/cryptographic-specs/falcon-deterministic.pdf
-[vector-commitment]: https://github.com/algorandfoundation/specs/blob/master/dev/cryptographic-specs/merkle-vc-full.pdf

dev/ledger.md

@@ -285,7 +285,7 @@ A valid block's reward state matches the expected reward state.
 The _balances_ are a set of mappings from _addresses_, 256-bit integers, to
 _balance records_.  A _balance record_ contains the following fields: the
 account _raw balance_, the account _status_, the account _rewards base_ and
-_total awarded amount_, the account _spending key_, and the account [_participation keys_][partkey-spec].
+_total awarded amount_, the account _spending key_, and the account [_participation keys_](./partkey.md).
 
 The account raw balance $a_I$ is a 64-bit unsigned integer which determines how
 much money the address has.
@@ -324,7 +324,7 @@ The account's spending key determines how transactions from this account must be
 Transactions from this account must have this value (or, if this value zero, the account's address) as their authorization address. This is described in the [Authorization and Signatures][Authorization and Signatures] section below.
 
 The account's participation keys $\pk$ are defined in Algorand's [specification
-of participation keys][partkey-spec].
+of participation keys](./partkey.md).
 
 An account's participation keys and voting stake from a recent round is returned
 by the $\Record$ procedure in the [Byzantine Agreement Protocol][abft-spec].
@@ -1276,7 +1276,3 @@ In this case every occurrence is counted independently in validation.
 Validation process checks all non-empty signatures are valid and their count
 not less than the threshold. Validation fails if any of signatures is invalid
 even if count of all remaining correct signatures is greater or equals than the threshold.
-
-
-[abft-spec]: https://github.com/algorand/spec/abft.md
-[partkey-spec]: https://github.com/algorand/spec/partkey.md

dev/partkey.md

@@ -65,7 +65,7 @@ sub-key per batch, $\KeyDilution$. For example, the default $\KeyDilution$
 value of of the genesis consensus protocol (V17) was $10,000$. 
 An Algorand account can change its $\KeyDilution$ via 
 key registration transactions (see 
-[the ledger specification](https://github.com/algorandfoundation/specs/blob/master/dev/ledger.md)).
+[the ledger specification](./ledger.md)).
 
 
 ### One\-time Signature
@@ -138,15 +138,15 @@ messages between Algorand users. It contains the following fields:
 To check the validity of a voting message, its VRF selection key
 needs to be verified. Algorand uses Verifiable Random Function (VRF) to 
 generate selection keys (more details in 
-[crypto specification](https://github.com/algorandfoundation/specs/blob/master/dev/crypto.md)).
+[crypto specification](./crypto.md)).
 
 More specifically, an unverified vote ($\unauthenticatedVote$) has the
 following fields:
 
  - _Raw Vote_ $\mathrm{R}$, an inner struct contains $\Sender$, $\Round$, $\Period$, 
    $\Step$, and $\Proposal$.
 
- - _Unverified Credential_ $\Cred$. $\Cred$ contains 
+ - _Unverified Credential_ $\Cred$. $\Cred$ contains
    a single field $\mathrm{Proof}$, which is a VRF proof.
 
  - _Signature_ $\Sig$, one-time signature of the vote.