Link fixes and other cleanup

- Clarifies that SetFee transaction hashes weren't always unique
  (Fixes #696)
- Fixes some broken links and adds a couple more useful links.
- Mention different types of transactions in tx basics page
- Fix inconsistent naming of 'list xrp...' use case

content/concepts/payment-system-basics/transaction-basics/transaction-basics.md

@@ -2,6 +2,8 @@
 
 A _Transaction_ is the only way to modify the XRP Ledger. Transactions are only final if signed, submitted, and accepted into a validated ledger version following the [consensus process](consensus.html). Some ledger rules also generate _[pseudo-transactions](pseudo-transaction-types.html)_, which aren't signed or submitted, but still must be accepted by consensus. Transactions that fail are also included in ledgers because they modify balances of XRP to pay for the anti-spam [transaction cost][].
 
+Transactions can do more than just send money. In addition to supporting various [Payment Types](payment-types.html), transactions in the XRP Ledger are also used to rotate [cryptographic keys](cryptographic-keys.html), manage other settings, and trade in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). The [`rippled` API reference](rippled-api.html) has a complete [list of transaction types](transaction-types.html).
+
 
 ### Identifying Transactions
 
@@ -9,6 +11,9 @@ Every signed transaction has a unique `"hash"` that identifies it. The server pr
 
 The transaction hash can be used as a "proof of payment" since anyone can [look up the transaction by its hash](look-up-transaction-results.html) to verify its final status.
 
+{% include '_snippets/setfee_uniqueness_note.md' %}
+<!--_ -->
+
 
 ## Claimed Cost Justification
 
@@ -189,8 +194,8 @@ Example response from the `tx` command:
 }
 ```
 
-## See Also
 
+## See Also
 
 - **Concepts:**
     - [Payment Types](payment-types.html)

content/concepts/the-rippled-server/ledger-history/ledger-history.md

@@ -1,6 +1,6 @@
 # Ledger History
 
-The [consensus process](intro-to-consensus.html) creates a chain of [validated ledger versions](ledgers.html), each derived from the previous one by applying a set of transactions. Every `rippled` server stores ledger versions and transaction history locally. The amount of transaction history a server stores depends on how long that server has been online and how much history it is configured to fetch and keep.
+The [consensus process](intro-to-consensus.html) creates a chain of [validated ledger versions](ledgers.html), each derived from the previous one by applying a set of [transactions](transaction-basics.html). Every [`rippled` server](the-rippled-server.html) stores ledger versions and transaction history locally. The amount of transaction history a server stores depends on how long that server has been online and how much history it is configured to fetch and keep.
 
 Servers in the peer-to-peer XRP Ledger network share transactions and other data with each other as part of the consensus process. Each server independently builds each new ledger version and compares results with its trusted validators to ensure consistency. (If a consensus of trusted validators disagrees with a server's results, that server fetches the necessary data from its peers to achieve consistency.) Servers can download older data from their peers to fill gaps in their available history. The structure of the ledger uses cryptographic [hashes](basic-data-types.html#hashes) of the data so that any server can verify the integrity and consistency of the data.