Minor docs cleanup (#2472)

* docs: link consensus to blockchain spec. closes #2422

* docs: deprecate research section. closes #2401

* docs: fix some links

* docs: fix some markdown lists

* docs: fix more links

docs/tendermint-core/running-in-production.md

@@ -6,7 +6,7 @@ By default, Tendermint uses the `syndtr/goleveldb` package for it's in-process
 key-value database. Unfortunately, this implementation of LevelDB seems to suffer under heavy load (see
 [#226](https://github.com/syndtr/goleveldb/issues/226)). It may be best to
 install the real C-implementaiton of LevelDB and compile Tendermint to use
-that using `make build_c`. See the [install instructions](../introduction/install) for details.
+that using `make build_c`. See the [install instructions](../introduction/install.md) for details.
 
 Tendermint keeps multiple distinct LevelDB databases in the `$TMROOT/data`:
 
@@ -20,11 +20,11 @@ Tendermint keeps multiple distinct LevelDB databases in the `$TMROOT/data`:
 - `tx_index.db`: Indexes txs (and their results) by tx hash and by DeliverTx result tags.
 
 By default, Tendermint will only index txs by their hash, not by their DeliverTx
-result tags. See [indexing transactions](../app-dev/indexing-transactions) for
+result tags. See [indexing transactions](../app-dev/indexing-transactions.md) for
 details.
 
 There is no current strategy for pruning the databases. Consider reducing
-block production by [controlling empty blocks](../tendermint-core/using-tendermint#No-Empty-Blocks)
+block production by [controlling empty blocks](../tendermint-core/using-tendermint.md#no-empty-blocks)
 or by increasing the `consensus.timeout_commit` param. Note both of these are
 local settings and not enforced by the consensus.
 
@@ -50,7 +50,9 @@ logging level, you can do so by running tendermint with
 ## Write Ahead Logs (WAL)
 
 Tendermint uses write ahead logs for the consensus (`cs.wal`) and the mempool
-(`mempool.wal`). Both WALs have a max size of 1GB and are automatically rotated..
+(`mempool.wal`). Both WALs have a max size of 1GB and are automatically rotated.
+
+### Consensus WAL
 
 The `consensus.wal` is used to ensure we can recover from a crash at any point
 in the consensus state machine.
@@ -60,7 +62,9 @@ validator. Since Tendermint validators are expected to never sign a conflicting
 WAL ensures we can always recover deterministically to the latest state of the consensus without
 using the network or re-signing any consensus messages.
 
-If your `consensus.wal` is corrupted, see [below](#WAL-Corruption).
+If your `consensus.wal` is corrupted, see [below](#wal-corruption).
+
+### Mempool WAL
 
 The `mempool.wal` logs all incoming txs before running CheckTx, but is
 otherwise not used in any programmatic way. It's just a kind of manual

docs/tendermint-core/using-tendermint.md

@@ -305,6 +305,12 @@ can take on the order of a second. For a quick result, use
 `broadcast_tx_sync`, but the transaction will not be committed until
 later, and by that point its effect on the state may change.
 
+Note the mempool does not provide strong guarantees - just because a tx passed
+CheckTx (ie. was accepted into the mempool), doesn't mean it will be committed,
+as nodes with the tx in their mempool may crash before they get to propose.
+For more information, see the [mempool
+write-ahead-log](../tendermint-core/running-in-production.md#mempool-wal)
+
 ## Tendermint Networks
 
 When `tendermint init` is run, both a `genesis.json` and