Merge branch 'master' into ancaz/blockchain_reactor_reorg

docs/tendermint-core/configuration.md

@@ -138,6 +138,12 @@ max_subscriptions_per_client = 5
 # See https://github.com/tendermint/tendermint/issues/3435
 timeout_broadcast_tx_commit = "10s"
 
+# Maximum size of request body, in bytes
+max_body_bytes = {{ .RPC.MaxBodyBytes }}
+
+# Maximum size of request header, in bytes
+max_header_bytes = {{ .RPC.MaxHeaderBytes }}
+
 # The path to a file containing certificate that is used to create the HTTPS server.
 # Migth be either absolute path or path related to tendermint's config directory.
 # If the certificate is signed by a certificate authority,
@@ -323,8 +329,7 @@ namespace = "tendermint"
 
 If `create_empty_blocks` is set to `true` in your config, blocks will be
 created ~ every second (with default consensus parameters). You can regulate
-the delay between blocks by changing the `timeout_commit`. E.g. `timeout_commit
-= "10s"` should result in ~ 10 second blocks.
+the delay between blocks by changing the `timeout_commit`. E.g. `timeout_commit = "10s"` should result in ~ 10 second blocks.
 
 **create_empty_blocks = false**
 
@@ -350,7 +355,7 @@ Tendermint will only create blocks if there are transactions, or after waiting
 ## Consensus timeouts explained
 
 There's a variety of information about timeouts in [Running in
-production](./running-in-production.html)
+production](./running-in-production.md)
 
 You can also find more detailed technical explanation in the spec: [The latest
 gossip on BFT consensus](https://arxiv.org/abs/1807.04938).

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

@@ -115,7 +115,7 @@ little overview what they do.
 - `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).
+  be found [here](https://github.com/tendermint/tendermint/tree/master/abci/client).
 - `blockchain` Provides storage, pool (a group of peers), and reactor
   for both storing and exchanging blocks between peers.
 - `consensus` The heart of Tendermint core, which is the

docs/tendermint-core/rpc.md

@@ -4,4 +4,4 @@ The RPC documentation is hosted here:
 
 - [https://tendermint.com/rpc/](https://tendermint.com/rpc/)
 
-To update the documentation, edit the relevant `godoc` comments in the [rpc/core directory](https://github.com/tendermint/tendermint/tree/develop/rpc/core).
+To update the documentation, edit the relevant `godoc` comments in the [rpc/core directory](https://github.com/tendermint/tendermint/tree/master/rpc/core).

docs/tendermint-core/using-tendermint.md

@@ -20,7 +20,7 @@ Initialize the root directory by running:
 tendermint init
 ```
 
-This will create a new private key (`priv_validator.json`), and a
+This will create a new private key (`priv_validator_key.json`), and a
 genesis file (`genesis.json`) containing the associated public key, in
 `$TMHOME/config`. This is all that's necessary to run a local testnet
 with one validator.
@@ -43,6 +43,11 @@ definition](https://github.com/tendermint/tendermint/blob/master/types/genesis.g
 - `chain_id`: ID of the blockchain. This must be unique for
   every blockchain. If your testnet blockchains do not have unique
   chain IDs, you will have a bad time. The ChainID must be less than 50 symbols.
+- `consensus_params`
+  - `block`
+    - `time_iota_ms`: Minimum time increment between consecutive blocks (in
+      milliseconds). If the block header timestamp is ahead of the system clock,
+      decrease this value.
 - `validators`: List of initial validators. Note this may be overridden entirely by the
   application, and may be left empty to make explicit that the
   application will initialize the validator set with ResponseInitChain.
@@ -63,9 +68,10 @@ definition](https://github.com/tendermint/tendermint/blob/master/types/genesis.g
   "genesis_time": "2018-11-13T18:11:50.277637Z",
   "chain_id": "test-chain-s4ui7D",
   "consensus_params": {
-    "block_size": {
+    "block": {
       "max_bytes": "22020096",
-      "max_gas": "-1"
+      "max_gas": "-1",
+      "time_iota_ms": "1000"
     },
     "evidence": {
       "max_age": "100000"
@@ -308,7 +314,7 @@ write-ahead-log](../tendermint-core/running-in-production.md#mempool-wal)
 ## Tendermint Networks
 
 When `tendermint init` is run, both a `genesis.json` and
-`priv_validator.json` are created in `~/.tendermint/config`. The
+`priv_validator_key.json` are created in `~/.tendermint/config`. The
 `genesis.json` might look like:
 
 ```
@@ -329,7 +335,7 @@ When `tendermint init` is run, both a `genesis.json` and
 }
 ```
 
-And the `priv_validator.json`:
+And the `priv_validator_key.json`:
 
 ```
 {
@@ -348,20 +354,20 @@ And the `priv_validator.json`:
 }
 ```
 
-The `priv_validator.json` actually contains a private key, and should
+The `priv_validator_key.json` actually contains a private key, and should
 thus be kept absolutely secret; for now we work with the plain text.
 Note the `last_` fields, which are used to prevent us from signing
 conflicting messages.
 
 Note also that the `pub_key` (the public key) in the
-`priv_validator.json` is also present in the `genesis.json`.
+`priv_validator_key.json` is also present in the `genesis.json`.
 
 The genesis file contains the list of public keys which may participate
 in the consensus, and their corresponding voting power. Greater than 2/3
 of the voting power must be active (i.e. the corresponding private keys
 must be producing signatures) for the consensus to make progress. In our
 case, the genesis file contains the public key of our
-`priv_validator.json`, so a Tendermint node started with the default
+`priv_validator_key.json`, so a Tendermint node started with the default
 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
@@ -447,16 +453,16 @@ not connected to the other peer.
 
 The easiest way to add new validators is to do it in the `genesis.json`,
 before starting the network. For instance, we could make a new
-`priv_validator.json`, and copy it's `pub_key` into the above genesis.
+`priv_validator_key.json`, and copy it's `pub_key` into the above genesis.
 
-We can generate a new `priv_validator.json` with the command:
+We can generate a new `priv_validator_key.json` with the command:
 
 ```
 tendermint gen_validator
 ```
 
 Now we can update our genesis file. For instance, if the new
-`priv_validator.json` looks like:
+`priv_validator_key.json` looks like:
 
 ```
 {
@@ -504,7 +510,7 @@ then the new `genesis.json` will be:
 ```
 
 Update the `genesis.json` in `~/.tendermint/config`. Copy the genesis
-file and the new `priv_validator.json` to the `~/.tendermint/config` on
+file and the new `priv_validator_key.json` to the `~/.tendermint/config` on
 a new machine.
 
 Now run `tendermint node` on both machines, and use either