Fix dead links

Author: ch1bo

src/client/README.md

@@ -28,7 +28,7 @@ Below we present a table with clients and servers that implement each protocol:
 
 > [!NOTE]
 >
-> Please help us keep this list up-to-date by [suggesting an edit](https://github.com/cardano-scaling/cardano-blueprint/edit/main/src/server-client/README.md).
+> Please help us keep this list up-to-date by [suggesting an edit](https://github.com/cardano-scaling/cardano-blueprint/edit/main/src/client/README.md).
 
 [cardano-node]: https://github.com/IntersectMBO/cardano-node
 [cardano-cli]: https://github.com/IntersectMBO/cardano-cli

src/client/node-to-client/README.md

@@ -7,7 +7,7 @@ trust between peers and consequently they behave more like traditional
 client/server APIs.
 
 In particular, these mini-protocols will also be wrapped by a
-[multiplexer](../network/multiplexing.md).
+[multiplexer](../../network/multiplexing.md).
 
 These mini-protocols are:
 

src/client/node-to-client/state-query/README.md

@@ -3,7 +3,7 @@
 > Protocol version: V19
 
 > [!WARNING]
-> TODO: Explain how to use and relate state diagram to full protocol in [network](../../../../network) chapter?
+> TODO: Explain how to use and relate state diagram to full protocol in [network](../../../network) chapter?
 
 <details>
   <summary> Full mini-protocol state diagram</summary>

src/codecs/README.md

@@ -32,7 +32,7 @@ different tag for each one of the eras in the Cardano blockchain:
 ```
 
 These definitions are made available in the
-[`base.cddl`](https://github.com/cardano-scaling/cardano-blueprint/tree/main/src/codecs/base.cddl)
+[`base.cddl`](base.cddl)
 file which we will import qualified with `;# import base as base`.
 
 On the other side, Ledger CDDL specs are fully self-contained for each

src/consensus/README.md

@@ -142,8 +142,8 @@ resource draining attacks.
 So the design at this stage involves transmitting chains of headers rather than
 whole blocks, and using a secondary mechanism to download block bodies of
 interest. This gives the reason why
-[`ChainSync`](../storage/miniprotocols/chainsync.md) and
-[`BlockFetch`](../storage/miniprotocols/blockfetch.md) are separate protocols.
+[`ChainSync`](../network/node-to-node/chainsync) and
+[`BlockFetch`](../network/node-to-node/blockfetch) are separate protocols.
 The Consensus chain selection can look only at chains of block headers, whereas
 the validity check of the block body can be performed by the Ledger rules,
 effectively separating concerns.

src/consensus/chainsel.md

@@ -16,8 +16,8 @@ network as a whole.
 Because each node performs chain selection, the Cardano network acts as a
 forward-filtering diffusion network.
 
-The block headers come from [`ChainSync`](../storage/miniprotocols/chainsync.md) and
-the block bodies come from [`BlockFetch`](../storage/miniprotocols/blockfetch.md).
+The block headers come from [`ChainSync`](../network/node-to-node/chainsync) and
+the block bodies come from [`BlockFetch`](../network/node-to-node/blockfetch).
 
 > [!NOTE]
 >

src/consensus/forging.md

@@ -38,7 +38,7 @@ valid block.
 >
 > To ensure the new block is actually valid, it could be fed into the [Chain
 > Selection](./chainsel.md) logic, which is expected to select it and then
-> [diffuse](../storage/diffusion.md) it via the usual mechanisms. This sanity
+> [diffuse](../storage/#chain-diffusion) it via the usual mechanisms. This sanity
 > check is not a hard requirement but it is advised to be implemented. If not
 > even the node that created the block can adopt it, sending such block to the
 > network would be useless.

src/network/node-to-node/blockfetch/README.md

@@ -15,8 +15,8 @@ explicit request from the client.
 > avoid duplicated requests.
 
 Received blocks are then given to the [chain
-selection](../../consensus/chainsel.md) logic to determine their
-[validity](../../consensus/chainvalid.md) and, depending on the chain selection
+selection](../../../consensus/chainsel.md) logic to determine their
+[validity](../../../consensus/chainvalid.md) and, depending on the chain selection
 outcome, may be incorporated into the currently selected chain.
 
 If the peer misbehaves, the connection will be abruptly

src/network/node-to-node/chainsync/README.md

@@ -150,7 +150,7 @@ for the particular era:
 
 [network-design]: https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-design/network-design.pdf
 [network-spec]: https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-spec/network-spec.pdf
-[k-secparam]: ../../consensus/chainsel.md#the-k-security-parameter
+[k-secparam]: ../../../consensus/chainsel.md#the-k-security-parameter
 <!-- iohk.io links return 403 "if you are not a human" -->
 <!-- markdown-link-check-disable-next-line -->
 [pipelining]: https://iohk.io/en/blog/posts/2022/02/01/introducing-pipelining-cardanos-consensus-layer-scaling-solution/

src/network/node-to-node/txsubmission2/README.md

@@ -8,7 +8,7 @@ upon explicit request from the client.
 
 The goal of `TxSubmission2` is to let other peers know about the transactions
 that the local node considers valid (with respects to the chain that the local
-node has selected in [Chain Selection](../consensus/chainsel.md) in the
+node has selected in [Chain Selection](../../../consensus/chainsel.md) in the
 consensus layer), and transmit such transactions if requested.
 
 An important piece of information is that transactions flow in the