chore(website): update proposing broken links (#14041)

Co-authored-by: dave | d1onys1us <13951458+d1onys1us@users.noreply.github.com>

packages/website/pages/docs/concepts/proposing.mdx

@@ -3,9 +3,9 @@
 On Taiko, the next L2 state is known immediately and deterministically at the time a block is proposed to the TaikoL1 contract. After a block is proposed, a series of checks are done to compute this post-L2 state:
 
 1. Block is proposed by any proposer (permissionlessly).
-2. Block level properties' validity is checked by the TaikoL1 contract with the ([proposed block intrinsic validity function](./intrinsic-validity-functions#proposed-block-intrinsic-validity-function)).
-3. Proposed block is downloaded by a Taiko node, and the transaction list is parsed over and checked for validity ([transaction list intrinsic validity function](./intrinsic-validity-functions#transaction-list-intrinsic-validity-function)).
-    - IF every transaction in the list is valid, an ordered subset of the list is created by skipping over transactions which have an invalid nonce or the sender has too little Ether balance to pay for the transaction. This ordered subset is used along with the [anchor transaction](./anchor-transaction) to create a Taiko L2 block.
+2. Block level properties' validity is checked by the TaikoL1 contract with the ([proposed block intrinsic validity function](./proposing#proposed-block-intrinsic-validity-function)).
+3. Proposed block is downloaded by a Taiko node, and the transaction list is parsed over and checked for validity ([transaction list intrinsic validity function](./proposing#transaction-list-intrinsic-validity-function)).
+    - IF every transaction in the list is valid, an ordered subset of the list is created by skipping over transactions which have an invalid nonce or the sender has too little Ether balance to pay for the transaction. This ordered subset is used along with the [anchor transaction](./proposing#anchor-transaction) to create a Taiko L2 block.
     - IF any transaction in the list is invalid, an empty block (with only the anchor tx) is created on L2.
 
 ## Intrinsic validity functions
@@ -23,7 +23,7 @@ A proposed block must pass these two checks in order to map the txList to an L2
 
 ### Proposed block intrinsic validity function
 
-The formal specification of the proposed block intrinsic can be found in the [whitepaper](/docs/resources/whitepaper), but on a high level, the proposed block intrinsic validity function checks that the block is valid except for transaction list validity checks. This is separated because on TaikoL1, the transaction list is not known and stored as a data blob. It would also be too expensive to do these checks on L1.
+The formal specification of the proposed block intrinsic can be found in the [whitepaper](https://taikoxyz.github.io/taiko-mono/taiko-whitepaper.pdf), but on a high level, the proposed block intrinsic validity function checks that the block is valid except for transaction list validity checks. This is separated because on TaikoL1, the transaction list is not known and stored as a data blob. It would also be too expensive to do these checks on L1.
 
 | Name                    | Symbol            | Meaning                                                                                                  |
 | ----------------------- | ----------------- | -------------------------------------------------------------------------------------------------------- |
@@ -81,7 +81,7 @@ The anchor transaction is required to be the first transaction in a Taiko block
 1. Persisting `l1Height` $C_a$, `l1Hash` $C_h$, `l1SignalRoot`, and `parentGasUsed` (data inherited from L1) to the storage trie. These values can be used by bridges to validate cross-chain messages.
 2. Comparing $ρ_{i−1}$, the public input hash stored by the previous block, with `KEC(i − 1, d, h[2..256])`. The anchor transaction will throw an exception if such comparison fails. The protocol requires the anchor transaction to execute successfully and will not accept a proof for a block that fails to do so. Note that the genesis block has $ρ_0$ ≡ `KEC(0, d, [0, ..., 0])`.
 3. Persisting a new public input hash $ρ_i$ ≡ `KEC(i, d, h[1..255])` to the storage trie for the next block to use. This allows transactions, in the current and all following blocks, to access these public input data with confidence as their values are now covered by ZK-EVM’s storage proof.
-4. With anchoring, the block mapping function `M` (defined in the [whitepaper](/docs/resources/whitepaper)) can be simplified to:  
+4. With anchoring, the block mapping function `M` (defined in the [whitepaper](https://taikoxyz.github.io/taiko-mono/taiko-whitepaper.pdf)) can be simplified to:  
 $$$
 \begin{aligned}
 B &≡ (H, T, U) \\