Merge remote-tracking branch 'origin/develop' into dev/multisig

.github/CODEOWNERS

@@ -4,4 +4,4 @@
 *       @ebuchman @melekes @xla
 
 # Precious documentation
-/docs/  @zramsay @jolesbi
+/docs/  @zramsay

abci/example/example_test.go

@@ -39,7 +39,7 @@ func TestGRPC(t *testing.T) {
 }
 
 func testStream(t *testing.T, app types.Application) {
-	numDeliverTxs := 200000
+	numDeliverTxs := 20000
 
 	// Start the listener
 	server := abciserver.NewSocketServer("unix://test.sock", app)
@@ -72,7 +72,7 @@ func testStream(t *testing.T, app types.Application) {
 			}
 			if counter == numDeliverTxs {
 				go func() {
-					time.Sleep(time.Second * 2) // Wait for a bit to allow counter overflow
+					time.Sleep(time.Second * 1) // Wait for a bit to allow counter overflow
 					close(done)
 				}()
 				return
@@ -148,7 +148,7 @@ func testGRPCSync(t *testing.T, app *types.GRPCApplication) {
 		t.Log("response", counter)
 		if counter == numDeliverTxs {
 			go func() {
-				time.Sleep(time.Second * 2) // Wait for a bit to allow counter overflow
+				time.Sleep(time.Second * 1) // Wait for a bit to allow counter overflow
 			}()
 		}
 

crypto/multisig/compact_bit_array.go

@@ -37,6 +37,8 @@ func (bA *CompactBitArray) Size() int {
 	} else if bA.ExtraBitsStored == byte(0) {
 		return len(bA.Elems) * 8
 	}
+	// num_bits = 8*num_full_bytes + overflow_in_last_byte
+	// num_full_bytes = (len(bA.Elems)-1)
 	return (len(bA.Elems)-1)*8 + int(bA.ExtraBitsStored)
 }
 

docs/README.md

@@ -11,17 +11,17 @@ replicates it on many machines. In other words, a blockchain.
 
 Tendermint requires an application running over the Application Blockchain
 Interface (ABCI) - and comes packaged with an example application to do so.
-Follow the [installation instructions](./introduction/install) to get up and running
-quickly. For more details on [using tendermint](./tendermint-core/using-tendermint) see that
+Follow the [installation instructions](./introduction/install.md) to get up and running
+quickly. For more details on [using tendermint](./tendermint-core/using-tendermint.md) see that
 and the following sections.
 
 ## Networks
 
 Testnets can be setup manually on one or more machines, or automatically on one
 or more machine, using a variety of methods described in the [deploy testnets
-section](./networks/deploy-testnets).
+section](./networks/deploy-testnets.md).
 
 ## Application Development
 
 The first step to building application on Tendermint is to [install
-ABCI-CLI](./app-dev/getting-started) and play with the example applications.
+ABCI-CLI](./app-dev/getting-started.md) and play with the example applications.

docs/app-dev/abci-cli.md

@@ -36,7 +36,7 @@ Available Commands:
   console     Start an interactive abci console for multiple commands
   counter     ABCI demo example
   deliver_tx  Deliver a new tx to the application
-  kvstore       ABCI demo example
+  kvstore     ABCI demo example
   echo        Have the application echo a message
   help        Help about any command
   info        Get some info about the application
@@ -140,7 +140,7 @@ response.
 The server may be generic for a particular language, and we provide a
 [reference implementation in
 Golang](https://github.com/tendermint/tendermint/tree/develop/abci/server). See the
-[list of other ABCI implementations](./ecosystem.html) for servers in
+[list of other ABCI implementations](./ecosystem.md) for servers in
 other languages.
 
 The handler is specific to the application, and may be arbitrary, so

docs/app-dev/app-architecture.md

@@ -46,6 +46,5 @@ See the following for more extensive documentation:
 
 - [Interchain Standard for the Light-Client REST API](https://github.com/cosmos/cosmos-sdk/pull/1028)
 - [Tendermint RPC Docs](https://tendermint.github.io/slate/)
-- [Tendermint in Production](https://github.com/tendermint/tendermint/pull/1618)
-- [Tendermint Basics](https://tendermint.readthedocs.io/en/master/using-tendermint.html)
-- [ABCI spec](https://github.com/tendermint/tendermint/blob/develop/abci/docs/abci-spec.md)
+- [Tendermint in Production](../tendermint-core/running-in-production.md)
+- [ABCI spec](./abci-spec.md)

docs/architecture/adr-012-ABCI-propose-tx.md

@@ -0,0 +1,183 @@
+# ADR 012: ABCI `ProposeTx` Method
+
+## Changelog
+
+25-06-2018: Initial draft based on [#1776](https://github.com/tendermint/tendermint/issues/1776)
+
+## Context
+
+[#1776](https://github.com/tendermint/tendermint/issues/1776) was
+opened in relation to implementation of a Plasma child chain using Tendermint
+Core as consensus/replication engine.
+
+Due to the requirements of [Minimal Viable Plasma (MVP)](https://ethresear.ch/t/minimal-viable-plasma/426) and [Plasma Cash](https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298), it is necessary for ABCI apps to have a mechanism to handle the following cases (more may emerge in the near future):
+
+1. `deposit` transactions on the Root Chain, which must consist of a block
+   with a single transaction, where there are no inputs and only one output
+   made in favour of the depositor. In this case, a `block` consists of
+   a transaction with the following shape:
+
+   ```
+   [0, 0, 0, 0, #input1 - zeroed out
+    0, 0, 0, 0, #input2 - zeroed out
+    <depositor_address>, <amount>, #output1 - in favour of depositor
+    0, 0, #output2 - zeroed out
+    <fee>,
+   ]
+   ```
+
+   `exit` transactions may also be treated in a similar manner, wherein the
+   input is the UTXO being exited on the Root Chain, and the output belongs to
+   a reserved "burn" address, e.g., `0x0`. In such cases, it is favourable for
+   the containing block to only hold a single transaction that may receive
+   special treatment.
+
+2. Other "internal" transactions on the child chain, which may be initiated
+   unilaterally.  The most basic example of is a coinbase transaction
+   implementing validator node incentives, but may also be app-specific. In
+   these cases, it may be favourable for such transactions to
+   be ordered in a specific manner, e.g., coinbase transactions will always be
+   at index 0. In general, such strategies increase the determinism and
+   predictability of blockchain applications.
+
+While it is possible to deal with the cases enumerated above using the
+existing ABCI, currently available result in suboptimal workarounds. Two are
+explained in greater detail below.
+
+### Solution 1: App state-based Plasma chain
+
+In this work around, the app maintains a `PlasmaStore` with a corresponding
+`Keeper`. The PlasmaStore is responsible for maintaing a second, separate
+blockchain that complies with the MVP specification, including `deposit`
+blocks and other "internal" transactions. These "virtual" blocks are then broadcasted
+to the Root Chain.
+
+This naive approach is, however, fundamentally flawed, as it by definition
+diverges from the canonical chain maintained by Tendermint. This is further
+exacerbated if the business logic for generating such transactions is
+potentially non-deterministic, as this should not even be done in
+`Begin/EndBlock`, which may, as a result, break consensus guarantees.
+
+Additinoally, this has serious implications for "watchers" - independent third parties,
+or even an auxilliary blockchain, responsible for ensuring that blocks recorded
+on the Root Chain are consistent with the Plasma chain's. Since, in this case,
+the Plasma chain is inconsistent with the canonical one maintained by Tendermint
+Core, it seems that there exists no compact means of verifying the legitimacy of
+the Plasma chain without replaying every state transition from genesis (!).
+
+### Solution 2: Broadcast to Tendermint Core from ABCI app
+
+This approach is inspired by `tendermint`, in which Ethereum transactions are
+relayed to Tendermint Core. It requires the app to maintain a client connection
+to the consensus engine.
+
+Whenever an "internal" transaction needs to be created, the proposer of the
+current block broadcasts the transaction or transactions to Tendermint as
+needed in order to ensure that the Tendermint chain and Plasma chain are
+completely consistent.
+
+This allows "internal" transactions to pass through the full consensus
+process, and can be validated in methods like `CheckTx`, i.e., signed by the
+proposer, is the semantically correct, etc. Note that this involves informing
+the ABCI app of the block proposer, which was temporarily hacked in as a means
+of conducting this experiment, although this should not be necessary when the
+current proposer is passed to `BeginBlock`.
+
+It is much easier to relay these transactions directly to the Root
+Chain smart contract and/or maintain a "compressed" auxiliary chain comprised
+of Plasma-friendly blocks that 100% reflect the canonical (Tendermint)
+blockchain.  Unfortunately, this approach not idiomatic (i.e., utilises the
+Tendermint consensus engine in unintended ways). Additionally, it does not
+allow the application developer to:
+
+- Control the _ordering_ of transactions in the proposed block (e.g., index 0,
+or 0 to `n` for coinbase transactions)
+- Control the _number_ of transactions in the block (e.g., when a `deposit`
+block is required)
+
+Since determinism is of utmost importance in blockchain engineering, this approach,
+while more viable, should also not be considered as fit for production.
+
+## Decision
+
+### `ProposeTx`
+
+In order to address the difficulties described above, the ABCI interface must
+expose an additional method, tentatively named `ProposeTx`.
+
+It should have the following signature:
+
+```
+ProposeTx(RequestProposeTx) ResponseProposeTx
+```
+
+Where `RequestProposeTx` and `ResponseProposeTx` are `message`s with the
+following shapes:
+
+```
+message RequestProposeTx {
+  int64 next_block_height = 1; // height of the block the proposed tx would be part of
+  Validator proposer = 2; // the proposer details
+}
+
+message ResponseProposeTx {
+  int64 num_tx = 1; // the number of tx to include in proposed block
+  repeated bytes txs = 2; // ordered transaction data to include in block
+  bool exclusive = 3; // whether the block should include other transactions (from `mempool`)
+}
+```
+
+`ProposeTx` would be called by before `mempool.Reap` at this
+[line](https://github.com/tendermint/tendermint/blob/master/consensus/state.go#L906).
+Depending on whether `exclusive` is `true` or `false`, the proposed
+transactions are then pushed on top of the transactions received from
+`mempool.Reap`.
+
+### `DeliverTx`
+
+Since the list of `tx` received from `ProposeTx` are _not_ passed through `CheckTx`,
+it is probably a good idea to provide a means of differentiatiating "internal" transactions
+from user-generated ones, in case the app developer needs/wants to take extra measures to
+ensure validity of the proposed transactions.
+
+Therefore, the `RequestDeliverTx` message should be changed to provide an additional flag, like so:
+
+```
+message RequestDeliverTx {
+	bytes tx = 1;
+	bool internal = 2;
+}
+```
+
+Alternatively, an additional method `DeliverProposeTx` may be added as an accompanient to
+`ProposeTx`. However, it is not clear at this stage if this additional overhead is necessary
+to preserve consensus guarantees given that a simple flag may suffice for now.
+
+## Status
+
+Pending
+
+## Consequences
+
+### Positive
+
+- Tendermint ABCI apps will be able to function as minimally viable Plasma chains.
+- It will thereby become possible to add an extension to `cosmos-sdk` to enable
+	ABCI apps to support both IBC and Plasma, maximising interop.
+- ABCI apps will have great control and flexibility in managing blockchain state,
+	without having to resort to non-deterministic hacks and/or unsafe workarounds
+
+### Negative
+
+- Maintenance overhead of exposing additional ABCI method
+- Potential security issues that may have been overlooked and must now be tested extensively
+
+### Neutral
+
+- ABCI developers must deal with increased (albeit nominal) API surface area.
+
+## References
+
+- [#1776 Plasma and "Internal" Transactions in ABCI Apps](https://github.com/tendermint/tendermint/issues/1776)
+- [Minimal Viable Plasma](https://ethresear.ch/t/minimal-viable-plasma/426)
+- [Plasma Cash: Plasma with much less per-user data checking](https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298)

docs/architecture/adr-019-multisigs.md

@@ -0,0 +1,150 @@
+# ADR 019: Encoding standard for Multisignatures
+
+## Changelog 
+
+06-08-2018: Minor updates
+
+27-07-2018: Update draft to use amino encoding
+
+11-07-2018: Initial Draft
+
+## Context
+
+Multisignatures, or technically _Accountable Subgroup Multisignatures_ (ASM), 
+are signature schemes which enable any subgroup of a set of signers to sign any message, 
+and reveal to the verifier exactly who the signers were. 
+This allows for complex conditionals of when to validate a signature.
+
+Suppose the set of signers is of size _n_.
+If we validate a signature if any subgroup of size _k_ signs a message,
+this becomes what is commonly reffered to as a _k of n multisig_ in Bitcoin.
+
+This ADR specifies the encoding standard for general accountable subgroup multisignatures,
+k of n accountable subgroup multisignatures, and its weighted variant.
+
+In the future, we can also allow for more complex conditionals on the accountable subgroup. 
+
+## Proposed Solution
+
+### New structs
+
+Every ASM will then have its own struct, implementing the crypto.Pubkey interface.
+
+This ADR assumes that [replacing crypto.Signature with []bytes](https://github.com/tendermint/tendermint/issues/1957) has been accepted.
+
+#### K of N threshold signature
+
+The pubkey is the following struct:
+
+```golang
+type ThresholdMultiSignaturePubKey struct { // K of N threshold multisig
+	K       uint               `json:"threshold"`
+	Pubkeys []crypto.Pubkey    `json:"pubkeys"`
+}
+```
+We will derive N from the length of pubkeys. (For spatial efficiency in encoding)
+
+`Verify` will expect an `[]byte` encoded version of the Multisignature.
+(Multisignature is described in the next section)
+The multisignature will be rejected if the bitmap has less than k indices,
+or if any signature at any of the k indices is not a valid signature from
+the kth public key on the message.
+(If more than k signatures are included, all must be valid)
+
+`Bytes` will be the amino encoded version of the pubkey.
+
+Address will be `Hash(amino_encoded_pubkey)`
+
+The reason this doesn't use `log_8(n)` bytes per signer is because that heavily optimizes for the case where a very small number of signers are required.
+e.g. for `n` of size `24`, that would only be more space efficient for `k < 3`. 
+This seems less likely, and that it should not be the case optimized for.
+
+#### Weighted threshold signature
+
+The pubkey is the following struct:
+
+```golang
+type WeightedThresholdMultiSignaturePubKey struct {
+	Weights []uint             `json:"weights"`
+	Threshold uint             `json:"threshold"`
+	Pubkeys []crypto.Pubkey    `json:"pubkeys"`
+}
+```
+Weights and Pubkeys must be of the same length.
+Everything else proceeds identically to the K of N multisig, 
+except the multisig fails if the sum of the weights is less than the threshold.
+
+#### Multisignature
+
+The inter-mediate phase of the signatures (as it accrues more signatures) will be the following struct:
+```golang
+type Multisignature struct {
+	BitArray    CryptoBitArray // Documented later
+	Sigs        [][]byte       
+```
+
+It is important to recall that each private key will output a signature on the provided message itself.
+So no signing algorithm ever outputs the multisignature.
+The UI will take a signature, cast into a multisignature, and then keep adding
+new signatures into it, and when done marshal into `[]byte`.
+This will require the following helper methods:
+```golang
+func SigToMultisig(sig []byte, n int)
+func GetIndex(pk crypto.Pubkey, []crypto.Pubkey)
+func AddSignature(sig Signature, index int, multiSig *Multisignature)
+```
+The multisignature will be converted to an `[]byte` using amino.MarshalBinaryBare. \*
+
+#### Bit Array
+We would be using a new implementation of a bitarray. The struct it would be encoded/decoded from is 
+```golang
+type CryptoBitArray struct {
+	ExtraBitsStored  byte      `json:"extra_bits"` // The number of extra bits in elems. 
+	Elems            []byte    `json:"elems"`
+}
+```
+The reason for not using the BitArray currently implemented in `libs/common/bit_array.go`
+is that it is less space efficient, due to a space / time trade-off.
+Evidence for this is outlined in [this issue](https://github.com/tendermint/tendermint/issues/2077). 
+
+In the multisig, we will not be performing arithmetic operations,
+so there is no performance increase with the current implementation,
+and just loss of spatial efficiency.
+Implementing this new bit array with `[]byte` _should_ be simple, as no
+arithmetic operations between bit arrays are required, and save a couple of bytes.
+(Explained in that same issue)
+
+When this bit array encoded, the number of elements is encoded due to amino.
+However we may be encoding a full byte for what we actually only need 1-7 bits for.
+We store that difference in ExtraBitsStored.
+This allows for us to have an unbounded number of signers, and is more space efficient than what is currently used in `libs/common`.
+Again the implementation of this space saving feature is straight forward.
+
+### Encoding the structs
+
+We will use straight forward amino encoding. This is chosen for ease of compatibility in other languages. 
+
+### Future points of discussion
+
+If desired, we can use ed25519 batch verification for all ed25519 keys.
+This is a future point of discussion, but would be backwards compatible as this information won't need to be marshalled.
+(There may even be cofactor concerns without ristretto)
+Aggregation of pubkeys / sigs in Schnorr sigs / BLS sigs is not backwards compatible, and would need to be a new ASM type.
+
+## Status
+
+Proposed. 
+
+## Consequences
+
+### Positive
+* Supports multisignatures, in a way that won't require any special cases in our downstream verification code. 
+* Easy to serialize / deserialize
+* Unbounded number of signers
+
+### Negative
+* Larger codebase, however this should reside in a subfolder of tendermint/crypto, as it provides no new interfaces. (Ref #https://github.com/tendermint/go-crypto/issues/136)
+* Space inefficient due to utilization of amino encoding
+* Suggested implementation requires a new struct for every ASM. 
+
+### Neutral

docs/introduction/introduction.md

@@ -90,7 +90,7 @@ it can be used as a plug-and-play replacement for the consensus engines
 of other blockchain software. So one can take the current Ethereum code
 base, whether in Rust, or Go, or Haskell, and run it as a ABCI
 application using Tendermint consensus. Indeed, [we did that with
-Ethereum](https://github.com/tendermint/ethermint). And we plan to do
+Ethereum](https://github.com/cosmos/ethermint). And we plan to do
 the same for Bitcoin, ZCash, and various other deterministic
 applications as well.
 
@@ -227,7 +227,7 @@ design their message handlers to create a blockchain that does anything
 useful but this architecture provides a place to start. The diagram
 below illustrates the flow of messages via ABCI.
 
-![](assets/abci.png)
+![](imgs/abci.png)
 
 ## A Note on Determinism
 
@@ -263,7 +263,7 @@ Tendermint is an easy-to-understand, mostly asynchronous, BFT consensus
 protocol. The protocol follows a simple state machine that looks like
 this:
 
-![](assets/consensus_logic.png)
+![](imgs/consensus_logic.png)
 
 Participants in the protocol are called **validators**; they take turns
 proposing blocks of transactions and voting on them. Blocks are
@@ -321,7 +321,7 @@ consensus protocol. This adds an economic element to the security of the
 protocol, allowing one to quantify the cost of violating the assumption
 that less than one-third of voting power is Byzantine.
 
-The [Cosmos Network](http://cosmos.network) is designed to use this
+The [Cosmos Network](https://cosmos.network) is designed to use this
 Proof-of-Stake mechanism across an array of cryptocurrencies implemented
 as ABCI applications.
 
@@ -329,4 +329,4 @@ The following diagram is Tendermint in a (technical) nutshell. [See here
 for high resolution
 version](https://github.com/mobfoundry/hackatom/blob/master/tminfo.pdf).
 
-![](assets/tm-transaction-flow.png)
+![](imgs/tm-transaction-flow.png)

docs/introduction/quick-start.md

@@ -26,7 +26,7 @@ Requires:
 
 - `go` minimum version 1.10
 - `$GOPATH` environment variable must be set
-- `$GOPATH/bin` must be on your `$PATH` (see https://github.com/tendermint/tendermint/wiki/Setting-GOPATH)
+- `$GOPATH/bin` must be on your `$PATH` (see [here](https://github.com/tendermint/tendermint/wiki/Setting-GOPATH))
 
 To install Tendermint, run:
 
@@ -43,9 +43,12 @@ Confirm installation:
 
 ```
 $ tendermint version
-0.23.0-dev
+0.23.0
 ```
 
+Note: see the [releases page](https://github.com/tendermint/tendermint/releases) and the latest version
+should match what you see above.
+
 ## Initialization
 
 Running:
@@ -142,8 +145,6 @@ tendermint node --home ./mytestnet/node3 --proxy_app=kvstore --p2p.persistent_pe
 
 Note that after the third node is started, blocks will start to stream in
 because >2/3 of validators (defined in the `genesis.json`) have come online.
-Seeds can also be specified in the `config.toml`. See [this
-PR](https://github.com/tendermint/tendermint/pull/792) for more information
-about configuration options.
+Seeds can also be specified in the `config.toml`. See [here](../tendermint-core/configuration.md) for more information about configuration options.
 
 Transactions can then be sent as covered in the single, local node example above.

docs/networks/deploy-testnets.md

@@ -71,4 +71,4 @@ local testnet. Review the target in the Makefile to debug any problems.
 
 ### Cloud
 
-See the [next section](./terraform-and-ansible.html) for details.
+See the [next section](./terraform-and-ansible.md) for details.

docs/spec/p2p/connection.md

@@ -38,7 +38,7 @@ type msgPacket struct {
 }
 ```
 
-The `msgPacket` is serialized using [go-wire](https://github.com/tendermint/go-wire) and prefixed with 0x3.
+The `msgPacket` is serialized using [go-amino](https://github.com/tendermint/go-amino) and prefixed with 0x3.
 The received `Bytes` of a sequential set of packets are appended together
 until a packet with `EOF=1` is received, then the complete serialized message
 is returned for processing by the `onReceive` function of the corresponding channel.

docs/spec/reactors/mempool/reactor.md

@@ -2,12 +2,12 @@
 
 ## Channels
 
-[#1503](https://github.com/tendermint/tendermint/issues/1503)
+See [this issue](https://github.com/tendermint/tendermint/issues/1503)
 
 Mempool maintains a cache of the last 10000 transactions to prevent
 replaying old transactions (plus transactions coming from other
 validators, who are continually exchanging transactions). Read [Replay
-Protection](https://tendermint.readthedocs.io/projects/tools/en/master/app-development.html?#replay-protection)
+Protection](../../../../app-development.md#replay-protection)
 for details.
 
 Sending incorrectly encoded data or data exceeding `maxMsgSize` will result

docs/spec/software/abci.md

@@ -7,7 +7,7 @@ The ABCI message types are defined in a [protobuf
 file](https://github.com/tendermint/tendermint/blob/develop/abci/types/types.proto).
 
 For full details on the ABCI message types and protocol, see the [ABCI
-specification](https://github.com/tendermint/tendermint/blob/develop/docs/abci-spec.md).
+specification](https://github.com/tendermint/tendermint/blob/develop/docs/app-dev/abci-spec.md).
 Be sure to read the specification if you're trying to build an ABCI app!
 
 For additional details on server implementation, see the [ABCI

docs/spec/software/wal.md

@@ -28,6 +28,5 @@ WAL. Then it will go to precommit, and that time it will work because the
 private validator contains the `LastSignBytes` and then we’ll replay the
 precommit from the WAL.
 
-Make sure to read about [WAL
-corruption](https://tendermint.readthedocs.io/projects/tools/en/master/specification/corruption.html#wal-corruption)
+Make sure to read about [WAL corruption](../../../tendermint-core/running-in-production.md#wal-corruption)
 and recovery strategies.

docs/tendermint-core/how-to-read-logs.md

@@ -63,8 +63,8 @@ Next follows a standard block creation cycle, where we enter a new
 round, propose a block, receive more than 2/3 of prevotes, then
 precommits and finally have a chance to commit a block. For details,
 please refer to [Consensus
-Overview](./introduction.md#consensus-overview) or [Byzantine Consensus
-Algorithm](./spec/consensus).
+Overview](../introduction/introduction.md#consensus-overview) or [Byzantine Consensus
+Algorithm](../spec/consensus/consensus.md).
 
 ```
 I[10-04|13:54:30.393] enterNewRound(91/0). Current: 91/0/RoundStepNewHeight module=consensus
@@ -112,7 +112,7 @@ I[10-04|13:54:30.410] Recheck txs                                  module=mempoo
 Here is the list of modules you may encounter in Tendermint's log and a
 little overview what they do.
 
-- `abci-client` As mentioned in [Application Development Guide](./app-development.md), Tendermint acts as an ABCI
+- `abci-client` As mentioned in [Application Development Guide](../app-dev/app-development.md), Tendermint acts as an ABCI
   client with respect to the application and maintains 3 connections:
   mempool, consensus and query. The code used by Tendermint Core can
   be found [here](https://github.com/tendermint/tendermint/tree/develop/abci/client).
@@ -133,9 +133,9 @@ little overview what they do.
 - `p2p` Provides an abstraction around peer-to-peer communication. For
   more details, please check out the
   [README](https://github.com/tendermint/tendermint/blob/master/p2p/README.md).
-- `rpc` [Tendermint's RPC](./specification/rpc.md).
+- `rpc` [Tendermint's RPC](./rpc.md).
 - `rpc-server` RPC server. For implementation details, please read the
-  [README](https://github.com/tendermint/tendermint/blob/master/rpc/lib/README.md).
+  [doc.go](https://github.com/tendermint/tendermint/blob/master/rpc/lib/doc.go).
 - `state` Represents the latest state and execution submodule, which
   executes blocks against the application.
 - `types` A collection of the publicly exposed types and methods to

docs/tendermint-core/rpc.md

@@ -1,3 +1,5 @@
 # RPC
 
 The RPC documentation is hosted [here](https://tendermint.github.io/slate) and is generated by the CI from our [Slate repo](https://github.com/tendermint/slate). To update the documentation, edit the relevant `godoc` comments in the [rpc/core directory](https://github.com/tendermint/tendermint/tree/develop/rpc/core).
+
+NOTE: We will be moving the RPC documentation into the website in the near future. Stay tuned!

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

@@ -28,7 +28,7 @@ send & receive rate per connection (`SendRate`, `RecvRate`).
 ### RPC
 
 Endpoints returning multiple entries are limited by default to return 30
-elements (100 max).
+elements (100 max). See [here](./rpc.md) for more information about the RPC.
 
 Rate-limiting and authentication are another key aspects to help protect
 against DOS attacks. While in the future we may implement these
@@ -40,12 +40,12 @@ to achieve the same things.
 ## Debugging Tendermint
 
 If you ever have to debug Tendermint, the first thing you should
-probably do is to check out the logs. See ["How to read
-logs"](./how-to-read-logs.md), where we explain what certain log
+probably do is to check out the logs. See [How to read
+logs](./how-to-read-logs.md), where we explain what certain log
 statements mean.
 
 If, after skimming through the logs, things are not clear still, the
-second TODO is to query the /status RPC endpoint. It provides the
+next thing to try is query the /status RPC endpoint. It provides the
 necessary info: whenever the node is syncing or not, what height it is
 on, etc.
 
@@ -80,7 +80,7 @@ Other useful endpoints include mentioned earlier `/status`, `/net_info` and
 
 We have a small tool, called `tm-monitor`, which outputs information from
 the endpoints above plus some statistics. The tool can be found
-[here](https://github.com/tendermint/tools/tree/master/tm-monitor).
+[here](https://github.com/tendermint/tendermint/tree/master/tools/tm-monitor).
 
 Tendermint also can report and serve Prometheus metrics. See
 [Metrics](./metrics.md).
@@ -206,14 +206,15 @@ operation systems (like Mac OS).
 ### Miscellaneous
 
 NOTE: if you are going to use Tendermint in a public domain, make sure
-you read [hardware recommendations (see "4.
-Hardware")](https://cosmos.network/validators) for a validator in the
+you read [hardware recommendations](https://cosmos.network/validators) for a validator in the
 Cosmos network.
 
 ## Configuration parameters
 
-- `p2p.flush_throttle_timeout` `p2p.max_packet_msg_payload_size`
-  `p2p.send_rate` `p2p.recv_rate`
+- `p2p.flush_throttle_timeout`
+- `p2p.max_packet_msg_payload_size`
+- `p2p.send_rate`
+- `p2p.recv_rate`
 
 If you are going to use Tendermint in a private domain and you have a
 private high-speed network among your peers, it makes sense to lower

docs/tendermint-core/secure-p2p.md

@@ -3,10 +3,6 @@
 The Tendermint p2p protocol uses an authenticated encryption scheme
 based on the [Station-to-Station
 Protocol](https://en.wikipedia.org/wiki/Station-to-Station_protocol).
-The implementation uses
-[golang's](https://godoc.org/golang.org/x/crypto/nacl/box) [nacl
-box](http://nacl.cr.yp.to/box.html) for the actual authenticated
-encryption algorithm.
 
 Each peer generates an ED25519 key-pair to use as a persistent
 (long-term) id.

docs/tendermint-core/using-tendermint.md

@@ -151,7 +151,7 @@ and the `latest_app_hash` in particular:
 curl http://localhost:26657/status | json_pp | grep latest_app_hash
 ```
 
-Visit http://localhost:26657> in your browser to see the list of other
+Visit http://localhost:26657 in your browser to see the list of other
 endpoints. Some take no arguments (like `/status`), while others specify
 the argument name and use `_` as a placeholder.
 
@@ -224,7 +224,7 @@ new blockchain will not make any blocks.
 ## Configuration
 
 Tendermint uses a `config.toml` for configuration. For details, see [the
-config specification](./specification/configuration.md).
+config specification](./tendermint-core/configuration.md).
 
 Notable options include the socket address of the application
 (`proxy_app`), the listening address of the Tendermint peer
@@ -235,8 +235,7 @@ Some fields from the config file can be overwritten with flags.
 
 ## No Empty Blocks
 
-This much requested feature was implemented in version 0.10.3. While the
-default behaviour of `tendermint` is still to create blocks
+While the default behaviour of `tendermint` is still to create blocks
 approximately once per second, it is possible to disable empty blocks or
 set a block creation interval. In the former case, blocks will be
 created when there are new transactions or when the AppHash changes.
@@ -365,10 +364,7 @@ case, the genesis file contains the public key of our
 root directory will be able to make progress. Voting power uses an int64
 but must be positive, thus the range is: 0 through 9223372036854775807.
 Because of how the current proposer selection algorithm works, we do not
-recommend having voting powers greater than 10\^12 (ie. 1 trillion) (see
-[Proposals section of Byzantine Consensus
-Algorithm](./specification/byzantine-consensus-algorithm.md#proposals)
-for details).
+recommend having voting powers greater than 10\^12 (ie. 1 trillion).
 
 If we want to add more nodes to the network, we have two choices: we can
 add a new validator node, who will also participate in the consensus by
@@ -520,7 +516,7 @@ failing, you need at least four validator nodes (e.g., 2/3).
 
 Updating validators in a live network is supported but must be
 explicitly programmed by the application developer. See the [application
-developers guide](./app-development.md) for more details.
+developers guide](../app-dev/app-development.md) for more details.
 
 ### Local Network
 

docs/tools/monitoring.md

@@ -3,7 +3,7 @@
 Tendermint blockchain monitoring tool; watches over one or more nodes,
 collecting and providing various statistics to the user:
 
-- https://github.com/tendermint/tools/tree/master/tm-monitor
+- https://github.com/tendermint/tendermint/tree/master/tools/tm-monitor
 
 ## Quick Start
 

libs/clist/clist_test.go

@@ -149,8 +149,8 @@ func _TestGCRandom(t *testing.T) {
 
 func TestScanRightDeleteRandom(t *testing.T) {
 
-	const numElements = 10000
-	const numTimes = 1000
+	const numElements = 1000
+	const numTimes = 100
 	const numScanners = 10
 
 	l := New()
@@ -209,7 +209,7 @@ func TestScanRightDeleteRandom(t *testing.T) {
 
 	// Stop scanners
 	close(stop)
-	time.Sleep(time.Second * 1)
+	// time.Sleep(time.Second * 1)
 
 	// And remove all the elements.
 	for el := l.Front(); el != nil; el = el.Next() {
@@ -244,7 +244,7 @@ func TestWaitChan(t *testing.T) {
 		for i := 1; i < 100; i++ {
 			l.PushBack(i)
 			pushed++
-			time.Sleep(time.Duration(cmn.RandIntn(100)) * time.Millisecond)
+			time.Sleep(time.Duration(cmn.RandIntn(25)) * time.Millisecond)
 		}
 		close(done)
 	}()
@@ -283,7 +283,7 @@ FOR_LOOP2:
 			if prev == nil {
 				t.Fatal("expected PrevWaitChan to block forever on nil when reached first elem")
 			}
-		case <-time.After(5 * time.Second):
+		case <-time.After(3 * time.Second):
 			break FOR_LOOP2
 		}
 	}

mempool/mempool.go

@@ -401,7 +401,7 @@ func (mem *Mempool) collectTxs(maxTxs int) types.Txs {
 // NOTE: unsafe; Lock/Unlock must be managed by caller
 func (mem *Mempool) Update(height int64, txs types.Txs) error {
 	// First, create a lookup map of txns in new txs.
-	txsMap := make(map[string]struct{})
+	txsMap := make(map[string]struct{}, len(txs))
 	for _, tx := range txs {
 		txsMap[string(tx)] = struct{}{}
 	}

p2p/conn/connection_test.go

@@ -433,7 +433,6 @@ func TestMConnectionReadErrorLongMessage(t *testing.T) {
 	_, err = client.Write(buf.Bytes())
 	assert.Nil(t, err)
 	assert.True(t, expectSend(chOnRcv), "msg just right")
-	assert.False(t, expectSend(chOnErr), "msg just right")
 
 	// send msg thats too long
 	buf = new(bytes.Buffer)
@@ -446,7 +445,6 @@ func TestMConnectionReadErrorLongMessage(t *testing.T) {
 	assert.Nil(t, err)
 	_, err = client.Write(buf.Bytes())
 	assert.NotNil(t, err)
-	assert.False(t, expectSend(chOnRcv), "msg too long")
 	assert.True(t, expectSend(chOnErr), "msg too long")
 }