Fix more links in tutorials

content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md

@@ -54,7 +54,7 @@ Each validated ledger has a canonical order in which transactions apply. This or
 
 ### LastLedgerSequence
 
-[`LastLedgerSequence`](reference-transaction-format.html#lastledgersequence) is an optional parameter of all transactions.  This instructs the XRP Ledger that a transaction must be validated on or before a specific ledger instance.  The XRP Ledger never includes a transaction in a ledger instance whose sequence number is higher than the transaction's `LastLedgerSequence` parameter.
+`LastLedgerSequence` is an optional [parameter of all transactions](transaction-common-fields.html).  This instructs the XRP Ledger that a transaction must be validated on or before a specific ledger instance.  The XRP Ledger never includes a transaction in a ledger instance whose sequence number is higher than the transaction's `LastLedgerSequence` parameter.
 
 Use the `LastLedgerSequence` parameter to prevent undesirable cases where a transaction is not confirmed promptly but could be included in a future ledger.  You should specify the `LastLedgerSequence` parameter on every transaction.  Automated processes should use a value of 4 greater than the last validated ledger index to make sure that a transaction is validated or rejected in a predictable and prompt way.
 
@@ -138,14 +138,14 @@ The difference between the two transaction failure cases (labeled (1) and (2) in
 - In failure case (1), the transaction was included in a ledger and destroyed the [XRP transaction cost](transaction-cost.html), but did nothing else. This could be caused by a lack of liquidity, improperly specified [paths](paths.html), or other circumstances. For many such failures, immediately retrying with a similar transaction is likely to have the same result. You may get different results if you wait for circumstances to change.
 
 - In failure case (2), the transaction was not included in a validated ledger, so it did nothing at all, not even destroy the transaction cost. This could be the result of the transaction cost being too low for the current load on the XRP Ledger, the `LastLedgerSequence` being too soon, or it could be due to other conditions such as an unstable network connection. In contrast to failure case (1), it is more likely that a new transaction is likely to succeed if you change only the `LastLedgerSequence` and possibly the `Fee` and submit again.
-    - It is also possible that the transaction could not succeed due to the state of the ledger, for example because the sending address disabled the key pair used to sign the transaction. If the transaction's provisional result was a [`tef`-class code](reference-transaction-format.html#tef-codes), the transaction is less likely to succeed without further modification.
+    - It is also possible that the transaction could not succeed due to the state of the ledger, for example because the sending address disabled the key pair used to sign the transaction. If the transaction's provisional result was a [`tef`-class code](tef-codes.html), the transaction is less likely to succeed without further modification.
 
 
 #### Ledger Gaps
 
 If your server does not have continuous ledger history from when the transaction was originally submitted up to and including the ledger identified by `LastLedgerSequence`, you may not know the final outcome of the transaction. (If it was included in one of the ledger versions your server is missing, you do not know whether it succeeded or failed.)
 
-Your `rippled` server should automatically acquire the missing ledger versions when it has spare resources (CPU/RAM/disk IO) to do so, unless the ledgers are older than its [configured amount of history to store](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg#L581). Depending on the size of the gap and the resource usage of your server, acquiring missing ledgers should take a few minutes. You can also manually request your server to acquire historical ledger versions using the [`ledger_request` command](reference-rippled.html#ledger-request).
+Your `rippled` server should automatically acquire the missing ledger versions when it has spare resources (CPU/RAM/disk IO) to do so, unless the ledgers are older than its [configured amount of history to store](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg#L581). Depending on the size of the gap and the resource usage of your server, acquiring missing ledgers should take a few minutes. You can also manually request your server to acquire historical ledger versions using the [ledger_request method][].
 
 Alternatively, you can look up the status of the transaction using a different `rippled` server that already has the needed ledger history, such as Ripple's full-history servers at `s2.ripple.com`. Only use a server you trust for this purpose. A malicious server could be programmed to provide false information about the status and outcome of a transaction.
 
@@ -176,7 +176,7 @@ How the application does these actions depends on the API the application uses.
 
 #### Determine the Account Sequence
 
-`rippled` provides the [account_info](reference-rippled.html#account-info) method to learn an account's sequence number in the last validated ledger.
+`rippled` provides the [account_info method][] to learn an account's sequence number in the last validated ledger.
 
 JSON-RPC Request:
 
@@ -222,7 +222,7 @@ If an application were to submit three transactions signed by this account, they
 
 #### Determine the Last Validated Ledger
 
-`rippled` provides the [server_state](reference-rippled.html#server-state) command which returns the ledger sequence number of the last validated ledger.
+The [server_state method][] returns the ledger index of the last validated ledger.
 
 Request:
 

content/tutorials/use-simple-xrp-payments/send-a-multisigned-transaction.md

@@ -9,7 +9,7 @@ The following procedure demonstrates how to create, sign, and submit a multi-sig
 - Multi-signing must be available. Multi-signing has been enabled by an [**Amendment**](amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27.
 
 
-### 1. Create the transaction
+## 1. Create the transaction
 
 Create a JSON object that represents the transaction you want to submit. You have to specify _everything_ about this transaction, including `Fee` and `Sequence`. Also include the field `SigningPubKey` as an empty string, to indicate that the transaction is multi-signed.
 
@@ -34,7 +34,7 @@ Here's an example transaction ready to be multi-signed:
 (This transaction creates an accounting relationship from rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC to rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh with a maximum balance of 100 USD.)
 
 
-### 2. Get one signature
+## 2. Get one signature
 
 Use the [sign_for method][] with the secret key and address of one of the members of your SignerList to get a signature for that member.
 
@@ -88,9 +88,9 @@ Use the [sign_for method][] with the secret key and address of one of the member
 
 Save the `tx_json` field of the response: it has the new signature in the `Signers` field. You can discard the value of the `tx_blob` field.
 
-If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](#availability-of-multi-signing).
+If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](start-a-new-genesis-ledger-in-stand-alone-mode.html#settings-in-new-genesis-ledgers).
 
-### 3. Get additional signatures
+## 3. Get additional signatures
 
 You can collect additional signatures in parallel or in serial:
 
@@ -165,7 +165,7 @@ You can collect additional signatures in parallel or in serial:
 Depending on the SignerList you configured, you may need to repeat this step several times to get signatures from all the necessary parties.
 
 
-### 4. Combine signatures and submit
+## 4. Combine signatures and submit
 
 If you collected the signatures in serial, the `tx_json` from the last `sign_for` response has all the signatures assembled, so you can use that as the argument to the [submit_multisigned method][].
 
@@ -244,7 +244,7 @@ If you collected the signatures in parallel, you must manually construct a `tx_j
 Take note of the `hash` value from the response so you can check the results of the transaction later.  (In this case, the hash is `BD636194C48FD7A100DE4C972336534C8E710FD008C0F3CF7BC5BF34DAF3C3E6`.)
 
 
-### 5. Close the ledger
+## 5. Close the ledger
 
 If you are using the live network, you can wait 4-7 seconds for the ledger to close automatically.
 
@@ -261,7 +261,7 @@ If you're running `rippled` in stand-alone mode, use the [ledger_accept method][
     }
 
 
-### 6. Confirm transaction results
+## 6. Confirm transaction results
 
 Use the hash value from the response to the `submit_multisigned` command to look up the transaction using the [tx method][]. In particular, check that the `TransactionResult` is the string `tesSUCCESS`.