changelog and version

tools/tmbench: Move statistics to a seperate file

.circleci/config.yml

@@ -31,8 +31,7 @@ jobs:
           name: binaries
           command: |
             export PATH="$GOBIN:$PATH"
-            make install
-            cd abci && make install
+            make install install_abci
       - persist_to_workspace:
           root: /tmp/workspace
           paths:

.github/CODEOWNERS

@@ -2,3 +2,6 @@
 
 # Everything goes through Bucky, Anton, Alex. For now.
 *       @ebuchman @melekes @xla
+
+# Precious documentation
+/docs/  @zramsay @jolesbi

.gitignore

@@ -14,10 +14,10 @@ test/p2p/data/
 test/logs
 coverage.txt
 docs/_build
-docs/tools
 *.log
 abci-cli
 abci/types/types.pb.go
+docs/node_modules/
 
 scripts/wal2json/wal2json
 scripts/cutWALUntil/cutWALUntil
@@ -27,3 +27,10 @@ scripts/cutWALUntil/cutWALUntil
 
 libs/pubsub/query/fuzz_test/output
 shunit2
+
+*/vendor
+*/.glide
+.terraform
+terraform.tfstate
+terraform.tfstate.backup
+terraform.tfstate.d

CHANGELOG.md

@@ -1,11 +1,76 @@
 # Changelog
 
+## 0.22.4
+
+*July 14th, 2018*
+
+FEATURES:
+- [tools] Merged in from github.com/tendermint/tools
+
+IMPROVEMENTS:
+- [genesis] removed deprecated `app_options` field.
+- [types] Genesis.AppStateJSON -> Genesis.AppState
+
+BUG FIXES:
+- [tools/tm-bench] Various fixes
+- [consensus] Wait for WAL to stop on shutdown
+- [abci] Fix #1891, pending requests cannot hang when abci server dies. Previously a crash in BeginBlock could leave tendermint in broken state.
+
+## 0.22.3
+
+*July 10th, 2018*
+
+IMPROVEMENTS
+- Update dependencies
+    * pin all values in Gopkg.toml to version or commit
+    * update golang/protobuf to v1.1.0
+
+## 0.22.2
+
+*July 10th, 2018*
+
+IMPROVEMENTS
+- More cleanup post repo merge!
+- [docs] Include `ecosystem.json` and `tendermint-bft.md` from deprecated `aib-data` repository.
+- [config] Add `instrumentation.max_open_connections`, which limits the number
+  of requests in flight to Prometheus server (if enabled). Default: 3.
+
+
+BUG FIXES
+- [rpc] Allow unquoted integers in requests
+    - NOTE: this is only for URI requests. JSONRPC requests and all responses
+      will use quoted integers (the proto3 JSON standard).
+- [consensus] Fix halt on shutdown
+
+## 0.22.1
+
+*July 5th, 2018*
+
+IMPROVEMENTS
+
+* Cleanup post repo-merge.
+* [docs] Various improvements.
+
+BUG FIXES
+
+* [state] Return error when EndBlock returns a 0-power validator that isn't
+  already in the validator set.
+* [consensus] Shut down WAL properly.
+
+
 ## 0.22.0
 
 *July 2nd, 2018*
 
 BREAKING CHANGES:
-- [config] Rename `skip_upnp` to `upnp`, and turn it off by default.
+- [config]
+    * Remove `max_block_size_txs` and `max_block_size_bytes` in favor of
+        consensus params from the genesis file.
+    * Rename `skip_upnp` to `upnp`, and turn it off by default.
+    * Change `max_packet_msg_size` back to `max_packet_msg_payload_size`
+- [rpc]
+    * All integers are encoded as strings (part of the update for Amino v0.10.1)
+    * `syncing` is now called `catching_up`
 - [types] Update Amino to v0.10.1
     * Amino is now fully proto3 compatible for the basic types
     * JSON-encoded types now use the type name instead of the prefix bytes
@@ -16,7 +81,6 @@ BREAKING CHANGES:
     * `tmlibs/merkle` -> `crypto/merkle`. Uses SHA256 instead of RIPEMD160
 - [tmlibs] Update to v0.9.0 and merge into `libs`
     * remove `merkle` package (moved to `crypto/merkle`)
-- [rpc] `syncing` is now called `catching_up`.
 
 FEATURES
 - [cmd] Added metrics (served under `/metrics` using a Prometheus client;

Gopkg.lock

@@ -11,10 +11,9 @@
   branch = "master"
   name = "github.com/btcsuite/btcd"
   packages = ["btcec"]
-  revision = "86fed781132ac890ee03e906e4ecd5d6fa180c64"
+  revision = "fdfc19097e7ac6b57035062056f5b7b4638b8898"
 
 [[projects]]
-  branch = "master"
   name = "github.com/btcsuite/btcutil"
   packages = [
     "base58",
@@ -29,16 +28,15 @@
   version = "v1.1.0"
 
 [[projects]]
-  branch = "master"
   name = "github.com/ebuchman/fail-test"
   packages = ["."]
   revision = "95f809107225be108efcf10a3509e4ea6ceef3c4"
 
 [[projects]]
-  branch = "master"
   name = "github.com/fortytw2/leaktest"
   packages = ["."]
-  revision = "b008db64ef8daabb22ff6daa557f33b41d8f6ccd"
+  revision = "a5ef70473c97b71626b9abeda80ee92ba2a7de9e"
+  version = "v1.2.0"
 
 [[projects]]
   name = "github.com/fsnotify/fsnotify"
@@ -185,8 +183,7 @@
     "prometheus",
     "prometheus/promhttp"
   ]
-  revision = "c5b7fccd204277076155f10851dad72b76a49317"
-  version = "v0.8.0"
+  revision = "ae27198cdd90bf12cd134ad79d1366a6cf49f632"
 
 [[projects]]
   branch = "master"
@@ -213,10 +210,9 @@
     "nfs",
     "xfs"
   ]
-  revision = "40f013a808ec4fa79def444a1a56de4d1727efcb"
+  revision = "ae68e2d4c00fed4943b5f6698d504a5fe083da8a"
 
 [[projects]]
-  branch = "master"
   name = "github.com/rcrowley/go-metrics"
   packages = ["."]
   revision = "e2704e165165ec55d062f5919b4b29494e9fa790"
@@ -266,8 +262,8 @@
     "assert",
     "require"
   ]
-  revision = "f35b8ab0b5a2cef36673838d662e249dd9c94686"
-  version = "v1.2.2"
+  revision = "12b6f73e6084dad08a7c6e575284b177ecafbc71"
+  version = "v1.2.1"
 
 [[projects]]
   branch = "master"
@@ -286,7 +282,7 @@
     "leveldb/table",
     "leveldb/util"
   ]
-  revision = "e2150783cd35f5b607daca48afd8c57ec54cc995"
+  revision = "c4c61651e9e37fa117f53c5a906d3b63090d8445"
 
 [[projects]]
   branch = "master"
@@ -326,7 +322,6 @@
   revision = "a49355c7e3f8fe157a85be2f77e6e269a0f89602"
 
 [[projects]]
-  branch = "master"
   name = "golang.org/x/net"
   packages = [
     "context",
@@ -338,7 +333,7 @@
     "netutil",
     "trace"
   ]
-  revision = "4cb1c02c05b0e749b0365f61ae859a8e0cfceed9"
+  revision = "292b43bbf7cb8d35ddf40f8d5100ef3837cced3f"
 
 [[projects]]
   branch = "master"
@@ -347,7 +342,7 @@
     "cpu",
     "unix"
   ]
-  revision = "7138fd3d9dc8335c567ca206f4333fb75eb05d56"
+  revision = "1b2967e3c290b7c545b3db0deeda16e9be4f98a2"
 
 [[projects]]
   name = "golang.org/x/text"
@@ -414,6 +409,6 @@
 [solve-meta]
   analyzer-name = "dep"
   analyzer-version = 1
-  inputs-digest = "71753a9d4ece4252d23941f116f5ff66c0d5da730a099e5a9867491d223ed93b"
+  inputs-digest = "b0718135d5ade0a75c6b8fe703f70eb9d8064ba871ec31abd9ace3c4ab944100"
   solver-name = "gps-cdcl"
   solver-version = 1

Gopkg.toml

@@ -23,16 +23,12 @@
 #   non-go = false
 #   go-tests = true
 #   unused-packages = true
+#
+###########################################################
+# NOTE: All packages should be pinned to specific versions.
+# Packages without releases must pin to a commit.
 
 
-[[constraint]]
-  name = "github.com/ebuchman/fail-test"
-  branch = "master"
-
-[[constraint]]
-  name = "github.com/fortytw2/leaktest"
-  branch = "master"
-
 [[constraint]]
   name = "github.com/go-kit/kit"
   version = "=0.6.0"
@@ -47,16 +43,12 @@
 
 [[constraint]]
   name = "github.com/gorilla/websocket"
-  version = "~1.2.0"
+  version = "=1.2.0"
 
 [[constraint]]
   name = "github.com/pkg/errors"
   version = "=0.8.0"
 
-[[constraint]]
-  name = "github.com/rcrowley/go-metrics"
-  branch = "master"
-
 [[constraint]]
   name = "github.com/spf13/cobra"
   version = "=0.0.1"
@@ -67,29 +59,60 @@
 
 [[constraint]]
   name = "github.com/stretchr/testify"
-  version = "~1.2.1"
+  version = "=1.2.1"
 
 [[constraint]]
   name = "github.com/tendermint/go-amino"
-  version = "~0.10.1"
+  version = "=0.10.1"
 
 [[constraint]]
   name = "google.golang.org/grpc"
-  version = "~1.11.3"
+  version = "=1.11.3"
 
-# this got updated and broke, so locked to an old working commit ...
+[[constraint]]
+  name = "github.com/fortytw2/leaktest"
+  version = "=1.2.0"
+
+###################################
+## Some repos dont have releases.
+## Pin to revision
+
+## We can remove this one by updating protobuf to v1.1.0
+## but then the grpc tests break with
+#--- FAIL: TestBroadcastTx (0.01s)
+#panic: message/group field common.KVPair:bytes without pointer [recovered]
+#        panic: message/group field common.KVPair:bytes without pointer
+#
+# ...
+#
+# github.com/tendermint/tendermint/rpc/grpc_test.TestBroadcastTx(0xc420a5ab40)
+#         /go/src/github.com/tendermint/tendermint/rpc/grpc/grpc_test.go:29 +0x141
 [[override]]
   name = "google.golang.org/genproto"
   revision = "7fd901a49ba6a7f87732eb344f6e3c5b19d1b200"
 
+[[constraint]]
+  name = "github.com/ebuchman/fail-test"
+  revision = "95f809107225be108efcf10a3509e4ea6ceef3c4"
+
+# last revision used by go-crypto
+[[constraint]]
+  name = "github.com/btcsuite/btcutil"
+  revision = "d4cc87b860166d00d6b5b9e0d3b3d71d6088d4d4"
+
+# Haven't made a release since 2016.
+[[constraint]]
+  name = "github.com/prometheus/client_golang"
+  revision = "ae27198cdd90bf12cd134ad79d1366a6cf49f632"
+
+[[constraint]]
+  name = "github.com/rcrowley/go-metrics"
+  revision = "e2704e165165ec55d062f5919b4b29494e9fa790"
+
+[[constraint]]
+  name = "golang.org/x/net"
+  revision = "292b43bbf7cb8d35ddf40f8d5100ef3837cced3f"
+
 [prune]
   go-tests = true
   unused-packages = true
-
-[[constraint]]
-  name = "github.com/prometheus/client_golang"
-  version = "0.8.0"
-
-[[constraint]]
-  branch = "master"
-  name = "golang.org/x/net"

Makefile

@@ -1,7 +1,12 @@
 GOTOOLS = \
+	github.com/mitchellh/gox \
 	github.com/golang/dep/cmd/dep \
-	gopkg.in/alecthomas/gometalinter.v2
+	gopkg.in/alecthomas/gometalinter.v2 \
+	github.com/gogo/protobuf/protoc-gen-gogo \
+	github.com/gogo/protobuf/gogoproto \
+	github.com/square/certstrap
 PACKAGES=$(shell go list ./... | grep -v '/vendor/')
+INCLUDE = -I=. -I=${GOPATH}/src -I=${GOPATH}/src/github.com/gogo/protobuf/protobuf
 BUILD_TAGS?=tendermint
 BUILD_FLAGS = -ldflags "-X github.com/tendermint/tendermint/version.GitCommit=`git rev-parse --short=8 HEAD`"
 
@@ -11,7 +16,7 @@ check: check_tools ensure_deps
 
 
 ########################################
-### Build
+### Build Tendermint
 
 build:
 	CGO_ENABLED=0 go build $(BUILD_FLAGS) -tags '$(BUILD_TAGS)' -o build/tendermint ./cmd/tendermint/
@@ -22,10 +27,29 @@ build_race:
 install:
 	CGO_ENABLED=0 go install $(BUILD_FLAGS) -tags '$(BUILD_TAGS)' ./cmd/tendermint
 
+########################################
+### Build ABCI
+
+protoc_abci:
+	## If you get the following error,
+	## "error while loading shared libraries: libprotobuf.so.14: cannot open shared object file: No such file or directory"
+	## See https://stackoverflow.com/a/25518702
+	protoc $(INCLUDE) --gogo_out=plugins=grpc:. abci/types/*.proto
+	@echo "--> adding nolint declarations to protobuf generated files"
+	@awk '/package abci/types/ { print "//nolint: gas"; print; next }1' abci/types/types.pb.go > abci/types/types.pb.go.new
+	@mv abci/types/types.pb.go.new abci/types/types.pb.go
+
+build_abci:
+	@go build -i ./abci/cmd/...
+
+install_abci:
+	@go install ./abci/cmd/...
+
 ########################################
 ### Distribution
 
 # dist builds binaries for all platforms and packages them for distribution
+# TODO add abci to these scripts
 dist:
 	@BUILD_TAGS='$(BUILD_TAGS)' sh -c "'$(CURDIR)/scripts/dist.sh'"
 
@@ -59,6 +83,17 @@ ensure_deps:
 	@echo "--> Running dep"
 	@dep ensure
 
+#For ABCI and libs
+get_protoc:
+	@# https://github.com/google/protobuf/releases
+	curl -L https://github.com/google/protobuf/releases/download/v3.4.1/protobuf-cpp-3.4.1.tar.gz | tar xvz && \
+		cd protobuf-3.4.1 && \
+		DIST_LANG=cpp ./configure && \
+		make && \
+		make install && \
+		cd .. && \
+		rm -rf protobuf-3.4.1
+
 draw_deps:
 	@# requires brew install graphviz or apt-get install graphviz
 	go get github.com/RobotsAndPencils/goviz
@@ -70,6 +105,37 @@ get_deps_bin_size:
 	@find $(WORK) -type f -name "*.a" | xargs -I{} du -hxs "{}" | sort -rh | sed -e s:${WORK}/::g > deps_bin_size.log
 	@echo "Results can be found here: $(CURDIR)/deps_bin_size.log"
 
+########################################
+### Libs
+
+protoc_libs:
+	## If you get the following error,
+	## "error while loading shared libraries: libprotobuf.so.14: cannot open shared object file: No such file or directory"
+	## See https://stackoverflow.com/a/25518702
+	protoc $(INCLUDE) --go_out=plugins=grpc:. libs/common/*.proto
+	@echo "--> adding nolint declarations to protobuf generated files"
+	@awk '/package libs/common/ { print "//nolint: gas"; print; next }1' libs/common/types.pb.go > libs/common/types.pb.go.new
+	@mv libs/common/types.pb.go.new libs/common/types.pb.go
+
+gen_certs: clean_certs
+	## Generating certificates for TLS testing...
+	certstrap init --common-name "tendermint.com" --passphrase ""
+	certstrap request-cert -ip "::" --passphrase ""
+	certstrap sign "::" --CA "tendermint.com" --passphrase ""
+	mv out/::.crt out/::.key db/remotedb
+
+clean_certs:
+	## Cleaning TLS testing certificates...
+	rm -rf out
+	rm -f db/remotedb/::.crt db/remotedb/::.key
+
+test_libs: gen_certs
+	GOCACHE=off go test -tags gcc $(shell go list ./... | grep -v vendor)
+	make clean_certs
+
+grpc_dbserver:
+	protoc -I db/remotedb/proto/ db/remotedb/proto/defs.proto --go_out=plugins=grpc:db/remotedb/proto
+
 ########################################
 ### Testing
 
@@ -87,6 +153,15 @@ test_apps:
 	# requires `abci-cli` and `tendermint` binaries installed
 	bash test/app/test.sh
 
+test_abci_apps:
+	bash abci/tests/test_app/test.sh
+
+test_abci_cli:
+	# test the cli against the examples in the tutorial at:
+	# ./docs/abci-cli.md
+	# if test fails, update the docs ^
+	@ bash abci/tests/test_cli/test.sh
+
 test_persistence:
 	# run the persistence tests using bash
 	# requires `abci-cli` installed
@@ -105,17 +180,16 @@ test_p2p:
 	# requires 'tester' the image from above
 	bash test/p2p/test.sh tester
 
-need_abci:
-	bash scripts/install_abci_apps.sh
-
 test_integrations:
 	make build_docker_test_image
 	make get_tools
 	make get_vendor_deps
 	make install
-	make need_abci
 	make test_cover
 	make test_apps
+	make test_abci_apps
+	make test_abci_cli
+	make test_libs
 	make test_persistence
 	make test_p2p
 
@@ -233,4 +307,4 @@ build-slate:
 # To avoid unintended conflicts with file names, always add to .PHONY
 # unless there is a reason not to.
 # https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html
-.PHONY: check build build_race dist install check_tools get_tools update_tools get_vendor_deps draw_deps test_cover test_apps test_persistence test_p2p test test_race test_integrations test_release test100 vagrant_test fmt build-linux localnet-start localnet-stop build-docker build-docker-localnode sentry-start sentry-config sentry-stop build-slate
+.PHONY: check build build_race build_abci dist install install_abci check_tools get_tools update_tools get_vendor_deps draw_deps get_protoc protoc_abci protoc_libs gen_certs clean_certs grpc_dbserver test_cover test_apps test_persistence test_p2p test test_race test_integrations test_release test100 vagrant_test fmt build-linux localnet-start localnet-stop build-docker build-docker-localnode sentry-start sentry-config sentry-stop build-slate

abci/Makefile

@@ -1,174 +0,0 @@
-GOTOOLS = \
-	github.com/mitchellh/gox \
-	github.com/golang/dep/cmd/dep \
-	gopkg.in/alecthomas/gometalinter.v2 \
-	github.com/gogo/protobuf/protoc-gen-gogo \
-	github.com/gogo/protobuf/gogoproto
-GOTOOLS_CHECK = gox dep gometalinter.v2 protoc protoc-gen-gogo
-PACKAGES=$(shell go list ./... | grep -v '/vendor/')
-INCLUDE = -I=. -I=${GOPATH}/src -I=${GOPATH}/src/github.com/gogo/protobuf/protobuf
-
-all: check get_vendor_deps protoc build test install metalinter
-
-check: check_tools
-
-
-########################################
-###  Build
-
-protoc:
-	## If you get the following error,
-	## "error while loading shared libraries: libprotobuf.so.14: cannot open shared object file: No such file or directory"
-	## See https://stackoverflow.com/a/25518702
-	protoc $(INCLUDE) --gogo_out=plugins=grpc:. types/*.proto
-	@echo "--> adding nolint declarations to protobuf generated files"
-	@awk '/package types/ { print "//nolint: gas"; print; next }1' types/types.pb.go > types/types.pb.go.new
-	@mv types/types.pb.go.new types/types.pb.go
-
-build:
-	@go build -i ./cmd/...
-
-dist:
-	@bash scripts/dist.sh
-	@bash scripts/publish.sh
-
-install:
-	@go install ./cmd/...
-
-
-########################################
-### Tools & dependencies
-
-check_tools:
-	@# https://stackoverflow.com/a/25668869
-	@echo "Found tools: $(foreach tool,$(GOTOOLS_CHECK),\
-        $(if $(shell which $(tool)),$(tool),$(error "No $(tool) in PATH")))"
-
-get_tools:
-	@echo "--> Installing tools"
-	go get -u -v $(GOTOOLS)
-	@gometalinter.v2 --install
-
-get_protoc:
-	@# https://github.com/google/protobuf/releases
-	curl -L https://github.com/google/protobuf/releases/download/v3.4.1/protobuf-cpp-3.4.1.tar.gz | tar xvz && \
-		cd protobuf-3.4.1 && \
-		DIST_LANG=cpp ./configure && \
-		make && \
-		make install && \
-		cd .. && \
-		rm -rf protobuf-3.4.1
-
-update_tools:
-	@echo "--> Updating tools"
-	@go get -u $(GOTOOLS)
-
-get_vendor_deps:
-	@rm -rf vendor/
-	@echo "--> Running dep ensure"
-	@dep ensure
-
-
-########################################
-### Testing
-
-test:
-	@find . -path ./vendor -prune -o -name "*.sock" -exec rm {} \;
-	@echo "==> Running go test"
-	@go test $(PACKAGES)
-
-test_race:
-	@find . -path ./vendor -prune -o -name "*.sock" -exec rm {} \;
-	@echo "==> Running go test --race"
-	@go test -v -race $(PACKAGES)
-
-### three tests tested by Jenkins
-test_cover:
-	@ bash tests/test_cover.sh
-
-test_apps:
-	# test the counter using a go test script
-	@ bash tests/test_app/test.sh
-
-test_cli:
-	# test the cli against the examples in the tutorial at:
-	# http://tendermint.readthedocs.io/projects/tools/en/master/abci-cli.html
-	#
-	# XXX: if this test fails, fix it and update the docs at:
-	# https://github.com/tendermint/tendermint/blob/develop/docs/abci-cli.rst
-	@ bash tests/test_cli/test.sh
-
-########################################
-### Formatting, linting, and vetting
-
-fmt:
-	@go fmt ./...
-
-metalinter:
-	@echo "==> Running linter"
-	gometalinter.v2 --vendor --deadline=600s --disable-all  \
-		--enable=maligned \
-		--enable=deadcode \
-		--enable=goconst \
-		--enable=goimports \
-		--enable=gosimple \
-		--enable=ineffassign \
-		--enable=megacheck \
-		--enable=misspell \
-		--enable=staticcheck \
-		--enable=safesql \
-		--enable=structcheck \
-		--enable=unconvert \
-		--enable=unused \
-		--enable=varcheck \
-		--enable=vetshadow \
-		./...
-		#--enable=gas \
-		#--enable=dupl \
-		#--enable=errcheck \
-		#--enable=gocyclo \
-		#--enable=golint \ <== comments on anything exported
-		#--enable=gotype \
-		#--enable=interfacer \
-		#--enable=unparam \
-		#--enable=vet \
-
-metalinter_all:
-	protoc $(INCLUDE) --lint_out=. types/*.proto
-	gometalinter.v2 --vendor --deadline=600s --enable-all --disable=lll ./...
-
-
-########################################
-### Docker
-
-DEVDOC_SAVE = docker commit `docker ps -a -n 1 -q` devdoc:local
-
-docker_build:
-	docker build -t "tendermint/abci-dev" -f Dockerfile.develop .
-
-docker_run:
-	docker run -it -v "$(CURDIR):/go/src/github.com/tendermint/abci" -w "/go/src/github.com/tendermint/abci" "tendermint/abci-dev" /bin/bash
-
-docker_run_rm:
-	docker run -it --rm -v "$(CURDIR):/go/src/github.com/tendermint/abci" -w "/go/src/github.com/tendermint/abci" "tendermint/abci-dev" /bin/bash
-
-devdoc_init:
-	docker run -it -v "$(CURDIR):/go/src/github.com/tendermint/abci" -w "/go/src/github.com/tendermint/abci" tendermint/devdoc echo
-	# TODO make this safer
-	$(call DEVDOC_SAVE)
-
-devdoc:
-	docker run -it -v "$(CURDIR):/go/src/github.com/tendermint/abci" -w "/go/src/github.com/tendermint/abci" devdoc:local bash
-
-devdoc_save:
-	# TODO make this safer
-	$(call DEVDOC_SAVE)
-
-devdoc_clean:
-	docker rmi $$(docker images -f "dangling=true" -q)
-
-
-# To avoid unintended conflicts with file names, always add to .PHONY
-# unless there is a reason not to.
-# https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html
-.PHONY: check protoc build dist install check_tools get_tools get_protoc update_tools get_vendor_deps test test_race fmt metalinter metalinter_all docker_build docker_run docker_run_rm devdoc_init devdoc devdoc_save devdoc_clean

abci/client/socket_client.go

@@ -357,6 +357,13 @@ func (cli *socketClient) queueRequest(req *types.Request) *ReqRes {
 }
 
 func (cli *socketClient) flushQueue() {
+	// mark all in-flight messages as resolved (they will get cli.Error())
+	for req := cli.reqSent.Front(); req != nil; req = req.Next() {
+		reqres := req.Value.(*ReqRes)
+		reqres.Done()
+	}
+
+	// mark all queued messages as resolved
 LOOP:
 	for {
 		select {

abci/client/socket_client_test.go

@@ -2,10 +2,17 @@ package abcicli_test
 
 import (
 	"errors"
+	"fmt"
 	"testing"
 	"time"
 
-	"github.com/tendermint/tendermint/abci/client"
+	"github.com/stretchr/testify/assert"
+	"github.com/stretchr/testify/require"
+
+	abcicli "github.com/tendermint/tendermint/abci/client"
+	"github.com/tendermint/tendermint/abci/server"
+	"github.com/tendermint/tendermint/abci/types"
+	cmn "github.com/tendermint/tendermint/libs/common"
 )
 
 func TestSocketClientStopForErrorDeadlock(t *testing.T) {
@@ -26,3 +33,89 @@ func TestSocketClientStopForErrorDeadlock(t *testing.T) {
 		t.Fatalf("Test took too long, potential deadlock still exists")
 	}
 }
+
+func TestProperSyncCalls(t *testing.T) {
+	app := slowApp{}
+
+	s, c := setupClientServer(t, app)
+	defer s.Stop()
+	defer c.Stop()
+
+	resp := make(chan error, 1)
+	go func() {
+		// This is BeginBlockSync unrolled....
+		reqres := c.BeginBlockAsync(types.RequestBeginBlock{})
+		c.FlushSync()
+		res := reqres.Response.GetBeginBlock()
+		require.NotNil(t, res)
+		resp <- c.Error()
+	}()
+
+	select {
+	case <-time.After(time.Second):
+		require.Fail(t, "No response arrived")
+	case err, ok := <-resp:
+		require.True(t, ok, "Must not close channel")
+		assert.NoError(t, err, "This should return success")
+	}
+}
+
+func TestHangingSyncCalls(t *testing.T) {
+	app := slowApp{}
+
+	s, c := setupClientServer(t, app)
+	defer s.Stop()
+	defer c.Stop()
+
+	resp := make(chan error, 1)
+	go func() {
+		// Start BeginBlock and flush it
+		reqres := c.BeginBlockAsync(types.RequestBeginBlock{})
+		flush := c.FlushAsync()
+		// wait 20 ms for all events to travel socket, but
+		// no response yet from server
+		time.Sleep(20 * time.Millisecond)
+		// kill the server, so the connections break
+		s.Stop()
+
+		// wait for the response from BeginBlock
+		reqres.Wait()
+		flush.Wait()
+		resp <- c.Error()
+	}()
+
+	select {
+	case <-time.After(time.Second):
+		require.Fail(t, "No response arrived")
+	case err, ok := <-resp:
+		require.True(t, ok, "Must not close channel")
+		assert.Error(t, err, "We should get EOF error")
+	}
+}
+
+func setupClientServer(t *testing.T, app types.Application) (
+	cmn.Service, abcicli.Client) {
+	// some port between 20k and 30k
+	port := 20000 + cmn.RandInt32()%10000
+	addr := fmt.Sprintf("localhost:%d", port)
+
+	s, err := server.NewServer(addr, "socket", app)
+	require.NoError(t, err)
+	err = s.Start()
+	require.NoError(t, err)
+
+	c := abcicli.NewSocketClient(addr, true)
+	err = c.Start()
+	require.NoError(t, err)
+
+	return s, c
+}
+
+type slowApp struct {
+	types.BaseApplication
+}
+
+func (slowApp) BeginBlock(req types.RequestBeginBlock) types.ResponseBeginBlock {
+	time.Sleep(200 * time.Millisecond)
+	return types.ResponseBeginBlock{}
+}

abci/scripts/abci-builder/Dockerfile

@@ -1,12 +0,0 @@
-FROM golang:1.9.2
-
-RUN apt-get update && apt-get install -y --no-install-recommends \
-		zip \
-	&& rm -rf /var/lib/apt/lists/*
-
-# We want to ensure that release builds never have any cgo dependencies so we
-# switch that off at the highest level.
-ENV CGO_ENABLED 0
-
-RUN mkdir -p $GOPATH/src/github.com/tendermint/abci
-WORKDIR $GOPATH/src/github.com/tendermint/abci

abci/scripts/dist.sh

@@ -1,52 +0,0 @@
-#!/usr/bin/env bash
-set -e
-
-REPO_NAME="abci"
-
-# Get the version from the environment, or try to figure it out.
-if [ -z $VERSION ]; then
-	VERSION=$(awk -F\" '/Version =/ { print $2; exit }' < version/version.go)
-fi
-if [ -z "$VERSION" ]; then
-    echo "Please specify a version."
-    exit 1
-fi
-echo "==> Building version $VERSION..."
-
-# Get the parent directory of where this script is.
-SOURCE="${BASH_SOURCE[0]}"
-while [ -h "$SOURCE" ] ; do SOURCE="$(readlink "$SOURCE")"; done
-DIR="$( cd -P "$( dirname "$SOURCE" )/.." && pwd )"
-
-# Change into that dir because we expect that.
-cd "$DIR"
-
-# Delete the old dir
-echo "==> Removing old directory..."
-rm -rf build/pkg
-mkdir -p build/pkg
-
-
-# Do a hermetic build inside a Docker container.
-docker build -t tendermint/${REPO_NAME}-builder scripts/${REPO_NAME}-builder/
-docker run --rm -e "BUILD_TAGS=$BUILD_TAGS" -v "$(pwd)":/go/src/github.com/tendermint/${REPO_NAME} tendermint/${REPO_NAME}-builder ./scripts/dist_build.sh
-
-# Add $REPO_NAME and $VERSION prefix to package name.
-rm -rf ./build/dist
-mkdir -p ./build/dist
-for FILENAME in $(find ./build/pkg -mindepth 1 -maxdepth 1 -type f); do
-  FILENAME=$(basename "$FILENAME")
-	cp "./build/pkg/${FILENAME}" "./build/dist/${REPO_NAME}_${VERSION}_${FILENAME}"
-done
-
-# Make the checksums.
-pushd ./build/dist
-shasum -a256 ./* > "./${REPO_NAME}_${VERSION}_SHA256SUMS"
-popd
-
-# Done
-echo
-echo "==> Results:"
-ls -hl ./build/dist
-
-exit 0

abci/scripts/dist_build.sh

@@ -1,53 +0,0 @@
-#!/usr/bin/env bash
-set -e
-
-# Get the parent directory of where this script is.
-SOURCE="${BASH_SOURCE[0]}"
-while [ -h "$SOURCE" ] ; do SOURCE="$(readlink "$SOURCE")"; done
-DIR="$( cd -P "$( dirname "$SOURCE" )/.." && pwd )"
-
-# Change into that dir because we expect that.
-cd "$DIR"
-
-# Get the git commit
-GIT_COMMIT="$(git rev-parse --short HEAD)"
-GIT_DESCRIBE="$(git describe --tags --always)"
-GIT_IMPORT="github.com/tendermint/abci/version"
-
-# Determine the arch/os combos we're building for
-XC_ARCH=${XC_ARCH:-"386 amd64 arm"}
-XC_OS=${XC_OS:-"solaris darwin freebsd linux windows"}
-
-# Make sure build tools are available.
-make get_tools
-
-# Get VENDORED dependencies
-make get_vendor_deps
-
-BINARY="abci-cli"
-
-# Build!
-echo "==> Building..."
-"$(which gox)" \
-	-os="${XC_OS}" \
-	-arch="${XC_ARCH}" \
-	-osarch="!darwin/arm !solaris/amd64 !freebsd/amd64" \
-	-ldflags "-X ${GIT_IMPORT}.GitCommit='${GIT_COMMIT}' -X ${GIT_IMPORT}.GitDescribe='${GIT_DESCRIBE}'" \
-	-output "build/pkg/{{.OS}}_{{.Arch}}/$BINARY" \
-	-tags="${BUILD_TAGS}" \
-	github.com/tendermint/abci/cmd/$BINARY
-
-# Zip all the files.
-echo "==> Packaging..."
-for PLATFORM in $(find ./build/pkg -mindepth 1 -maxdepth 1 -type d); do
-	OSARCH=$(basename "${PLATFORM}")
-	echo "--> ${OSARCH}"
-
-	pushd "$PLATFORM" >/dev/null 2>&1
-	zip "../${OSARCH}.zip" ./*
-	popd >/dev/null 2>&1
-done
-
-
-
-exit 0

abci/scripts/publish.sh

@@ -1,7 +0,0 @@
-#! /bin/bash 
-
-# Get the version from the environment, or try to figure it out.
-if [ -z $VERSION ]; then
-	VERSION=$(awk -F\" '/Version =/ { print $2; exit }' < version/version.go)
-fi
-aws s3 cp --recursive build/dist s3://tendermint/binaries/abci/v${VERSION} --acl public-read

abci/specification.rst

@@ -1,294 +0,0 @@
-ABCI Specification
-==================
-
-NOTE: this file has moved to `specification.md <./specification.md>`__. It is left to prevent link breakages for the forseable future. It can safely be deleted in a few months.
-
-Message Types
-~~~~~~~~~~~~~
-
-ABCI requests/responses are defined as simple Protobuf messages in `this
-schema
-file <https://github.com/tendermint/abci/blob/master/types/types.proto>`__.
-TendermintCore sends the requests, and the ABCI application sends the
-responses. Here, we provide an overview of the messages types and how they
-are used by Tendermint. Then we describe each request-response pair as a
-function with arguments and return values, and add some notes on usage.
-
-Some messages (``Echo, Info, InitChain, BeginBlock, EndBlock, Commit``), don't
-return errors because an error would indicate a critical failure in the
-application and there's nothing Tendermint can do.  The problem should be
-addressed and both Tendermint and the application restarted.  All other
-messages (``SetOption, Query, CheckTx, DeliverTx``) return an
-application-specific response ``Code uint32``, where only ``0`` is reserved for
-``OK``.
-
-Some messages (``SetOption, Query, CheckTx, DeliverTx``) return
-non-deterministic data in the form of ``Info`` and ``Log``. The ``Log`` is
-intended for the literal output from the application's logger, while the
-``Info`` is any additional info that should be returned.
-
-The first time a new blockchain is started, Tendermint calls ``InitChain``.
-From then on, the Block Execution Sequence that causes the committed state to
-be updated is as follows:
-
-``BeginBlock, [DeliverTx], EndBlock, Commit``
-
-where one ``DeliverTx`` is called for each transaction in the block.
-Cryptographic commitments to the results of DeliverTx, EndBlock, and
-Commit are included in the header of the next block.
-
-Tendermint opens three connections to the application to handle the different message
-types:
-
-- ``Consensus Connection - InitChain, BeginBlock, DeliverTx, EndBlock, Commit``
-
-- ``Mempool Connection - CheckTx``
-
-- ``Info Connection - Info, SetOption, Query``
-
-The ``Flush`` message is used on every connection, and the ``Echo`` message
-is only used for debugging.
-
-Note that messages may be sent concurrently across all connections -
-a typical application will thus maintain a distinct state for each
-connection. They may be referred to as the ``DeliverTx state``, the
-``CheckTx state``, and the ``Commit state`` respectively.
-
-See below for more details on the message types and how they are used.
-
-Echo
-^^^^
-
--  **Arguments**:
-
-   -  ``Message (string)``: A string to echo back
-
--  **Returns**:
-
-   -  ``Message (string)``: The input string
-
--  **Usage**:
-
-   -  Echo a string to test an abci client/server implementation
-
-Flush
-^^^^^
-
--  **Usage**:
-
-   -  Signals that messages queued on the client should be flushed to
-      the server. It is called periodically by the client implementation
-      to ensure asynchronous requests are actually sent, and is called
-      immediately to make a synchronous request, which returns when the
-      Flush response comes back.
-
-Info
-^^^^
-
--  **Arguments**:
-
-   -  ``Version (string)``: The Tendermint version
-
--  **Returns**:
-
-   -  ``Data (string)``: Some arbitrary information
-   -  ``Version (Version)``: Version information
-   -  ``LastBlockHeight (int64)``: Latest block for which the app has
-      called Commit
-   -  ``LastBlockAppHash ([]byte)``: Latest result of Commit
-
--  **Usage**:
-
-   - Return information about the application state.
-   - Used to sync Tendermint with the application during a handshake that
-     happens on startup.
-   - Tendermint expects ``LastBlockAppHash`` and ``LastBlockHeight`` to be
-     updated during ``Commit``, ensuring that ``Commit`` is never called twice
-     for the same block height.
-
-SetOption
-^^^^^^^^^
-
--  **Arguments**:
-
-   -  ``Key (string)``: Key to set
-   -  ``Value (string)``: Value to set for key
-
--  **Returns**:
-
-   -  ``Code (uint32)``: Response code
-   -  ``Log (string)``: The output of the application's logger. May be non-deterministic.
-   -  ``Info (string)``: Additional information. May be non-deterministic.
-
--  **Usage**:
-
-   - Set non-consensus critical application specific options.
-   - e.g. Key="min-fee", Value="100fermion" could set the minimum fee required for CheckTx
-     (but not DeliverTx - that would be consensus critical).
-
-InitChain
-^^^^^^^^^
-
--  **Arguments**:
-
-   -  ``Validators ([]Validator)``: Initial genesis validators
-   -  ``AppStateBytes ([]byte)``: Serialized initial application state
-
--  **Usage**:
-
-   - Called once upon genesis.
-
-Query
-^^^^^
-
--  **Arguments**:
-
-   -  ``Data ([]byte)``: Raw query bytes. Can be used with or in lieu of
-      Path.
-   -  ``Path (string)``: Path of request, like an HTTP GET path. Can be
-      used with or in liue of Data.
-   -  Apps MUST interpret '/store' as a query by key on the underlying
-      store. The key SHOULD be specified in the Data field.
-   -  Apps SHOULD allow queries over specific types like '/accounts/...'
-      or '/votes/...'
-   -  ``Height (int64)``: The block height for which you want the query
-      (default=0 returns data for the latest committed block). Note that
-      this is the height of the block containing the application's
-      Merkle root hash, which represents the state as it was after
-      committing the block at Height-1
-   -  ``Prove (bool)``: Return Merkle proof with response if possible
-
--  **Returns**:
-
-   -  ``Code (uint32)``: Response code.
-   -  ``Log (string)``: The output of the application's logger. May be non-deterministic.
-   -  ``Info (string)``: Additional information. May be non-deterministic.
-   -  ``Index (int64)``: The index of the key in the tree.
-   -  ``Key ([]byte)``: The key of the matching data.
-   -  ``Value ([]byte)``: The value of the matching data.
-   -  ``Proof ([]byte)``: Proof for the data, if requested.
-   -  ``Height (int64)``: The block height from which data was derived.
-      Note that this is the height of the block containing the
-      application's Merkle root hash, which represents the state as it
-      was after committing the block at Height-1
-
--  **Usage**:
-
-   - Query for data from the application at current or past height.
-   - Optionally return Merkle proof.
-
-BeginBlock
-^^^^^^^^^^
-
--  **Arguments**:
-
-   -  ``Hash ([]byte)``: The block's hash. This can be derived from the
-      block header.
-   -  ``Header (struct{})``: The block header
-   -  ``AbsentValidators ([]int32)``: List of indices of validators not
-      included in the LastCommit
-   -  ``ByzantineValidators ([]Evidence)``: List of evidence of
-      validators that acted maliciously
-
--  **Usage**:
-
-   - Signals the beginning of a new block. Called prior to any DeliverTxs.
-   - The header is expected to at least contain the Height.
-   - The ``AbsentValidators`` and ``ByzantineValidators`` can be used to
-     determine rewards and punishments for the validators.
-
-CheckTx
-^^^^^^^
-
--  **Arguments**:
-
-   -  ``Tx ([]byte)``: The request transaction bytes
-
--  **Returns**:
-
-   -  ``Code (uint32)``: Response code
-   -  ``Data ([]byte)``: Result bytes, if any.
-   -  ``Log (string)``: The output of the application's logger. May be non-deterministic.
-   -  ``Info (string)``: Additional information. May be non-deterministic.
-   -  ``GasWanted (int64)``: Amount of gas request for transaction.
-   -  ``GasUsed (int64)``: Amount of gas consumed by transaction.
-   -  ``Tags ([]cmn.KVPair)``: Key-Value tags for filtering and indexing transactions (eg. by account).
-   -  ``Fee (cmn.KI64Pair)``: Fee paid for the transaction.
-
--  **Usage**: Validate a mempool transaction, prior to broadcasting or
-   proposing. CheckTx should perform stateful but light-weight checks
-   of the validity of the transaction (like checking signatures and account balances),
-   but need not execute in full (like running a smart contract).
-
-   Tendermint runs CheckTx and DeliverTx concurrently with eachother,
-   though on distinct ABCI connections - the mempool connection and the consensus
-   connection, respectively.
-
-   The application should maintain a separate state to support CheckTx.
-   This state can be reset to the latest committed state during ``Commit``,
-   where Tendermint ensures the mempool is locked and not sending new ``CheckTx``.
-   After ``Commit``, the mempool will rerun CheckTx on all remaining
-   transactions, throwing out any that are no longer valid.
-
-   Keys and values in Tags must be UTF-8 encoded strings (e.g. "account.owner": "Bob", "balance": "100.0", "date": "2018-01-02")
-
-
-DeliverTx
-^^^^^^^^^
-
--  **Arguments**:
-
-   -  ``Tx ([]byte)``: The request transaction bytes.
-
--  **Returns**:
-
-   -  ``Code (uint32)``: Response code.
-   -  ``Data ([]byte)``: Result bytes, if any.
-   -  ``Log (string)``: The output of the application's logger. May be non-deterministic.
-   -  ``Info (string)``: Additional information. May be non-deterministic.
-   -  ``GasWanted (int64)``: Amount of gas requested for transaction.
-   -  ``GasUsed (int64)``: Amount of gas consumed by transaction.
-   -  ``Tags ([]cmn.KVPair)``: Key-Value tags for filtering and indexing transactions (eg. by account).
-   -  ``Fee (cmn.KI64Pair)``: Fee paid for the transaction.
-
--  **Usage**:
-
-   - Deliver a transaction to be executed in full by the application. If the transaction is valid,
-     returns CodeType.OK.
-   - Keys and values in Tags must be UTF-8 encoded strings (e.g. "account.owner": "Bob", "balance": "100.0", "time": "2018-01-02T12:30:00Z")
-
-EndBlock
-^^^^^^^^
-
--  **Arguments**:
-
-   -  ``Height (int64)``: Height of the block just executed.
-
--  **Returns**:
-
-   -  ``ValidatorUpdates ([]Validator)``: Changes to validator set (set
-      voting power to 0 to remove).
-   -  ``ConsensusParamUpdates (ConsensusParams)``: Changes to
-      consensus-critical time, size, and other parameters.
-
--  **Usage**:
-
-   - Signals the end of a block.
-   - Called prior to each Commit, after all transactions.
-   - Validator set and consensus params are updated with the result.
-   - Validator pubkeys are expected to be go-wire encoded.
-
-Commit
-^^^^^^
-
--  **Returns**:
-
-   -  ``Data ([]byte)``: The Merkle root hash
-
--  **Usage**:
-
-   - Persist the application state.
-   - Return a Merkle root hash of the application state.
-   - It's critical that all application instances return the same hash. If not,
-     they will not be able to agree on the next block, because the hash is
-     included in the next block!

abci/tests/test_cover.sh

@@ -1,13 +0,0 @@
-#!/usr/bin/env bash
-
-set -e
-echo "" > coverage.txt
-
-echo "==> Running unit tests"
-for d in $(go list ./... | grep -v vendor); do
-    go test -race -coverprofile=profile.out -covermode=atomic "$d"
-    if [ -f profile.out ]; then
-        cat profile.out >> coverage.txt
-        rm profile.out
-    fi
-done

blockchain/reactor.go

@@ -5,12 +5,13 @@ import (
 	"reflect"
 	"time"
 
-	"github.com/tendermint/go-amino"
+	amino "github.com/tendermint/go-amino"
+
+	cmn "github.com/tendermint/tendermint/libs/common"
+	"github.com/tendermint/tendermint/libs/log"
 	"github.com/tendermint/tendermint/p2p"
 	sm "github.com/tendermint/tendermint/state"
 	"github.com/tendermint/tendermint/types"
-	cmn "github.com/tendermint/tendermint/libs/common"
-	"github.com/tendermint/tendermint/libs/log"
 )
 
 const (
@@ -174,7 +175,7 @@ func (bcR *BlockchainReactor) respondToPeer(msg *bcBlockRequestMessage,
 
 // Receive implements Reactor by handling 4 types of messages (look below).
 func (bcR *BlockchainReactor) Receive(chID byte, src p2p.Peer, msgBytes []byte) {
-	msg, err := DecodeMessage(msgBytes)
+	msg, err := decodeMsg(msgBytes)
 	if err != nil {
 		bcR.Logger.Error("Error decoding message", "src", src, "chId", chID, "msg", msg, "err", err, "bytes", msgBytes)
 		bcR.Switch.StopPeerForError(src, err)
@@ -342,17 +343,11 @@ func RegisterBlockchainMessages(cdc *amino.Codec) {
 	cdc.RegisterConcrete(&bcStatusRequestMessage{}, "tendermint/mempool/StatusRequest", nil)
 }
 
-// DecodeMessage decodes BlockchainMessage.
-// TODO: ensure that bz is completely read.
-func DecodeMessage(bz []byte) (msg BlockchainMessage, err error) {
+func decodeMsg(bz []byte) (msg BlockchainMessage, err error) {
 	if len(bz) > maxMsgSize {
-		return msg, fmt.Errorf("Msg exceeds max size (%d > %d)",
-			len(bz), maxMsgSize)
+		return msg, fmt.Errorf("Msg exceeds max size (%d > %d)", len(bz), maxMsgSize)
 	}
 	err = cdc.UnmarshalBinaryBare(bz, &msg)
-	if err != nil {
-		err = cmn.ErrorWrap(err, "DecodeMessage() had bytes left over")
-	}
 	return
 }
 

config/config.go

@@ -606,6 +606,12 @@ type InstrumentationConfig struct {
 
 	// Address to listen for Prometheus collector(s) connections.
 	PrometheusListenAddr string `mapstructure:"prometheus_listen_addr"`
+
+	// Maximum number of simultaneous connections.
+	// If you want to accept more significant number than the default, make sure
+	// you increase your OS limits.
+	// 0 - unlimited.
+	MaxOpenConnections int `mapstructure:"max_open_connections"`
 }
 
 // DefaultInstrumentationConfig returns a default configuration for metrics
@@ -614,6 +620,7 @@ func DefaultInstrumentationConfig() *InstrumentationConfig {
 	return &InstrumentationConfig{
 		Prometheus:           false,
 		PrometheusListenAddr: ":26660",
+		MaxOpenConnections:   3,
 	}
 }
 

config/toml.go

@@ -262,6 +262,12 @@ prometheus = {{ .Instrumentation.Prometheus }}
 
 # Address to listen for Prometheus collector(s) connections
 prometheus_listen_addr = "{{ .Instrumentation.PrometheusListenAddr }}"
+
+# Maximum number of simultaneous connections.
+# If you want to accept more significant number than the default, make sure
+# you increase your OS limits.
+# 0 - unlimited.
+max_open_connections = {{ .Instrumentation.MaxOpenConnections }}
 `
 
 /****** these are for test settings ***********/

consensus/reactor.go

@@ -9,11 +9,11 @@ import (
 	"github.com/pkg/errors"
 
 	amino "github.com/tendermint/go-amino"
-	cmn "github.com/tendermint/tendermint/libs/common"
-	"github.com/tendermint/tendermint/libs/log"
 
 	cstypes "github.com/tendermint/tendermint/consensus/types"
+	cmn "github.com/tendermint/tendermint/libs/common"
 	tmevents "github.com/tendermint/tendermint/libs/events"
+	"github.com/tendermint/tendermint/libs/log"
 	"github.com/tendermint/tendermint/p2p"
 	sm "github.com/tendermint/tendermint/state"
 	"github.com/tendermint/tendermint/types"
@@ -80,6 +80,9 @@ func (conR *ConsensusReactor) OnStop() {
 	conR.BaseReactor.OnStop()
 	conR.unsubscribeFromBroadcastEvents()
 	conR.conS.Stop()
+	if !conR.FastSync() {
+		conR.conS.Wait()
+	}
 }
 
 // SwitchToConsensus switches from fast_sync mode to consensus mode.
@@ -183,7 +186,7 @@ func (conR *ConsensusReactor) Receive(chID byte, src p2p.Peer, msgBytes []byte)
 		return
 	}
 
-	msg, err := DecodeMessage(msgBytes)
+	msg, err := decodeMsg(msgBytes)
 	if err != nil {
 		conR.Logger.Error("Error decoding message", "src", src, "chId", chID, "msg", msg, "err", err, "bytes", msgBytes)
 		conR.Switch.StopPeerForError(src, err)
@@ -1306,11 +1309,9 @@ func RegisterConsensusMessages(cdc *amino.Codec) {
 	cdc.RegisterConcrete(&ProposalHeartbeatMessage{}, "tendermint/ProposalHeartbeat", nil)
 }
 
-// DecodeMessage decodes the given bytes into a ConsensusMessage.
-func DecodeMessage(bz []byte) (msg ConsensusMessage, err error) {
+func decodeMsg(bz []byte) (msg ConsensusMessage, err error) {
 	if len(bz) > maxMsgSize {
-		return msg, fmt.Errorf("Msg exceeds max size (%d > %d)",
-			len(bz), maxMsgSize)
+		return msg, fmt.Errorf("Msg exceeds max size (%d > %d)", len(bz), maxMsgSize)
 	}
 	err = cdc.UnmarshalBinaryBare(bz, &msg)
 	return

consensus/replay.go

@@ -273,7 +273,7 @@ func (h *Handshaker) ReplayBlocks(state sm.State, appHash []byte, appBlockHeight
 			ChainId:         h.genDoc.ChainID,
 			ConsensusParams: csParams,
 			Validators:      validators,
-			AppStateBytes:   h.genDoc.AppStateJSON,
+			AppStateBytes:   h.genDoc.AppState,
 		}
 		res, err := proxyApp.Consensus().InitChainSync(req)
 		if err != nil {

consensus/state.go

@@ -314,13 +314,8 @@ func (cs *ConsensusState) startRoutines(maxSteps int) {
 
 // OnStop implements cmn.Service. It stops all routines and waits for the WAL to finish.
 func (cs *ConsensusState) OnStop() {
-	cs.BaseService.OnStop()
-
 	cs.evsw.Stop()
-
 	cs.timeoutTicker.Stop()
-
-	cs.wal.Stop()
 }
 
 // Wait waits for the the main routine to return.
@@ -600,6 +595,7 @@ func (cs *ConsensusState) receiveRoutine(maxSteps int) {
 
 			// close wal now that we're done writing to it
 			cs.wal.Stop()
+			cs.wal.Wait()
 
 			close(cs.done)
 			return

crypto/Gopkg.lock

@@ -1,137 +0,0 @@
-# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.
-
-
-[[projects]]
-  branch = "master"
-  name = "github.com/btcsuite/btcd"
-  packages = ["btcec"]
-  revision = "86fed781132ac890ee03e906e4ecd5d6fa180c64"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/btcsuite/btcutil"
-  packages = ["base58"]
-  revision = "d4cc87b860166d00d6b5b9e0d3b3d71d6088d4d4"
-
-[[projects]]
-  name = "github.com/davecgh/go-spew"
-  packages = ["spew"]
-  revision = "346938d642f2ec3594ed81d874461961cd0faa76"
-  version = "v1.1.0"
-
-[[projects]]
-  name = "github.com/go-kit/kit"
-  packages = [
-    "log",
-    "log/level",
-    "log/term"
-  ]
-  revision = "4dc7be5d2d12881735283bcab7352178e190fc71"
-  version = "v0.6.0"
-
-[[projects]]
-  name = "github.com/go-logfmt/logfmt"
-  packages = ["."]
-  revision = "390ab7935ee28ec6b286364bba9b4dd6410cb3d5"
-  version = "v0.3.0"
-
-[[projects]]
-  name = "github.com/go-stack/stack"
-  packages = ["."]
-  revision = "259ab82a6cad3992b4e21ff5cac294ccb06474bc"
-  version = "v1.7.0"
-
-[[projects]]
-  name = "github.com/gogo/protobuf"
-  packages = [
-    "gogoproto",
-    "proto",
-    "protoc-gen-gogo/descriptor"
-  ]
-  revision = "1adfc126b41513cc696b209667c8656ea7aac67c"
-  version = "v1.0.0"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/kr/logfmt"
-  packages = ["."]
-  revision = "b84e30acd515aadc4b783ad4ff83aff3299bdfe0"
-
-[[projects]]
-  name = "github.com/pkg/errors"
-  packages = ["."]
-  revision = "645ef00459ed84a119197bfb8d8205042c6df63d"
-  version = "v0.8.0"
-
-[[projects]]
-  name = "github.com/pmezard/go-difflib"
-  packages = ["difflib"]
-  revision = "792786c7400a136282c1664665ae0a8db921c6c2"
-  version = "v1.0.0"
-
-[[projects]]
-  name = "github.com/stretchr/testify"
-  packages = [
-    "assert",
-    "require"
-  ]
-  revision = "f35b8ab0b5a2cef36673838d662e249dd9c94686"
-  version = "v1.2.2"
-
-[[projects]]
-  branch = "master"
-  name = "github.com/tendermint/ed25519"
-  packages = [
-    ".",
-    "edwards25519",
-    "extra25519"
-  ]
-  revision = "d8387025d2b9d158cf4efb07e7ebf814bcce2057"
-
-[[projects]]
-  name = "github.com/tendermint/go-amino"
-  packages = ["."]
-  revision = "2106ca61d91029c931fd54968c2bb02dc96b1412"
-  version = "0.10.1"
-
-[[projects]]
-  name = "github.com/tendermint/tmlibs"
-  packages = [
-    "common",
-    "log",
-    "test"
-  ]
-  revision = "692f1d86a6e2c0efa698fd1e4541b68c74ffaf38"
-  version = "v0.8.4"
-
-[[projects]]
-  branch = "master"
-  name = "golang.org/x/crypto"
-  packages = [
-    "bcrypt",
-    "blowfish",
-    "chacha20poly1305",
-    "hkdf",
-    "internal/chacha20",
-    "internal/subtle",
-    "nacl/secretbox",
-    "openpgp/armor",
-    "openpgp/errors",
-    "poly1305",
-    "ripemd160",
-    "salsa20/salsa"
-  ]
-  revision = "7f39a6fea4fe9364fb61e1def6a268a51b4f3a06"
-
-[[projects]]
-  branch = "master"
-  name = "golang.org/x/sys"
-  packages = ["cpu"]
-  revision = "ad87a3a340fa7f3bed189293fbfa7a9b7e021ae1"
-
-[solve-meta]
-  analyzer-name = "dep"
-  analyzer-version = 1
-  inputs-digest = "027b22b86396a971d5d5c1d298947f531f39743975d65a22e98601140aa1b1a1"
-  solver-name = "gps-cdcl"
-  solver-version = 1

docs/DOCS_README.md

@@ -0,0 +1,19 @@
+# Documentation Maintenance Overview
+
+The documentation found in this directory is hosted at:
+
+- https://tendermint.com/docs/
+
+and built using [VuePress](https://vuepress.vuejs.org/) from the tendermint website repo:
+
+- https://github.com/tendermint/tendermint.com
+
+which has a [configuration file](https://github.com/tendermint/tendermint.com/blob/develop/docs/.vuepress/config.js) for displaying
+the Table of Contents that lists all the documentation.
+
+The `README.md` in this directory is the landing page for
+website documentation and the following folders are intentionally
+ommitted:
+
+- `architecture/` ==> contains Architecture Design Records
+- `spec/` ==> contains the detailed specification

docs/README.md

@@ -11,18 +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](./install) to get up and running
-quickly. For more details on [using tendermint](./using-tendermint) see that
+Follow the [installation instructions](./introduction/install) to get up and running
+quickly. For more details on [using tendermint](./tendermint-core/using-tendermint) 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](./deploy-testnets). For more information (and to join) about the
-Cosmos Network testnets, see [here](/getting-started/full-node.md).
+section](./networks/deploy-testnets).
 
 ## Application Development
 
 The first step to building application on Tendermint is to [install
-ABCI-CLI](./getting-started) and play with the example applications.
+ABCI-CLI](./app-dev/getting-started) and play with the example applications.

docs/abci-spec.md

@@ -1,324 +0,0 @@
-# ABCI Specification
-
-## Message Types
-
-ABCI requests/responses are defined as simple Protobuf messages in [this
-schema file](https://github.com/tendermint/tendermint/blob/develop/abci/types/types.proto).
-TendermintCore sends the requests, and the ABCI application sends the
-responses. Here, we provide an overview of the messages types and how
-they are used by Tendermint. Then we describe each request-response pair
-as a function with arguments and return values, and add some notes on
-usage.
-
-Some messages (`Echo, Info, InitChain, BeginBlock, EndBlock, Commit`),
-don't return errors because an error would indicate a critical failure
-in the application and there's nothing Tendermint can do. The problem
-should be addressed and both Tendermint and the application restarted.
-All other messages (`SetOption, Query, CheckTx, DeliverTx`) return an
-application-specific response `Code uint32`, where only `0` is reserved
-for `OK`.
-
-Some messages (`SetOption, Query, CheckTx, DeliverTx`) return
-non-deterministic data in the form of `Info` and `Log`. The `Log` is
-intended for the literal output from the application's logger, while the
-`Info` is any additional info that should be returned.
-
-The first time a new blockchain is started, Tendermint calls
-`InitChain`. From then on, the Block Execution Sequence that causes the
-committed state to be updated is as follows:
-
-`BeginBlock, [DeliverTx], EndBlock, Commit`
-
-where one `DeliverTx` is called for each transaction in the block.
-Cryptographic commitments to the results of DeliverTx, EndBlock, and
-Commit are included in the header of the next block.
-
-Tendermint opens three connections to the application to handle the
-different message types:
-
--   `Consensus Connection - InitChain, BeginBlock, DeliverTx, EndBlock, Commit`
--   `Mempool Connection - CheckTx`
--   `Info Connection - Info, SetOption, Query`
-
-The `Flush` message is used on every connection, and the `Echo` message
-is only used for debugging.
-
-Note that messages may be sent concurrently across all connections -a
-typical application will thus maintain a distinct state for each
-connection. They may be referred to as the `DeliverTx state`, the
-`CheckTx state`, and the `Commit state` respectively.
-
-See below for more details on the message types and how they are used.
-
-## Request/Response Messages
-
-### Echo
-
--   **Request**:
-    -   `Message (string)`: A string to echo back
--   **Response**:
-    -   `Message (string)`: The input string
--   **Usage**:
-    -   Echo a string to test an abci client/server implementation
-
-### Flush
-
--   **Usage**:
-    -   Signals that messages queued on the client should be flushed to
-        the server. It is called periodically by the client
-        implementation to ensure asynchronous requests are actually
-        sent, and is called immediately to make a synchronous request,
-        which returns when the Flush response comes back.
-
-### Info
-
--   **Request**:
-    -   `Version (string)`: The Tendermint version
--   **Response**:
-    -   `Data (string)`: Some arbitrary information
-    -   `Version (Version)`: Version information
-    -   `LastBlockHeight (int64)`: Latest block for which the app has
-        called Commit
-    -   `LastBlockAppHash ([]byte)`: Latest result of Commit
--   **Usage**:
-    -   Return information about the application state.
-    -   Used to sync Tendermint with the application during a handshake
-        that happens on startup.
-    -   Tendermint expects `LastBlockAppHash` and `LastBlockHeight` to
-        be updated during `Commit`, ensuring that `Commit` is never
-        called twice for the same block height.
-
-### SetOption
-
--   **Request**:
-    -   `Key (string)`: Key to set
-    -   `Value (string)`: Value to set for key
--   **Response**:
-    -   `Code (uint32)`: Response code
-    -   `Log (string)`: The output of the application's logger. May
-        be non-deterministic.
-    -   `Info (string)`: Additional information. May
-        be non-deterministic.
--   **Usage**:
-    -   Set non-consensus critical application specific options.
-    -   e.g. Key="min-fee", Value="100fermion" could set the minimum fee
-        required for CheckTx (but not DeliverTx - that would be
-        consensus critical).
-
-### InitChain
-
--   **Request**:
-    -   `Validators ([]Validator)`: Initial genesis validators
-    -   `AppStateBytes ([]byte)`: Serialized initial application state
--   **Response**:
-    -   `ConsensusParams (ConsensusParams)`: Initial
-        consensus-critical parameters.
-    -   `Validators ([]Validator)`: Initial validator set.
--   **Usage**:
-    -   Called once upon genesis.
-
-### Query
-
--   **Request**:
-    -   `Data ([]byte)`: Raw query bytes. Can be used with or in lieu
-        of Path.
-    -   `Path (string)`: Path of request, like an HTTP GET path. Can be
-        used with or in liue of Data.
-    -   Apps MUST interpret '/store' as a query by key on the
-        underlying store. The key SHOULD be specified in the Data field.
-    -   Apps SHOULD allow queries over specific types like
-        '/accounts/...' or '/votes/...'
-    -   `Height (int64)`: The block height for which you want the query
-        (default=0 returns data for the latest committed block). Note
-        that this is the height of the block containing the
-        application's Merkle root hash, which represents the state as it
-        was after committing the block at Height-1
-    -   `Prove (bool)`: Return Merkle proof with response if possible
--   **Response**:
-    -   `Code (uint32)`: Response code.
-    -   `Log (string)`: The output of the application's logger. May
-        be non-deterministic.
-    -   `Info (string)`: Additional information. May
-        be non-deterministic.
-    -   `Index (int64)`: The index of the key in the tree.
-    -   `Key ([]byte)`: The key of the matching data.
-    -   `Value ([]byte)`: The value of the matching data.
-    -   `Proof ([]byte)`: Proof for the data, if requested.
-    -   `Height (int64)`: The block height from which data was derived.
-        Note that this is the height of the block containing the
-        application's Merkle root hash, which represents the state as it
-        was after committing the block at Height-1
--   **Usage**:
-    -   Query for data from the application at current or past height.
-    -   Optionally return Merkle proof.
-
-### BeginBlock
-
--   **Request**:
-    -   `Hash ([]byte)`: The block's hash. This can be derived from the
-        block header.
-    -   `Header (struct{})`: The block header
-    -   `Validators ([]SigningValidator)`: List of validators in the current validator
-        set and whether or not they signed a vote in the LastCommit
-    -   `ByzantineValidators ([]Evidence)`: List of evidence of
-        validators that acted maliciously
--   **Response**:
-    -   `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
--   **Usage**:
-    -   Signals the beginning of a new block. Called prior to
-        any DeliverTxs.
-    -   The header is expected to at least contain the Height.
-    -   The `Validators` and `ByzantineValidators` can be used to
-        determine rewards and punishments for the validators.
-
-### CheckTx
-
--   **Request**:
-    -   `Tx ([]byte)`: The request transaction bytes
--   **Response**:
-    -   `Code (uint32)`: Response code
-    -   `Data ([]byte)`: Result bytes, if any.
-    -   `Log (string)`: The output of the application's logger. May
-        be non-deterministic.
-    -   `Info (string)`: Additional information. May
-        be non-deterministic.
-    -   `GasWanted (int64)`: Amount of gas request for transaction.
-    -   `GasUsed (int64)`: Amount of gas consumed by transaction.
-    -   `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
-        transactions (eg. by account).
-    -   `Fee (cmn.KI64Pair)`: Fee paid for the transaction.
--   **Usage**: Validate a mempool transaction, prior to broadcasting
-    or proposing. CheckTx should perform stateful but light-weight
-    checks of the validity of the transaction (like checking signatures
-    and account balances), but need not execute in full (like running a
-    smart contract).
-
-    Tendermint runs CheckTx and DeliverTx concurrently with eachother,
-    though on distinct ABCI connections - the mempool connection and the
-    consensus connection, respectively.
-
-    The application should maintain a separate state to support CheckTx.
-    This state can be reset to the latest committed state during
-    `Commit`, where Tendermint ensures the mempool is locked and not
-    sending new `CheckTx`. After `Commit`, the mempool will rerun
-    CheckTx on all remaining transactions, throwing out any that are no
-    longer valid.
-
-    Keys and values in Tags must be UTF-8 encoded strings (e.g.
-    "account.owner": "Bob", "balance": "100.0", "date": "2018-01-02")
-
-### DeliverTx
-
--   **Request**:
-    -   `Tx ([]byte)`: The request transaction bytes.
--   **Response**:
-    -   `Code (uint32)`: Response code.
-    -   `Data ([]byte)`: Result bytes, if any.
-    -   `Log (string)`: The output of the application's logger. May
-        be non-deterministic.
-    -   `Info (string)`: Additional information. May
-        be non-deterministic.
-    -   `GasWanted (int64)`: Amount of gas requested for transaction.
-    -   `GasUsed (int64)`: Amount of gas consumed by transaction.
-    -   `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
-        transactions (eg. by account).
-    -   `Fee (cmn.KI64Pair)`: Fee paid for the transaction.
--   **Usage**:
-    -   Deliver a transaction to be executed in full by the application.
-        If the transaction is valid, returns CodeType.OK.
-    -   Keys and values in Tags must be UTF-8 encoded strings (e.g.
-        "account.owner": "Bob", "balance": "100.0",
-        "time": "2018-01-02T12:30:00Z")
-
-### EndBlock
-
--   **Request**:
-    -   `Height (int64)`: Height of the block just executed.
--   **Response**:
-    -   `ValidatorUpdates ([]Validator)`: Changes to validator set (set
-        voting power to 0 to remove).
-    -   `ConsensusParamUpdates (ConsensusParams)`: Changes to
-        consensus-critical time, size, and other parameters.
-    -   `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
--   **Usage**:
-    -   Signals the end of a block.
-    -   Called prior to each Commit, after all transactions.
-    -   Validator set and consensus params are updated with the result.
-    -   Validator pubkeys are expected to be go-wire encoded.
-
-### Commit
-
--   **Response**:
-    -   `Data ([]byte)`: The Merkle root hash
--   **Usage**:
-    -   Persist the application state.
-    -   Return a Merkle root hash of the application state.
-    -   It's critical that all application instances return the
-        same hash. If not, they will not be able to agree on the next
-        block, because the hash is included in the next block!
-
-## Data Messages
-
-### Header
-
-- **Fields**:
-    - `ChainID (string)`: ID of the blockchain
-    - `Height (int64)`: Height of the block in the chain
-    - `Time (int64)`: Unix time of the block
-    - `NumTxs (int32)`: Number of transactions in the block
-    - `TotalTxs (int64)`: Total number of transactions in the blockchain until
-      now
-    - `LastBlockHash ([]byte)`: Hash of the previous (parent) block
-    - `ValidatorsHash ([]byte)`: Hash of the validator set for this block
-    - `AppHash ([]byte)`: Data returned by the last call to `Commit` - typically the
-      Merkle root of the application state after executing the previous block's
-      transactions
-    - `Proposer (Validator)`: Original proposer for the block
-- **Usage**:
-    - Provided in RequestBeginBlock
-    - Provides important context about the current state of the blockchain -
-      especially height and time.
-    - Provides the proposer of the current block, for use in proposer-based
-      reward mechanisms.
-
-### Validator
-
-- **Fields**:
-    - `Address ([]byte)`: Address of the validator (hash of the public key)
-    - `PubKey (PubKey)`:  Public key of the validator
-    - `Power (int64)`: Voting power of the validator
-- **Usage**:
-    - Provides all identifying information about the validator
-
-### SigningValidator
-
-- **Fields**:
-    - `Validator (Validator)`: A validator
-    - `SignedLastBlock (bool)`: Indicated whether or not the validator signed
-      the last block
-- **Usage**:
-    - Indicates whether a validator signed the last block, allowing for rewards
-      based on validator availability
-
-### PubKey
-
-- **Fields**:
-    - `Type (string)`: Type of the public key. A simple string like `"ed25519"`.
-      In the future, may indicate a serialization algorithm to parse the `Data`,
-      for instance `"amino"`.
-    - `Data ([]byte)`: Public key data. For a simple public key, it's just the
-      raw bytes. If the `Type` indicates an encoding algorithm, this is the
-      encoded public key.
-- **Usage**:
-    - A generic and extensible typed public key
-
-### Evidence
-
-- **Fields**:
-    - `Type (string)`: Type of the evidence. A hierarchical path like
-      "duplicate/vote".
-    - `Validator (Validator`: The offending validator
-    - `Height (int64)`: Height when the offense was committed
-    - `Time (int64)`: Unix time of the block at height `Height`
-    - `TotalVotingPower (int64)`: Total voting power of the validator set at
-      height `Height`

docs/app-dev/abci-cli.md

@@ -10,41 +10,47 @@ Make sure you [have Go installed](https://golang.org/doc/install).
 
 Next, install the `abci-cli` tool and example applications:
 
-    go get github.com/tendermint/tendermint
+```
+go get github.com/tendermint/tendermint
+```
 
 to get vendored dependencies:
 
-    cd $GOPATH/src/github.com/tendermint/tendermint
-    make get_tools
-    make get_vendor_deps
-    make install_abci
+```
+cd $GOPATH/src/github.com/tendermint/tendermint
+make get_tools
+make get_vendor_deps
+make install_abci
+```
 
 Now run `abci-cli` to see the list of commands:
 
-    Usage:
-      abci-cli [command]
+```
+Usage:
+  abci-cli [command]
 
-    Available Commands:
-      batch       Run a batch of abci commands against an application
-      check_tx    Validate a tx
-      commit      Commit the application state and return the Merkle root hash
-      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
-      echo        Have the application echo a message
-      help        Help about any command
-      info        Get some info about the application
-      query       Query the application state
-      set_option  Set an options on the application
+Available Commands:
+  batch       Run a batch of abci commands against an application
+  check_tx    Validate a tx
+  commit      Commit the application state and return the Merkle root hash
+  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
+  echo        Have the application echo a message
+  help        Help about any command
+  info        Get some info about the application
+  query       Query the application state
+  set_option  Set an options on the application
 
-    Flags:
-          --abci string      socket or grpc (default "socket")
-          --address string   address of application socket (default "tcp://127.0.0.1:26658")
-      -h, --help             help for abci-cli
-      -v, --verbose          print the command and results as if it were a console session
+Flags:
+      --abci string      socket or grpc (default "socket")
+      --address string   address of application socket (default "tcp://127.0.0.1:26658")
+  -h, --help             help for abci-cli
+  -v, --verbose          print the command and results as if it were a console session
 
-    Use "abci-cli [command] --help" for more information about a command.
+Use "abci-cli [command] --help" for more information about a command.
+```
 
 ## KVStore - First Example
 
@@ -63,59 +69,69 @@ Its code can be found
 [here](https://github.com/tendermint/tendermint/blob/develop/abci/cmd/abci-cli/abci-cli.go)
 and looks like:
 
-    func cmdKVStore(cmd *cobra.Command, args []string) error {
-        logger := log.NewTMLogger(log.NewSyncWriter(os.Stdout))
-    
-        // Create the application - in memory or persisted to disk
-        var app types.Application
-        if flagPersist == "" {
-            app = kvstore.NewKVStoreApplication()
-        } else {
-            app = kvstore.NewPersistentKVStoreApplication(flagPersist)
-            app.(*kvstore.PersistentKVStoreApplication).SetLogger(logger.With("module", "kvstore"))
-        }
-    
-        // Start the listener
-        srv, err := server.NewServer(flagAddrD, flagAbci, app)
-        if err != nil {
-            return err
-        }
-        srv.SetLogger(logger.With("module", "abci-server"))
-        if err := srv.Start(); err != nil {
-            return err
-        }
-    
-        // Wait forever
-        cmn.TrapSignal(func() {
-            // Cleanup
-            srv.Stop()
-        })
-        return nil
+```
+func cmdKVStore(cmd *cobra.Command, args []string) error {
+    logger := log.NewTMLogger(log.NewSyncWriter(os.Stdout))
+
+    // Create the application - in memory or persisted to disk
+    var app types.Application
+    if flagPersist == "" {
+        app = kvstore.NewKVStoreApplication()
+    } else {
+        app = kvstore.NewPersistentKVStoreApplication(flagPersist)
+        app.(*kvstore.PersistentKVStoreApplication).SetLogger(logger.With("module", "kvstore"))
     }
 
+    // Start the listener
+    srv, err := server.NewServer(flagAddrD, flagAbci, app)
+    if err != nil {
+        return err
+    }
+    srv.SetLogger(logger.With("module", "abci-server"))
+    if err := srv.Start(); err != nil {
+        return err
+    }
+
+    // Wait forever
+    cmn.TrapSignal(func() {
+        // Cleanup
+        srv.Stop()
+    })
+    return nil
+}
+```
+
 Start by running:
 
-    abci-cli kvstore
+```
+abci-cli kvstore
+```
 
 And in another terminal, run
 
-    abci-cli echo hello
-    abci-cli info
+```
+abci-cli echo hello
+abci-cli info
+```
 
 You'll see something like:
 
-    -> data: hello
-    -> data.hex: 68656C6C6F
+```
+-> data: hello
+-> data.hex: 68656C6C6F
+```
 
 and:
 
-    -> data: {"size":0}
-    -> data.hex: 7B2273697A65223A307D
+```
+-> data: {"size":0}
+-> data.hex: 7B2273697A65223A307D
+```
 
 An ABCI application must provide two things:
 
--   a socket server
--   a handler for ABCI messages
+- a socket server
+- a handler for ABCI messages
 
 When we run the `abci-cli` tool we open a new connection to the
 application's socket server, send the given ABCI message, and wait for a
@@ -144,52 +160,54 @@ speaking ABCI messages to your application.
 
 Try running these commands:
 
-    > echo hello
-    -> code: OK
-    -> data: hello
-    -> data.hex: 0x68656C6C6F
+```
+> echo hello
+-> code: OK
+-> data: hello
+-> data.hex: 0x68656C6C6F
 
-    > info
-    -> code: OK
-    -> data: {"size":0}
-    -> data.hex: 0x7B2273697A65223A307D
+> info
+-> code: OK
+-> data: {"size":0}
+-> data.hex: 0x7B2273697A65223A307D
 
-    > commit
-    -> code: OK
-    -> data.hex: 0x0000000000000000
+> commit
+-> code: OK
+-> data.hex: 0x0000000000000000
 
-    > deliver_tx "abc"
-    -> code: OK
+> deliver_tx "abc"
+-> code: OK
 
-    > info
-    -> code: OK
-    -> data: {"size":1}
-    -> data.hex: 0x7B2273697A65223A317D
+> info
+-> code: OK
+-> data: {"size":1}
+-> data.hex: 0x7B2273697A65223A317D
 
-    > commit
-    -> code: OK
-    -> data.hex: 0x0200000000000000
+> commit
+-> code: OK
+-> data.hex: 0x0200000000000000
 
-    > query "abc"
-    -> code: OK
-    -> log: exists
-    -> height: 0
-    -> value: abc
-    -> value.hex: 616263
+> query "abc"
+-> code: OK
+-> log: exists
+-> height: 0
+-> value: abc
+-> value.hex: 616263
 
-    > deliver_tx "def=xyz"
-    -> code: OK
+> deliver_tx "def=xyz"
+-> code: OK
 
-    > commit
-    -> code: OK
-    -> data.hex: 0x0400000000000000
+> commit
+-> code: OK
+-> data.hex: 0x0400000000000000
 
-    > query "def"
-    -> code: OK
-    -> log: exists
-    -> height: 0
-    -> value: xyz
-    -> value.hex: 78797A
+> query "def"
+-> code: OK
+-> log: exists
+-> height: 0
+-> value: xyz
+-> value.hex: 78797A
+```
 
 Note that if we do `deliver_tx "abc"` it will store `(abc, abc)`, but if
 we do `deliver_tx "abc=efg"` it will store `(abc, efg)`.
@@ -206,29 +224,31 @@ Like the kvstore app, its code can be found
 [here](https://github.com/tendermint/tendermint/blob/master/abci/cmd/abci-cli/abci-cli.go)
 and looks like:
 
-    func cmdCounter(cmd *cobra.Command, args []string) error {
-    
-        app := counter.NewCounterApplication(flagSerial)
-    
-        logger := log.NewTMLogger(log.NewSyncWriter(os.Stdout))
-    
-        // Start the listener
-        srv, err := server.NewServer(flagAddrC, flagAbci, app)
-        if err != nil {
-            return err
-        }
-        srv.SetLogger(logger.With("module", "abci-server"))
-        if err := srv.Start(); err != nil {
-            return err
-        }
-    
-        // Wait forever
-        cmn.TrapSignal(func() {
-            // Cleanup
-            srv.Stop()
-        })
-        return nil
+```
+func cmdCounter(cmd *cobra.Command, args []string) error {
+
+    app := counter.NewCounterApplication(flagSerial)
+
+    logger := log.NewTMLogger(log.NewSyncWriter(os.Stdout))
+
+    // Start the listener
+    srv, err := server.NewServer(flagAddrC, flagAbci, app)
+    if err != nil {
+        return err
     }
+    srv.SetLogger(logger.With("module", "abci-server"))
+    if err := srv.Start(); err != nil {
+        return err
+    }
+
+    // Wait forever
+    cmn.TrapSignal(func() {
+        // Cleanup
+        srv.Stop()
+    })
+    return nil
+}
+```
 
 The counter app doesn't use a Merkle tree, it just counts how many times
 we've sent a transaction, asked for a hash, or committed the state. The
@@ -256,38 +276,42 @@ whose integer is greater than the last committed one.
 Let's kill the console and the kvstore application, and start the
 counter app:
 
-    abci-cli counter
+```
+abci-cli counter
+```
 
 In another window, start the `abci-cli console`:
 
-    > set_option serial on
-    -> code: OK
-    -> log: OK (SetOption doesn't return anything.)
+```
+> set_option serial on
+-> code: OK
+-> log: OK (SetOption doesn't return anything.)
 
-    > check_tx 0x00
-    -> code: OK
+> check_tx 0x00
+-> code: OK
 
-    > check_tx 0xff
-    -> code: OK
+> check_tx 0xff
+-> code: OK
 
-    > deliver_tx 0x00
-    -> code: OK
+> deliver_tx 0x00
+-> code: OK
 
-    > check_tx 0x00
-    -> code: BadNonce
-    -> log: Invalid nonce. Expected >= 1, got 0
+> check_tx 0x00
+-> code: BadNonce
+-> log: Invalid nonce. Expected >= 1, got 0
 
-    > deliver_tx 0x01
-    -> code: OK
+> deliver_tx 0x01
+-> code: OK
 
-    > deliver_tx 0x04
-    -> code: BadNonce
-    -> log: Invalid nonce. Expected 2, got 4
+> deliver_tx 0x04
+-> code: BadNonce
+-> log: Invalid nonce. Expected 2, got 4
 
-    > info
-    -> code: OK
-    -> data: {"hashes":0,"txs":2}
-    -> data.hex: 0x7B22686173686573223A302C22747873223A327D
+> info
+-> code: OK
+-> data: {"hashes":0,"txs":2}
+-> data.hex: 0x7B22686173686573223A302C22747873223A327D
+```
 
 This is a very simple application, but between `counter` and `kvstore`,
 its easy to see how you can build out arbitrary application states on
@@ -304,7 +328,9 @@ example directory](https://github.com/tendermint/tendermint/tree/develop/abci/ex
 
 To run the Node JS version, `cd` to `example/js` and run
 
-    node app.js
+```
+node app.js
+```
 
 (you'll have to kill the other counter application process). In another
 window, run the console and those previous ABCI commands. You should get

docs/app-dev/abci-spec.md

@@ -0,0 +1,325 @@
+# ABCI Specification
+
+## Message Types
+
+ABCI requests/responses are defined as simple Protobuf messages in [this
+schema file](https://github.com/tendermint/tendermint/blob/master/abci/types/types.proto).
+TendermintCore sends the requests, and the ABCI application sends the
+responses. Here, we provide an overview of the messages types and how
+they are used by Tendermint. Then we describe each request-response pair
+as a function with arguments and return values, and add some notes on
+usage.
+
+Some messages (`Echo, Info, InitChain, BeginBlock, EndBlock, Commit`),
+don't return errors because an error would indicate a critical failure
+in the application and there's nothing Tendermint can do. The problem
+should be addressed and both Tendermint and the application restarted.
+All other messages (`SetOption, Query, CheckTx, DeliverTx`) return an
+application-specific response `Code uint32`, where only `0` is reserved
+for `OK`.
+
+Some messages (`SetOption, Query, CheckTx, DeliverTx`) return
+non-deterministic data in the form of `Info` and `Log`. The `Log` is
+intended for the literal output from the application's logger, while the
+`Info` is any additional info that should be returned.
+
+The first time a new blockchain is started, Tendermint calls
+`InitChain`. From then on, the Block Execution Sequence that causes the
+committed state to be updated is as follows:
+
+`BeginBlock, [DeliverTx], EndBlock, Commit`
+
+where one `DeliverTx` is called for each transaction in the block.
+Cryptographic commitments to the results of DeliverTx, EndBlock, and
+Commit are included in the header of the next block.
+
+Tendermint opens three connections to the application to handle the
+different message types:
+
+- `Consensus Connection - InitChain, BeginBlock, DeliverTx, EndBlock, Commit`
+- `Mempool Connection - CheckTx`
+- `Info Connection - Info, SetOption, Query`
+
+The `Flush` message is used on every connection, and the `Echo` message
+is only used for debugging.
+
+Note that messages may be sent concurrently across all connections -a
+typical application will thus maintain a distinct state for each
+connection. They may be referred to as the `DeliverTx state`, the
+`CheckTx state`, and the `Commit state` respectively.
+
+See below for more details on the message types and how they are used.
+
+## Request/Response Messages
+
+### Echo
+
+- **Request**:
+  - `Message (string)`: A string to echo back
+- **Response**:
+  - `Message (string)`: The input string
+- **Usage**:
+  - Echo a string to test an abci client/server implementation
+
+### Flush
+
+- **Usage**:
+  - Signals that messages queued on the client should be flushed to
+    the server. It is called periodically by the client
+    implementation to ensure asynchronous requests are actually
+    sent, and is called immediately to make a synchronous request,
+    which returns when the Flush response comes back.
+
+### Info
+
+- **Request**:
+  - `Version (string)`: The Tendermint version
+- **Response**:
+  - `Data (string)`: Some arbitrary information
+  - `Version (Version)`: Version information
+  - `LastBlockHeight (int64)`: Latest block for which the app has
+    called Commit
+  - `LastBlockAppHash ([]byte)`: Latest result of Commit
+- **Usage**:
+  - Return information about the application state.
+  - Used to sync Tendermint with the application during a handshake
+    that happens on startup.
+  - Tendermint expects `LastBlockAppHash` and `LastBlockHeight` to
+    be updated during `Commit`, ensuring that `Commit` is never
+    called twice for the same block height.
+
+### SetOption
+
+- **Request**:
+  - `Key (string)`: Key to set
+  - `Value (string)`: Value to set for key
+- **Response**:
+  - `Code (uint32)`: Response code
+  - `Log (string)`: The output of the application's logger. May
+    be non-deterministic.
+  - `Info (string)`: Additional information. May
+    be non-deterministic.
+- **Usage**:
+  - Set non-consensus critical application specific options.
+  - e.g. Key="min-fee", Value="100fermion" could set the minimum fee
+    required for CheckTx (but not DeliverTx - that would be
+    consensus critical).
+
+### InitChain
+
+- **Request**:
+  - `Validators ([]Validator)`: Initial genesis validators
+  - `AppStateBytes ([]byte)`: Serialized initial application state
+- **Response**:
+  - `ConsensusParams (ConsensusParams)`: Initial
+    consensus-critical parameters.
+  - `Validators ([]Validator)`: Initial validator set.
+- **Usage**:
+  - Called once upon genesis.
+
+### Query
+
+- **Request**:
+  - `Data ([]byte)`: Raw query bytes. Can be used with or in lieu
+    of Path.
+  - `Path (string)`: Path of request, like an HTTP GET path. Can be
+    used with or in liue of Data.
+  - Apps MUST interpret '/store' as a query by key on the
+    underlying store. The key SHOULD be specified in the Data field.
+  - Apps SHOULD allow queries over specific types like
+    '/accounts/...' or '/votes/...'
+  - `Height (int64)`: The block height for which you want the query
+    (default=0 returns data for the latest committed block). Note
+    that this is the height of the block containing the
+    application's Merkle root hash, which represents the state as it
+    was after committing the block at Height-1
+  - `Prove (bool)`: Return Merkle proof with response if possible
+- **Response**:
+  - `Code (uint32)`: Response code.
+  - `Log (string)`: The output of the application's logger. May
+    be non-deterministic.
+  - `Info (string)`: Additional information. May
+    be non-deterministic.
+  - `Index (int64)`: The index of the key in the tree.
+  - `Key ([]byte)`: The key of the matching data.
+  - `Value ([]byte)`: The value of the matching data.
+  - `Proof ([]byte)`: Proof for the data, if requested.
+  - `Height (int64)`: The block height from which data was derived.
+    Note that this is the height of the block containing the
+    application's Merkle root hash, which represents the state as it
+    was after committing the block at Height-1
+- **Usage**:
+  - Query for data from the application at current or past height.
+  - Optionally return Merkle proof.
+
+### BeginBlock
+
+- **Request**:
+  - `Hash ([]byte)`: The block's hash. This can be derived from the
+    block header.
+  - `Header (struct{})`: The block header
+  - `Validators ([]SigningValidator)`: List of validators in the current validator
+    set and whether or not they signed a vote in the LastCommit
+  - `ByzantineValidators ([]Evidence)`: List of evidence of
+    validators that acted maliciously
+- **Response**:
+  - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
+- **Usage**:
+  - Signals the beginning of a new block. Called prior to
+    any DeliverTxs.
+  - The header is expected to at least contain the Height.
+  - The `Validators` and `ByzantineValidators` can be used to
+    determine rewards and punishments for the validators.
+
+### CheckTx
+
+- **Request**:
+  - `Tx ([]byte)`: The request transaction bytes
+- **Response**:
+  - `Code (uint32)`: Response code
+  - `Data ([]byte)`: Result bytes, if any.
+  - `Log (string)`: The output of the application's logger. May
+    be non-deterministic.
+  - `Info (string)`: Additional information. May
+    be non-deterministic.
+  - `GasWanted (int64)`: Amount of gas request for transaction.
+  - `GasUsed (int64)`: Amount of gas consumed by transaction.
+  - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
+    transactions (eg. by account).
+  - `Fee (cmn.KI64Pair)`: Fee paid for the transaction.
+- **Usage**: Validate a mempool transaction, prior to broadcasting
+  or proposing. CheckTx should perform stateful but light-weight
+  checks of the validity of the transaction (like checking signatures
+  and account balances), but need not execute in full (like running a
+  smart contract).
+
+  Tendermint runs CheckTx and DeliverTx concurrently with eachother,
+  though on distinct ABCI connections - the mempool connection and the
+  consensus connection, respectively.
+
+  The application should maintain a separate state to support CheckTx.
+  This state can be reset to the latest committed state during
+  `Commit`. Before calling Commit, Tendermint will lock and flush the mempool,
+  ensuring that all existing CheckTx are responded to and no new ones can
+  begin. After `Commit`, the mempool will rerun
+  CheckTx for all remaining transactions, throwing out any that are no longer valid.
+  Then the mempool will unlock and start sending CheckTx again.
+
+  Keys and values in Tags must be UTF-8 encoded strings (e.g.
+  "account.owner": "Bob", "balance": "100.0", "date": "2018-01-02")
+
+### DeliverTx
+
+- **Request**:
+  - `Tx ([]byte)`: The request transaction bytes.
+- **Response**:
+  - `Code (uint32)`: Response code.
+  - `Data ([]byte)`: Result bytes, if any.
+  - `Log (string)`: The output of the application's logger. May
+    be non-deterministic.
+  - `Info (string)`: Additional information. May
+    be non-deterministic.
+  - `GasWanted (int64)`: Amount of gas requested for transaction.
+  - `GasUsed (int64)`: Amount of gas consumed by transaction.
+  - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
+    transactions (eg. by account).
+  - `Fee (cmn.KI64Pair)`: Fee paid for the transaction.
+- **Usage**:
+  - Deliver a transaction to be executed in full by the application.
+    If the transaction is valid, returns CodeType.OK.
+  - Keys and values in Tags must be UTF-8 encoded strings (e.g.
+    "account.owner": "Bob", "balance": "100.0",
+    "time": "2018-01-02T12:30:00Z")
+
+### EndBlock
+
+- **Request**:
+  - `Height (int64)`: Height of the block just executed.
+- **Response**:
+  - `ValidatorUpdates ([]Validator)`: Changes to validator set (set
+    voting power to 0 to remove).
+  - `ConsensusParamUpdates (ConsensusParams)`: Changes to
+    consensus-critical time, size, and other parameters.
+  - `Tags ([]cmn.KVPair)`: Key-Value tags for filtering and indexing
+- **Usage**:
+  - Signals the end of a block.
+  - Called prior to each Commit, after all transactions.
+  - Validator set and consensus params are updated with the result.
+  - Validator pubkeys are expected to be go-wire encoded.
+
+### Commit
+
+- **Response**:
+  - `Data ([]byte)`: The Merkle root hash
+- **Usage**:
+  - Persist the application state.
+  - Return a Merkle root hash of the application state.
+  - It's critical that all application instances return the
+    same hash. If not, they will not be able to agree on the next
+    block, because the hash is included in the next block!
+
+## Data Messages
+
+### Header
+
+- **Fields**:
+  - `ChainID (string)`: ID of the blockchain
+  - `Height (int64)`: Height of the block in the chain
+  - `Time (int64)`: Unix time of the block
+  - `NumTxs (int32)`: Number of transactions in the block
+  - `TotalTxs (int64)`: Total number of transactions in the blockchain until
+    now
+  - `LastBlockHash ([]byte)`: Hash of the previous (parent) block
+  - `ValidatorsHash ([]byte)`: Hash of the validator set for this block
+  - `AppHash ([]byte)`: Data returned by the last call to `Commit` - typically the
+    Merkle root of the application state after executing the previous block's
+    transactions
+  - `Proposer (Validator)`: Original proposer for the block
+- **Usage**:
+  - Provided in RequestBeginBlock
+  - Provides important context about the current state of the blockchain -
+    especially height and time.
+  - Provides the proposer of the current block, for use in proposer-based
+    reward mechanisms.
+
+### Validator
+
+- **Fields**:
+  - `Address ([]byte)`: Address of the validator (hash of the public key)
+  - `PubKey (PubKey)`: Public key of the validator
+  - `Power (int64)`: Voting power of the validator
+- **Usage**:
+  - Provides all identifying information about the validator
+
+### SigningValidator
+
+- **Fields**:
+  - `Validator (Validator)`: A validator
+  - `SignedLastBlock (bool)`: Indicated whether or not the validator signed
+    the last block
+- **Usage**:
+  - Indicates whether a validator signed the last block, allowing for rewards
+    based on validator availability
+
+### PubKey
+
+- **Fields**:
+  - `Type (string)`: Type of the public key. A simple string like `"ed25519"`.
+    In the future, may indicate a serialization algorithm to parse the `Data`,
+    for instance `"amino"`.
+  - `Data ([]byte)`: Public key data. For a simple public key, it's just the
+    raw bytes. If the `Type` indicates an encoding algorithm, this is the
+    encoded public key.
+- **Usage**:
+  - A generic and extensible typed public key
+
+### Evidence
+
+- **Fields**:
+  - `Type (string)`: Type of the evidence. A hierarchical path like
+    "duplicate/vote".
+  - `Validator (Validator`: The offending validator
+  - `Height (int64)`: Height when the offense was committed
+  - `Time (int64)`: Unix time of the block at height `Height`
+  - `TotalVotingPower (int64)`: Total voting power of the validator set at
+    height `Height`

docs/app-dev/app-architecture.md

@@ -17,7 +17,7 @@ transaction is actually processed.
 
 The ABCI application must be a deterministic result of the Tendermint
 consensus - any external influence on the application state that didn't
-come through Tendermint could cause a consensus failure. Thus *nothing*
+come through Tendermint could cause a consensus failure. Thus _nothing_
 should communicate with the application except Tendermint via ABCI.
 
 If the application is written in Go, it can be compiled into the
@@ -43,6 +43,7 @@ all transactions, and possibly all queries, should still pass through
 Tendermint.
 
 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)

docs/app-dev/app-development.md

@@ -16,28 +16,27 @@ committed in hash-linked blocks.
 
 The ABCI design has a few distinct components:
 
--   message protocol
-    -   pairs of request and response messages
-    -   consensus makes requests, application responds
-    -   defined using protobuf
--   server/client
-    -   consensus engine runs the client
-    -   application runs the server
-    -   two implementations:
-        -   async raw bytes
-        -   grpc
--   blockchain protocol
-    -   abci is connection oriented
-    -   Tendermint Core maintains three connections:
-        -   [mempool connection](#mempool-connection): for checking if
-            transactions should be relayed before they are committed;
-            only uses `CheckTx`
-        -   [consensus connection](#consensus-connection): for executing
-            transactions that have been committed. Message sequence is
-            -for every block
-            -`BeginBlock, [DeliverTx, ...], EndBlock, Commit`
-        -   [query connection](#query-connection): for querying the
-            application state; only uses Query and Info
+- message protocol
+  - pairs of request and response messages
+  - consensus makes requests, application responds
+  - defined using protobuf
+- server/client
+  - consensus engine runs the client
+  - application runs the server
+  - two implementations:
+    - async raw bytes
+    - grpc
+- blockchain protocol
+  - abci is connection oriented
+  - Tendermint Core maintains three connections:
+    - [mempool connection](#mempool-connection): for checking if
+      transactions should be relayed before they are committed;
+      only uses `CheckTx`
+    - [consensus connection](#consensus-connection): for executing
+      transactions that have been committed. Message sequence is
+      -for every block -`BeginBlock, [DeliverTx, ...], EndBlock, Commit`
+    - [query connection](#query-connection): for querying the
+      application state; only uses Query and Info
 
 The mempool and consensus logic act as clients, and each maintains an
 open ABCI connection with the application, which hosts an ABCI server.
@@ -64,9 +63,9 @@ To use ABCI in your programming language of choice, there must be a ABCI
 server in that language. Tendermint supports two kinds of implementation
 of the server:
 
--   Asynchronous, raw socket server (Tendermint Socket Protocol, also
-    known as TSP or Teaspoon)
--   GRPC
+- Asynchronous, raw socket server (Tendermint Socket Protocol, also
+  known as TSP or Teaspoon)
+- GRPC
 
 Both can be tested using the `abci-cli` by setting the `--abci` flag
 appropriately (ie. to `socket` or `grpc`).
@@ -161,7 +160,7 @@ connection, to query the local state of the app.
 
 ### Mempool Connection
 
-The mempool connection is used *only* for CheckTx requests. Transactions
+The mempool connection is used _only_ for CheckTx requests. Transactions
 are run using CheckTx in the same order they were received by the
 validator. If the CheckTx returns `OK`, the transaction is kept in
 memory and relayed to other peers in the same order it was received.
@@ -180,23 +179,27 @@ mempool state (this behaviour can be turned off with
 
 In go:
 
-    func (app *KVStoreApplication) CheckTx(tx []byte) types.Result {
-      return types.OK
-    }
+```
+func (app *KVStoreApplication) CheckTx(tx []byte) types.Result {
+  return types.OK
+}
+```
 
 In Java:
 
-    ResponseCheckTx requestCheckTx(RequestCheckTx req) {
-        byte[] transaction = req.getTx().toByteArray();
+```
+ResponseCheckTx requestCheckTx(RequestCheckTx req) {
+    byte[] transaction = req.getTx().toByteArray();
 
-        // validate transaction
+    // validate transaction
 
-        if (notValid) {
-            return ResponseCheckTx.newBuilder().setCode(CodeType.BadNonce).setLog("invalid tx").build();
-        } else {
-            return ResponseCheckTx.newBuilder().setCode(CodeType.OK).build();
-        }
+    if (notValid) {
+        return ResponseCheckTx.newBuilder().setCode(CodeType.BadNonce).setLog("invalid tx").build();
+    } else {
+        return ResponseCheckTx.newBuilder().setCode(CodeType.OK).build();
     }
+}
+```
 
 ### Replay Protection
 
@@ -242,43 +245,47 @@ merkle root of the data returned by the DeliverTx requests, or both.
 
 In go:
 
-    // tx is either "key=value" or just arbitrary bytes
-    func (app *KVStoreApplication) DeliverTx(tx []byte) types.Result {
-      parts := strings.Split(string(tx), "=")
-      if len(parts) == 2 {
-        app.state.Set([]byte(parts[0]), []byte(parts[1]))
-      } else {
-        app.state.Set(tx, tx)
-      }
-      return types.OK
-    }
+```
+// tx is either "key=value" or just arbitrary bytes
+func (app *KVStoreApplication) DeliverTx(tx []byte) types.Result {
+  parts := strings.Split(string(tx), "=")
+  if len(parts) == 2 {
+    app.state.Set([]byte(parts[0]), []byte(parts[1]))
+  } else {
+    app.state.Set(tx, tx)
+  }
+  return types.OK
+}
+```
 
 In Java:
 
-    /**
-     * Using Protobuf types from the protoc compiler, we always start with a byte[]
-     */
-    ResponseDeliverTx deliverTx(RequestDeliverTx request) {
-        byte[] transaction  = request.getTx().toByteArray();
+```
+/**
+ * Using Protobuf types from the protoc compiler, we always start with a byte[]
+ */
+ResponseDeliverTx deliverTx(RequestDeliverTx request) {
+    byte[] transaction  = request.getTx().toByteArray();
 
-        // validate your transaction
-
-        if (notValid) {
-            return ResponseDeliverTx.newBuilder().setCode(CodeType.BadNonce).setLog("transaction was invalid").build();
-        } else {
-            ResponseDeliverTx.newBuilder().setCode(CodeType.OK).build();
-        }
+    // validate your transaction
 
+    if (notValid) {
+        return ResponseDeliverTx.newBuilder().setCode(CodeType.BadNonce).setLog("transaction was invalid").build();
+    } else {
+        ResponseDeliverTx.newBuilder().setCode(CodeType.OK).build();
     }
 
+}
+```
+
 ### Commit
 
 Once all processing of the block is complete, Tendermint sends the
 Commit request and blocks waiting for a response. While the mempool may
 run concurrently with block processing (the BeginBlock, DeliverTxs, and
 EndBlock), it is locked for the Commit request so that its state can be
-safely reset during Commit. This means the app *MUST NOT* do any
-blocking communication with the mempool (ie. broadcast\_tx) during
+safely reset during Commit. This means the app _MUST NOT_ do any
+blocking communication with the mempool (ie. broadcast_tx) during
 Commit, or there will be deadlock. Note also that all remaining
 transactions in the mempool are replayed on the mempool connection
 (CheckTx) following a commit.
@@ -294,21 +301,25 @@ job of the [Handshake](#handshake).
 
 In go:
 
-    func (app *KVStoreApplication) Commit() types.Result {
-      hash := app.state.Hash()
-      return types.NewResultOK(hash, "")
-    }
+```
+func (app *KVStoreApplication) Commit() types.Result {
+  hash := app.state.Hash()
+  return types.NewResultOK(hash, "")
+}
+```
 
 In Java:
 
-    ResponseCommit requestCommit(RequestCommit requestCommit) {
+```
+ResponseCommit requestCommit(RequestCommit requestCommit) {
 
-        // update the internal app-state
-        byte[] newAppState = calculateAppState();
+    // update the internal app-state
+    byte[] newAppState = calculateAppState();
 
-        // and return it to the node
-        return ResponseCommit.newBuilder().setCode(CodeType.OK).setData(ByteString.copyFrom(newAppState)).build();
-    }
+    // and return it to the node
+    return ResponseCommit.newBuilder().setCode(CodeType.OK).setData(ByteString.copyFrom(newAppState)).build();
+}
+```
 
 ### BeginBlock
 
@@ -322,31 +333,35 @@ pick up from when it restarts. See information on the Handshake, below.
 
 In go:
 
-    // Track the block hash and header information
-    func (app *PersistentKVStoreApplication) BeginBlock(params types.RequestBeginBlock) {
-      // update latest block info
-      app.blockHeader = params.Header
+```
+// Track the block hash and header information
+func (app *PersistentKVStoreApplication) BeginBlock(params types.RequestBeginBlock) {
+  // update latest block info
+  app.blockHeader = params.Header
 
-      // reset valset changes
-      app.changes = make([]*types.Validator, 0)
-    }
+  // reset valset changes
+  app.changes = make([]*types.Validator, 0)
+}
+```
 
 In Java:
 
-    /*
-     * all types come from protobuf definition
-     */
-    ResponseBeginBlock requestBeginBlock(RequestBeginBlock req) {
+```
+/*
+ * all types come from protobuf definition
+ */
+ResponseBeginBlock requestBeginBlock(RequestBeginBlock req) {
 
-        Header header = req.getHeader();
-        byte[] prevAppHash = header.getAppHash().toByteArray();
-        long prevHeight = header.getHeight();
-        long numTxs = header.getNumTxs();
+    Header header = req.getHeader();
+    byte[] prevAppHash = header.getAppHash().toByteArray();
+    long prevHeight = header.getHeight();
+    long numTxs = header.getNumTxs();
 
-        // run your pre-block logic. Maybe prepare a state snapshot, message components, etc
+    // run your pre-block logic. Maybe prepare a state snapshot, message components, etc
 
-        return ResponseBeginBlock.newBuilder().build();
-    }
+    return ResponseBeginBlock.newBuilder().build();
+}
+```
 
 ### EndBlock
 
@@ -364,25 +379,29 @@ for details on how it tracks validators.
 
 In go:
 
-    // Update the validator set
-    func (app *PersistentKVStoreApplication) EndBlock(req types.RequestEndBlock) types.ResponseEndBlock {
-      return types.ResponseEndBlock{ValidatorUpdates: app.ValUpdates}
-    }
+```
+// Update the validator set
+func (app *PersistentKVStoreApplication) EndBlock(req types.RequestEndBlock) types.ResponseEndBlock {
+  return types.ResponseEndBlock{ValidatorUpdates: app.ValUpdates}
+}
+```
 
 In Java:
 
-    /*
-     * Assume that one validator changes. The new validator has a power of 10
-     */
-    ResponseEndBlock requestEndBlock(RequestEndBlock req) {
-        final long currentHeight = req.getHeight();
-        final byte[] validatorPubKey = getValPubKey();
+```
+/*
+ * Assume that one validator changes. The new validator has a power of 10
+ */
+ResponseEndBlock requestEndBlock(RequestEndBlock req) {
+    final long currentHeight = req.getHeight();
+    final byte[] validatorPubKey = getValPubKey();
 
-        ResponseEndBlock.Builder builder = ResponseEndBlock.newBuilder();
-        builder.addDiffs(1, Types.Validator.newBuilder().setPower(10L).setPubKey(ByteString.copyFrom(validatorPubKey)).build());
+    ResponseEndBlock.Builder builder = ResponseEndBlock.newBuilder();
+    builder.addDiffs(1, Types.Validator.newBuilder().setPower(10L).setPubKey(ByteString.copyFrom(validatorPubKey)).build());
 
-        return builder.build();
-    }
+    return builder.build();
+}
+```
 
 ### Query Connection
 
@@ -398,67 +417,71 @@ connecting, according to IP address or node ID. For instance,
 returning non-OK ABCI response to either of the following queries will
 cause Tendermint to not connect to the corresponding peer:
 
--   `p2p/filter/addr/<ip addr>`, where `<ip addr>` is an IP address.
--   `p2p/filter/id/<id>`, where `<is>` is the hex-encoded node ID (the hash of
-    the node's p2p pubkey).
+- `p2p/filter/addr/<ip addr>`, where `<ip addr>` is an IP address.
+- `p2p/filter/id/<id>`, where `<is>` is the hex-encoded node ID (the hash of
+  the node's p2p pubkey).
 
 Note: these query formats are subject to change!
 
 In go:
 
-    func (app *KVStoreApplication) Query(reqQuery types.RequestQuery) (resQuery types.ResponseQuery) {
-      if reqQuery.Prove {
-        value, proof, exists := app.state.Proof(reqQuery.Data)
-        resQuery.Index = -1 // TODO make Proof return index
-        resQuery.Key = reqQuery.Data
-        resQuery.Value = value
-        resQuery.Proof = proof
-        if exists {
-          resQuery.Log = "exists"
-        } else {
-          resQuery.Log = "does not exist"
-        }
-        return
-      } else {
-        index, value, exists := app.state.Get(reqQuery.Data)
-        resQuery.Index = int64(index)
-        resQuery.Value = value
-        if exists {
-          resQuery.Log = "exists"
-        } else {
-          resQuery.Log = "does not exist"
-        }
-        return
-      }
+```
+func (app *KVStoreApplication) Query(reqQuery types.RequestQuery) (resQuery types.ResponseQuery) {
+  if reqQuery.Prove {
+    value, proof, exists := app.state.Proof(reqQuery.Data)
+    resQuery.Index = -1 // TODO make Proof return index
+    resQuery.Key = reqQuery.Data
+    resQuery.Value = value
+    resQuery.Proof = proof
+    if exists {
+      resQuery.Log = "exists"
+    } else {
+      resQuery.Log = "does not exist"
     }
+    return
+  } else {
+    index, value, exists := app.state.Get(reqQuery.Data)
+    resQuery.Index = int64(index)
+    resQuery.Value = value
+    if exists {
+      resQuery.Log = "exists"
+    } else {
+      resQuery.Log = "does not exist"
+    }
+    return
+  }
+}
+```
 
 In Java:
 
-    ResponseQuery requestQuery(RequestQuery req) {
-        final boolean isProveQuery = req.getProve();
-        final ResponseQuery.Builder responseBuilder = ResponseQuery.newBuilder();
+```
+ResponseQuery requestQuery(RequestQuery req) {
+    final boolean isProveQuery = req.getProve();
+    final ResponseQuery.Builder responseBuilder = ResponseQuery.newBuilder();
 
-        if (isProveQuery) {
-            com.app.example.ProofResult proofResult = generateProof(req.getData().toByteArray());
-            final byte[] proofAsByteArray = proofResult.getAsByteArray();
+    if (isProveQuery) {
+        com.app.example.ProofResult proofResult = generateProof(req.getData().toByteArray());
+        final byte[] proofAsByteArray = proofResult.getAsByteArray();
 
-            responseBuilder.setProof(ByteString.copyFrom(proofAsByteArray));
-            responseBuilder.setKey(req.getData());
-            responseBuilder.setValue(ByteString.copyFrom(proofResult.getData()));
-            responseBuilder.setLog(result.getLogValue());
-        } else {
-            byte[] queryData = req.getData().toByteArray();
+        responseBuilder.setProof(ByteString.copyFrom(proofAsByteArray));
+        responseBuilder.setKey(req.getData());
+        responseBuilder.setValue(ByteString.copyFrom(proofResult.getData()));
+        responseBuilder.setLog(result.getLogValue());
+    } else {
+        byte[] queryData = req.getData().toByteArray();
 
-            final com.app.example.QueryResult result = generateQueryResult(queryData);
+        final com.app.example.QueryResult result = generateQueryResult(queryData);
 
-            responseBuilder.setIndex(result.getIndex());
-            responseBuilder.setValue(ByteString.copyFrom(result.getValue()));
-            responseBuilder.setLog(result.getLogValue());
-        }
-
-        return responseBuilder.build();
+        responseBuilder.setIndex(result.getIndex());
+        responseBuilder.setValue(ByteString.copyFrom(result.getValue()));
+        responseBuilder.setLog(result.getLogValue());
     }
 
+    return responseBuilder.build();
+}
+```
+
 ### Handshake
 
 When the app or tendermint restarts, they need to sync to a common
@@ -477,17 +500,21 @@ all blocks.
 
 In go:
 
-    func (app *KVStoreApplication) Info(req types.RequestInfo) (resInfo types.ResponseInfo) {
-      return types.ResponseInfo{Data: cmn.Fmt("{\"size\":%v}", app.state.Size())}
-    }
+```
+func (app *KVStoreApplication) Info(req types.RequestInfo) (resInfo types.ResponseInfo) {
+  return types.ResponseInfo{Data: cmn.Fmt("{\"size\":%v}", app.state.Size())}
+}
+```
 
 In Java:
 
-    ResponseInfo requestInfo(RequestInfo req) {
-        final byte[] lastAppHash = getLastAppHash();
-        final long lastHeight = getLastHeight();
-        return ResponseInfo.newBuilder().setLastBlockAppHash(ByteString.copyFrom(lastAppHash)).setLastBlockHeight(lastHeight).build();
-    }
+```
+ResponseInfo requestInfo(RequestInfo req) {
+    final byte[] lastAppHash = getLastAppHash();
+    final long lastHeight = getLastHeight();
+    return ResponseInfo.newBuilder().setLastBlockAppHash(ByteString.copyFrom(lastAppHash)).setLastBlockHeight(lastHeight).build();
+}
+```
 
 ### Genesis
 
@@ -497,31 +524,35 @@ consensus params.
 
 In go:
 
-    // Save the validators in the merkle tree
-    func (app *PersistentKVStoreApplication) InitChain(params types.RequestInitChain) {
-      for _, v := range params.Validators {
-        r := app.updateValidator(v)
-        if r.IsErr() {
-          app.logger.Error("Error updating validators", "r", r)
-        }
-      }
+```
+// Save the validators in the merkle tree
+func (app *PersistentKVStoreApplication) InitChain(params types.RequestInitChain) {
+  for _, v := range params.Validators {
+    r := app.updateValidator(v)
+    if r.IsErr() {
+      app.logger.Error("Error updating validators", "r", r)
     }
+  }
+}
+```
 
 In Java:
 
-    /*
-     * all types come from protobuf definition
-     */
-    ResponseInitChain requestInitChain(RequestInitChain req) {
-        final int validatorsCount = req.getValidatorsCount();
-        final List<Types.Validator> validatorsList = req.getValidatorsList();
+```
+/*
+ * all types come from protobuf definition
+ */
+ResponseInitChain requestInitChain(RequestInitChain req) {
+    final int validatorsCount = req.getValidatorsCount();
+    final List<Types.Validator> validatorsList = req.getValidatorsList();
 
-        validatorsList.forEach((validator) -> {
-            long power = validator.getPower();
-            byte[] validatorPubKey = validator.getPubKey().toByteArray();
+    validatorsList.forEach((validator) -> {
+        long power = validator.getPower();
+        byte[] validatorPubKey = validator.getPubKey().toByteArray();
 
-            // do somehing for validator setup in app
-        });
+        // do somehing for validator setup in app
+    });
 
-        return ResponseInitChain.newBuilder().build();
-    }
+    return ResponseInitChain.newBuilder().build();
+}
+```

docs/app-dev/ecosystem.json

@@ -0,0 +1,213 @@
+{
+  "abciApps": [
+    {
+      "name": "Cosmos SDK",
+      "url": "https://github.com/cosmos/cosmos-sdk",
+      "language": "Go",
+      "author": "Cosmos",
+      "description":
+        "A prototypical account based crypto currency state machine supporting plugins"
+    },
+    {
+      "name": "cb-ledger",
+      "url": "https://github.com/block-finance/cpp-abci",
+      "language": "C++",
+      "author": "Block Finance",
+      "description":
+        "Custodian Bank Ledger, integrating central banking with the blockchains of tomorrow"
+    },
+    {
+      "name": "Clearchain",
+      "url": "https://github.com/tendermint/clearchain",
+      "language": "Go",
+      "author": "FXCLR",
+      "description":
+        "Application to manage a distributed ledger for money transfers that support multi-currency accounts"
+    },
+    {
+      "name": "Ethermint",
+      "url": "https://github.com/tendermint/ethermint",
+      "language": "Go",
+      "author": "Tendermint",
+      "description": "The go-ethereum state machine run as an ABCI app"
+    },
+    {
+      "name": "Merkle AVL Tree",
+      "url": "https://github.com/tendermint/merkleeyes",
+      "language": "Go",
+      "author": "Tendermint",
+      "description": "Tendermint IAVL tree implemented as an ABCI app"
+    },
+    {
+      "name": "Burrow",
+      "url": "https://github.com/hyperledger/burrow",
+      "language": "Go",
+      "author": "Monax Industries",
+      "description":
+        "Ethereum Virtual Machine augmented with native permissioning scheme and global key-value store"
+    },
+    {
+      "name": "Merkle AVL Tree",
+      "url": "https://github.com/jTMSP/MerkleTree",
+      "language": "Java",
+      "author": "jTMSP",
+      "description": "Tendermint IAVL tree implemented as an ABCI app"
+    },
+    {
+      "name": "TMChat",
+      "url": "https://github.com/wolfposd/TMChat",
+      "language": "Java",
+      "author": "jTMSP",
+      "description": "P2P chat using Tendermint"
+    },
+    {
+      "name": "Comit",
+      "url": "https://github.com/zballs/comit",
+      "language": "Go",
+      "author": "Zach Balder",
+      "description": "Public service reporting and tracking"
+    },
+    {
+      "name": "Passchain",
+      "url": "https://github.com/trusch/passchain",
+      "language": "Go",
+      "author": "trusch",
+      "description":
+        "Tool to securely store and share passwords, tokens and other short secrets"
+    },
+    {
+      "name": "Passwerk",
+      "url": "https://github.com/rigelrozanski/passwerk",
+      "language": "Go",
+      "author": "Rigel Rozanski",
+      "description": "Encrypted storage web-utility backed by Tendermint"
+    },
+    {
+      "name": "py-tendermint",
+      "url": "https://github.com/davebryson/py-tendermint",
+      "language": "Python",
+      "author": "Dave Bryson",
+      "description":
+        "A Python microframework for building blockchain applications with Tendermint"
+    },
+    {
+      "name": "Stratumn SDK",
+      "url": "https://github.com/stratumn/sdk",
+      "language": "Go",
+      "author": "Stratumn",
+      "description": "SDK for Proof-of-Process networks"
+    },
+    {
+      "name": "Lotion",
+      "url": "https://github.com/keppel/lotion",
+      "language": "Javascript",
+      "author": "Judd Keppel",
+      "description":
+        "A Javascript microframework for building blockchain applications with Tendermint"
+    },
+    {
+      "name": "Tendermint Blockchain Chat App",
+      "url": "https://github.com/SaifRehman/tendermint-chat-app/",
+      "language": "Javascript",
+      "author": "Saif Rehman",
+      "description":
+        "This is a minimal chat application based on Tendermint using Lotion.js in 30 lines of code!. It also includes web/mobile application built using Ionic 3."
+    },
+    {
+      "name": "BigchainDB",
+      "url": "https://github.com/bigchaindb/bigchaindb",
+      "language": "Python",
+      "author": "BigchainDB GmbH and the BigchainDB community",
+      "description": "Blockchain database"
+    },
+    {
+      "name": "Mint",
+      "url": "https://github.com/Hashnode/mint",
+      "language": "Go",
+      "author": "Hashnode",
+      "description": "Build blockchain-powered social apps"
+    }
+  ],
+  "abciServers": [
+    {
+      "name": "abci",
+      "url": "https://github.com/tendermint/abci",
+      "language": "Go",
+      "author": "Tendermint"
+    },
+    {
+      "name": "js-abci",
+      "url": "https://github.com/tendermint/js-abci",
+      "language": "Javascript",
+      "author": "Tendermint"
+    },
+    {
+      "name": "cpp-tmsp",
+      "url": "https://github.com/mdyring/cpp-tmsp",
+      "language": "C++",
+      "author": "Martin Dyring"
+    },
+    {
+      "name": "jabci",
+      "url": "https://github.com/jTendermint/jabci",
+      "language": "Java",
+      "author": "jTendermint"
+    },
+    {
+      "name": "ocaml-tmsp",
+      "url": "https://github.com/zballs/ocaml-tmsp",
+      "language": "Ocaml",
+      "author": "Zach Balder"
+    },
+    {
+      "name": "abci_server",
+      "url": "https://github.com/KrzysiekJ/abci_server",
+      "language": "Erlang",
+      "author": "Krzysztof Jurewicz"
+    },
+    {
+      "name": "py-abci",
+      "url": "https://github.com/davebryson/py-abci",
+      "language": "Python",
+      "author": "Dave Bryson"
+    },
+    {
+      "name": "Spearmint",
+      "url": "https://github.com/dennismckinnon/spearmint",
+      "language": "Javascript",
+      "author": "Dennis McKinnon"
+    }
+  ],
+  "deploymentTools": [
+    {
+      "name": "mintnet-kubernetes",
+      "url": "https://github.com/tendermint/tools",
+      "technology": "Docker and Kubernetes",
+      "author": "Tendermint",
+      "description":
+        "Deploy a Tendermint test network using Google's kubernetes"
+    },
+    {
+      "name": "terraforce",
+      "url": "https://github.com/tendermint/tools",
+      "technology": "Terraform",
+      "author": "Tendermint",
+      "description":
+        "Terraform + our custom terraforce tool; deploy a production Tendermint network with load balancing over multiple AWS availability zones"
+    },
+    {
+      "name": "ansible-tendermint",
+      "url": "https://github.com/tendermint/tools",
+      "technology": "Ansible",
+      "author": "Tendermint",
+      "description": "Ansible playbooks + Tendermint"
+    },
+    {
+      "name": "brooklyn-tendermint",
+      "url": "https://github.com/cloudsoft/brooklyn-tendermint",
+      "technology": "Clocker for Apache Brooklyn ",
+      "author": "Cloudsoft",
+      "description": "Deploy a tendermint test network in docker containers "
+    }
+  ]
+}

docs/app-dev/ecosystem.md

@@ -3,11 +3,11 @@
 The growing list of applications built using various pieces of the
 Tendermint stack can be found at:
 
--   https://tendermint.com/ecosystem
+- https://tendermint.com/ecosystem
 
 We thank the community for their contributions thus far and welcome the
 addition of new projects. A pull request can be submitted to [this
-file](https://github.com/tendermint/aib-data/blob/master/json/ecosystem.json)
+file](https://github.com/tendermint/tendermint/blob/master/docs/app-dev/ecosystem.json)
 to include your project.
 
 ## Other Tools

docs/app-dev/getting-started.md

@@ -25,11 +25,13 @@ more info.
 
 Then run
 
-    go get github.com/tendermint/tendermint
-    cd $GOPATH/src/github.com/tendermint/tendermint
-    make get_tools
-    make get_vendor_deps
-    make install_abci
+```
+go get github.com/tendermint/tendermint
+cd $GOPATH/src/github.com/tendermint/tendermint
+make get_tools
+make get_vendor_deps
+make install_abci
+```
 
 Now you should have the `abci-cli` installed; you'll see a couple of
 commands (`counter` and `kvstore`) that are example applications written
@@ -47,13 +49,17 @@ full transaction bytes are stored as the key and the value.
 
 Let's start a kvstore application.
 
-    abci-cli kvstore
+```
+abci-cli kvstore
+```
 
 In another terminal, we can start Tendermint. If you have never run
 Tendermint before, use:
 
-    tendermint init
-    tendermint node
+```
+tendermint init
+tendermint node
+```
 
 If you have used Tendermint, you may want to reset the data for a new
 blockchain by running `tendermint unsafe_reset_all`. Then you can run
@@ -63,14 +69,18 @@ details, see [the guide on using Tendermint](./using-tendermint.md).
 You should see Tendermint making blocks! We can get the status of our
 Tendermint node as follows:
 
-    curl -s localhost:26657/status
+```
+curl -s localhost:26657/status
+```
 
 The `-s` just silences `curl`. For nicer output, pipe the result into a
 tool like [jq](https://stedolan.github.io/jq/) or `json_pp`.
 
 Now let's send some transactions to the kvstore.
 
-    curl -s 'localhost:26657/broadcast_tx_commit?tx="abcd"'
+```
+curl -s 'localhost:26657/broadcast_tx_commit?tx="abcd"'
+```
 
 Note the single quote (`'`) around the url, which ensures that the
 double quotes (`"`) are not escaped by bash. This command sent a
@@ -78,50 +88,56 @@ transaction with bytes `abcd`, so `abcd` will be stored as both the key
 and the value in the Merkle tree. The response should look something
 like:
 
-    {
-      "jsonrpc": "2.0",
-      "id": "",
-      "result": {
-        "check_tx": {
-          "fee": {}
+```
+{
+  "jsonrpc": "2.0",
+  "id": "",
+  "result": {
+    "check_tx": {
+      "fee": {}
+    },
+    "deliver_tx": {
+      "tags": [
+        {
+          "key": "YXBwLmNyZWF0b3I=",
+          "value": "amFl"
         },
-        "deliver_tx": {
-          "tags": [
-            {
-              "key": "YXBwLmNyZWF0b3I=",
-              "value": "amFl"
-            },
-            {
-              "key": "YXBwLmtleQ==",
-              "value": "YWJjZA=="
-            }
-          ],
-          "fee": {}
-        },
-        "hash": "9DF66553F98DE3C26E3C3317A3E4CED54F714E39",
-        "height": 14
-      }
-    }
+        {
+          "key": "YXBwLmtleQ==",
+          "value": "YWJjZA=="
+        }
+      ],
+      "fee": {}
+    },
+    "hash": "9DF66553F98DE3C26E3C3317A3E4CED54F714E39",
+    "height": 14
+  }
+}
+```
 
 We can confirm that our transaction worked and the value got stored by
 querying the app:
 
-    curl -s 'localhost:26657/abci_query?data="abcd"'
+```
+curl -s 'localhost:26657/abci_query?data="abcd"'
+```
 
 The result should look like:
 
-    {
-      "jsonrpc": "2.0",
-      "id": "",
-      "result": {
-        "response": {
-          "log": "exists",
-          "index": "-1",
-          "key": "YWJjZA==",
-          "value": "YWJjZA=="
-        }
-      }
+```
+{
+  "jsonrpc": "2.0",
+  "id": "",
+  "result": {
+    "response": {
+      "log": "exists",
+      "index": "-1",
+      "key": "YWJjZA==",
+      "value": "YWJjZA=="
     }
+  }
+}
+```
 
 Note the `value` in the result (`YWJjZA==`); this is the base64-encoding
 of the ASCII of `abcd`. You can verify this in a python 2 shell by
@@ -132,12 +148,16 @@ human-readable](https://github.com/tendermint/tendermint/issues/1794).
 
 Now let's try setting a different key and value:
 
-    curl -s 'localhost:26657/broadcast_tx_commit?tx="name=satoshi"'
+```
+curl -s 'localhost:26657/broadcast_tx_commit?tx="name=satoshi"'
+```
 
 Now if we query for `name`, we should get `satoshi`, or `c2F0b3NoaQ==`
 in base64:
 
-    curl -s 'localhost:26657/abci_query?data="name"'
+```
+curl -s 'localhost:26657/abci_query?data="name"'
+```
 
 Try some other transactions and queries to make sure everything is
 working!
@@ -171,57 +191,67 @@ Let's kill the previous instance of `tendermint` and the `kvstore`
 application, and start the counter app. We can enable `serial=on` with a
 flag:
 
-    abci-cli counter --serial
+```
+abci-cli counter --serial
+```
 
 In another window, reset then start Tendermint:
 
-    tendermint unsafe_reset_all
-    tendermint node
+```
+tendermint unsafe_reset_all
+tendermint node
+```
 
 Once again, you can see the blocks streaming by. Let's send some
 transactions. Since we have set `serial=on`, the first transaction must
 be the number `0`:
 
-    curl localhost:26657/broadcast_tx_commit?tx=0x00
+```
+curl localhost:26657/broadcast_tx_commit?tx=0x00
+```
 
 Note the empty (hence successful) response. The next transaction must be
 the number `1`. If instead, we try to send a `5`, we get an error:
 
-    > curl localhost:26657/broadcast_tx_commit?tx=0x05
-    {
-      "jsonrpc": "2.0",
-      "id": "",
-      "result": {
-        "check_tx": {
-          "fee": {}
-        },
-        "deliver_tx": {
-          "code": 2,
-          "log": "Invalid nonce. Expected 1, got 5",
-          "fee": {}
-        },
-        "hash": "33B93DFF98749B0D6996A70F64071347060DC19C",
-        "height": 34
-      }
-    }
+```
+> curl localhost:26657/broadcast_tx_commit?tx=0x05
+{
+  "jsonrpc": "2.0",
+  "id": "",
+  "result": {
+    "check_tx": {
+      "fee": {}
+    },
+    "deliver_tx": {
+      "code": 2,
+      "log": "Invalid nonce. Expected 1, got 5",
+      "fee": {}
+    },
+    "hash": "33B93DFF98749B0D6996A70F64071347060DC19C",
+    "height": 34
+  }
+}
+```
 
 But if we send a `1`, it works again:
 
-    > curl localhost:26657/broadcast_tx_commit?tx=0x01
-    {
-      "jsonrpc": "2.0",
-      "id": "",
-      "result": {
-        "check_tx": {
-          "fee": {}
-        },
-        "deliver_tx": {
-          "fee": {}
-        },
-        "hash": "F17854A977F6FA7EEA1BD758E296710B86F72F3D",
-        "height": 60
-      }
-    }
+```
+> curl localhost:26657/broadcast_tx_commit?tx=0x01
+{
+  "jsonrpc": "2.0",
+  "id": "",
+  "result": {
+    "check_tx": {
+      "fee": {}
+    },
+    "deliver_tx": {
+      "fee": {}
+    },
+    "hash": "F17854A977F6FA7EEA1BD758E296710B86F72F3D",
+    "height": 60
+  }
+}
+```
 
 For more details on the `broadcast_tx` API, see [the guide on using
 Tendermint](./using-tendermint.md).
@@ -236,26 +266,34 @@ You'll also need to fetch the relevant repository, from
 [here](https://github.com/tendermint/js-abci) then install it. As go
 devs, we keep all our code under the `$GOPATH`, so run:
 
-    go get github.com/tendermint/js-abci &> /dev/null
-    cd $GOPATH/src/github.com/tendermint/js-abci/example
-    npm install
-    cd ..
+```
+go get github.com/tendermint/js-abci &> /dev/null
+cd $GOPATH/src/github.com/tendermint/js-abci/example
+npm install
+cd ..
+```
 
 Kill the previous `counter` and `tendermint` processes. Now run the app:
 
-    node example/counter.js
+```
+node example/counter.js
+```
 
 In another window, reset and start `tendermint`:
 
-    tendermint unsafe_reset_all
-    tendermint node
+```
+tendermint unsafe_reset_all
+tendermint node
+```
 
 Once again, you should see blocks streaming by - but now, our
 application is written in javascript! Try sending some transactions, and
 like before - the results should be the same:
 
-    curl localhost:26657/broadcast_tx_commit?tx=0x00 # ok
-    curl localhost:26657/broadcast_tx_commit?tx=0x05 # invalid nonce
-    curl localhost:26657/broadcast_tx_commit?tx=0x01 # ok
+```
+curl localhost:26657/broadcast_tx_commit?tx=0x00 # ok
+curl localhost:26657/broadcast_tx_commit?tx=0x05 # invalid nonce
+curl localhost:26657/broadcast_tx_commit?tx=0x01 # ok
+```
 
 Neat, eh?

docs/app-dev/indexing-transactions.md

@@ -0,0 +1,97 @@
+# Indexing Transactions
+
+Tendermint allows you to index transactions and later query or subscribe
+to their results.
+
+Let's take a look at the `[tx_index]` config section:
+
+```
+##### transactions indexer configuration options #####
+[tx_index]
+
+# What indexer to use for transactions
+#
+# Options:
+#   1) "null" (default)
+#   2) "kv" - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend).
+indexer = "kv"
+
+# Comma-separated list of tags to index (by default the only tag is tx hash)
+#
+# It's recommended to index only a subset of tags due to possible memory
+# bloat. This is, of course, depends on the indexer's DB and the volume of
+# transactions.
+index_tags = ""
+
+# When set to true, tells indexer to index all tags. Note this may be not
+# desirable (see the comment above). IndexTags has a precedence over
+# IndexAllTags (i.e. when given both, IndexTags will be indexed).
+index_all_tags = false
+```
+
+By default, Tendermint will index all transactions by their respective
+hashes using an embedded simple indexer. Note, we are planning to add
+more options in the future (e.g., Postgresql indexer).
+
+## Adding tags
+
+In your application's `DeliverTx` method, add the `Tags` field with the
+pairs of UTF-8 encoded strings (e.g. "account.owner": "Bob", "balance":
+"100.0", "date": "2018-01-02").
+
+Example:
+
+```
+func (app *KVStoreApplication) DeliverTx(tx []byte) types.Result {
+    ...
+    tags := []cmn.KVPair{
+      {[]byte("account.name"), []byte("igor")},
+      {[]byte("account.address"), []byte("0xdeadbeef")},
+      {[]byte("tx.amount"), []byte("7")},
+    }
+    return types.ResponseDeliverTx{Code: code.CodeTypeOK, Tags: tags}
+}
+```
+
+If you want Tendermint to only index transactions by "account.name" tag,
+in the config set `tx_index.index_tags="account.name"`. If you to index
+all tags, set `index_all_tags=true`
+
+Note, there are a few predefined tags:
+
+- `tm.event` (event type)
+- `tx.hash` (transaction's hash)
+- `tx.height` (height of the block transaction was committed in)
+
+Tendermint will throw a warning if you try to use any of the above keys.
+
+## Querying transactions
+
+You can query the transaction results by calling `/tx_search` RPC
+endpoint:
+
+```
+curl "localhost:26657/tx_search?query=\"account.name='igor'\"&prove=true"
+```
+
+Check out [API docs](https://tendermint.github.io/slate/?shell#txsearch)
+for more information on query syntax and other options.
+
+## Subscribing to transactions
+
+Clients can subscribe to transactions with the given tags via Websocket
+by providing a query to `/subscribe` RPC endpoint.
+
+```
+{
+    "jsonrpc": "2.0",
+    "method": "subscribe",
+    "id": "0",
+    "params": {
+        "query": "account.name='igor'"
+    }
+}
+```
+
+Check out [API docs](https://tendermint.github.io/slate/#subscribe) for
+more information on query syntax and other options.

docs/app-dev/subscribing-to-events-via-websocket.md

@@ -9,14 +9,16 @@ for third-party applications (for analysys) or inspecting state.
 You can subscribe to any of the events above by calling `subscribe` RPC
 method via Websocket.
 
-    {
-        "jsonrpc": "2.0",
-        "method": "subscribe",
-        "id": "0",
-        "params": {
-            "query": "tm.event='NewBlock'"
-        }
+```
+{
+    "jsonrpc": "2.0",
+    "method": "subscribe",
+    "id": "0",
+    "params": {
+        "query": "tm.event='NewBlock'"
     }
+}
+```
 
 Check out [API docs](https://tendermint.github.io/slate/#subscribe) for
 more information on query syntax and other options.

docs/deploy-testnets.md

@@ -1,68 +0,0 @@
-# Deploy a Testnet
-
-Now that we've seen how ABCI works, and even played with a few
-applications on a single validator node, it's time to deploy a test
-network to four validator nodes.
-
-## Manual Deployments
-
-It's relatively easy to setup a Tendermint cluster manually. The only
-requirements for a particular Tendermint node are a private key for the
-validator, stored as `priv_validator.json`, a node key, stored as
-`node_key.json` and a list of the public keys of all validators, stored
-as `genesis.json`. These files should be stored in
-`~/.tendermint/config`, or wherever the `$TMHOME` variable might be set
-to.
-
-Here are the steps to setting up a testnet manually:
-
-1)  Provision nodes on your cloud provider of choice
-2)  Install Tendermint and the application of interest on all nodes
-3)  Generate a private key and a node key for each validator using
-    `tendermint init`
-4)  Compile a list of public keys for each validator into a
-    `genesis.json` file and replace the existing file with it.
-5)  Run
-    `tendermint node --proxy_app=kvstore --p2p.persistent_peers=< peer addresses >`
-    on each node, where `< peer addresses >` is a comma separated list
-    of the IP:PORT combination for each node. The default port for
-    Tendermint is `26656`. Thus, if the IP addresses of your nodes were
-    `192.168.0.1, 192.168.0.2, 192.168.0.3, 192.168.0.4`, the command
-    would look like:
-
-
-    tendermint node --proxy_app=kvstore --p2p.persistent_peers=96663a3dd0d7b9d17d4c8211b191af259621c693@192.168.0.1:26656, 429fcf25974313b95673f58d77eacdd434402665@192.168.0.2:26656, 0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@192.168.0.3:26656, f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@192.168.0.4:26656
-
-After a few seconds, all the nodes should connect to each other and
-start making blocks! For more information, see the Tendermint Networks
-section of [the guide to using Tendermint](./using-tendermint.md).
-
-But wait! Steps 3 and 4 are quite manual. Instead, use [this
-script](https://github.com/tendermint/tendermint/blob/develop/docs/examples/init_testnet.sh),
-which does the heavy lifting for you. And it gets better.
-
-Instead of the previously linked script to initialize the files required
-for a testnet, we have the `tendermint testnet` command. By default,
-running `tendermint testnet` will create all the required files, just
-like the script. Of course, you'll still need to manually edit some
-fields in the `config.toml`. Alternatively, see the available flags to
-auto-populate the `config.toml` with the fields that would otherwise be
-passed in via flags when running `tendermint node`. As you might
-imagine, this command is useful for manual or automated deployments.
-
-## Automated Deployments
-
-The easiest and fastest way to get a testnet up in less than 5 minutes.
-
-### Local
-
-With `docker` and `docker-compose` installed, run the command:
-
-    make localnet-start
-
-from the root of the tendermint repository. This will spin up a 4-node
-local testnet. Review the target in the Makefile to debug any problems.
-
-### Cloud
-
-See the [next section](./terraform-and-ansible.html) for details.

docs/examples/init_testnet.sh

@@ -1,69 +0,0 @@
-#!/usr/bin/env bash
-
-# make all the files
-tendermint init --home ./tester/node0
-tendermint init --home ./tester/node1
-tendermint init --home ./tester/node2
-tendermint init --home ./tester/node3
-
-file0=./tester/node0/config/genesis.json
-file1=./tester/node1/config/genesis.json
-file2=./tester/node2/config/genesis.json
-file3=./tester/node3/config/genesis.json
-
-genesis_time=`cat $file0 | jq '.genesis_time'`
-chain_id=`cat $file0 | jq '.chain_id'`
-
-value0=`cat $file0 | jq '.validators[0].pub_key.value'`
-value1=`cat $file1 | jq '.validators[0].pub_key.value'`
-value2=`cat $file2 | jq '.validators[0].pub_key.value'`
-value3=`cat $file3 | jq '.validators[0].pub_key.value'`
-
-rm $file0
-rm $file1
-rm $file2
-rm $file3
-
-echo "{
-  \"genesis_time\": $genesis_time,
-  \"chain_id\": $chain_id,
-  \"validators\": [
-    {
-     \"pub_key\": {
-       \"type\": \"tendermint/PubKeyEd25519\",
-       \"value\": $value0
-     },
-      \"power:\": 10,
-      \"name\":, \"\"
-    },
-    {
-     \"pub_key\": {
-       \"type\": \"tendermint/PubKeyEd25519\",
-       \"value\": $value1
-     },
-      \"power:\": 10,
-      \"name\":, \"\"
-    },
-    {
-     \"pub_key\": {
-       \"type\": \"tendermint/PubKeyEd25519\",
-       \"value\": $value2
-     },
-      \"power:\": 10,
-      \"name\":, \"\"
-    },
-    {
-     \"pub_key\": {
-       \"type\": \"tendermint/PubKeyEd25519\",
-       \"value\": $value3
-     },
-      \"power:\": 10,
-      \"name\":, \"\"
-    }
-   ],
-   \"app_hash\": \"\"
-}" >> $file0
-
-cp $file0 $file1
-cp $file0 $file2
-cp $file2 $file3

docs/examples/install_tendermint.sh

@@ -1,32 +0,0 @@
-#!/usr/bin/env bash
-
-# XXX: this script is meant to be used only on a fresh Ubuntu 16.04 instance
-# and has only been tested on Digital Ocean
-
-# get and unpack golang
-curl -O https://storage.googleapis.com/golang/go1.10.linux-amd64.tar.gz
-tar -xvf go1.10.linux-amd64.tar.gz
-
-apt install make
-
-## move go and add binary to path
-mv go /usr/local
-echo "export PATH=\$PATH:/usr/local/go/bin" >> ~/.profile
-
-## create the GOPATH directory, set GOPATH and put on PATH
-mkdir goApps
-echo "export GOPATH=/root/goApps" >> ~/.profile
-echo "export PATH=\$PATH:\$GOPATH/bin" >> ~/.profile
-
-source ~/.profile
-
-## get the code and move into it
-REPO=github.com/tendermint/tendermint
-go get $REPO
-cd $GOPATH/src/$REPO
-
-## build
-git checkout master
-make get_tools
-make get_vendor_deps
-make install

docs/examples/node0/config/config.toml

@@ -1,166 +0,0 @@
-# This is a TOML config file.
-# For more information, see https://github.com/toml-lang/toml
-
-##### main base config options #####
-
-# TCP or UNIX socket address of the ABCI application,
-# or the name of an ABCI application compiled in with the Tendermint binary
-proxy_app = "tcp://127.0.0.1:26658"
-
-# A custom human readable name for this node
-moniker = "alpha"
-
-# If this node is many blocks behind the tip of the chain, FastSync
-# allows them to catchup quickly by downloading blocks in parallel
-# and verifying their commits
-fast_sync = true
-
-# Database backend: leveldb | memdb
-db_backend = "leveldb"
-
-# Database directory
-db_path = "data"
-
-# Output level for logging, including package level options
-log_level = "main:info,state:info,*:error"
-
-##### additional base config options #####
-
-# Path to the JSON file containing the initial validator set and other meta data
-genesis_file = "config/genesis.json"
-
-# Path to the JSON file containing the private key to use as a validator in the consensus protocol
-priv_validator_file = "config/priv_validator.json"
-
-# Path to the JSON file containing the private key to use for node authentication in the p2p protocol
-node_key_file = "config/node_key.json"
-
-# Mechanism to connect to the ABCI application: socket | grpc
-abci = "socket"
-
-# TCP or UNIX socket address for the profiling server to listen on
-prof_laddr = ""
-
-# If true, query the ABCI app on connecting to a new peer
-# so the app can decide if we should keep the connection or not
-filter_peers = false
-
-##### advanced configuration options #####
-
-##### rpc server configuration options #####
-[rpc]
-
-# TCP or UNIX socket address for the RPC server to listen on
-laddr = "tcp://0.0.0.0:26657"
-
-# TCP or UNIX socket address for the gRPC server to listen on
-# NOTE: This server only supports /broadcast_tx_commit
-grpc_laddr = ""
-
-# Activate unsafe RPC commands like /dial_seeds and /unsafe_flush_mempool
-unsafe = false
-
-##### peer to peer configuration options #####
-[p2p]
-
-# Address to listen for incoming connections
-laddr = "tcp://0.0.0.0:26656"
-
-# Comma separated list of seed nodes to connect to
-seeds = ""
-
-# Comma separated list of nodes to keep persistent connections to
-# Do not add private peers to this list if you don't want them advertised
-persistent_peers = ""
-
-# Path to address book
-addr_book_file = "config/addrbook.json"
-
-# Set true for strict address routability rules
-addr_book_strict = true
-
-# Time to wait before flushing messages out on the connection, in ms
-flush_throttle_timeout = 100
-
-# Maximum number of peers to connect to
-max_num_peers = 50
-
-# Maximum size of a message packet payload, in bytes
-max_packet_msg_payload_size = 1024
-
-# Rate at which packets can be sent, in bytes/second
-send_rate = 512000
-
-# Rate at which packets can be received, in bytes/second
-recv_rate = 512000
-
-# Set true to enable the peer-exchange reactor
-pex = true
-
-# Seed mode, in which node constantly crawls the network and looks for
-# peers. If another node asks it for addresses, it responds and disconnects.
-#
-# Does not work if the peer-exchange reactor is disabled.
-seed_mode = false
-
-# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
-private_peer_ids = ""
-
-##### mempool configuration options #####
-[mempool]
-
-recheck = true
-recheck_empty = true
-broadcast = true
-wal_dir = "data/mempool.wal"
-
-##### consensus configuration options #####
-[consensus]
-
-wal_file = "data/cs.wal/wal"
-
-# All timeouts are in milliseconds
-timeout_propose = 3000
-timeout_propose_delta = 500
-timeout_prevote = 1000
-timeout_prevote_delta = 500
-timeout_precommit = 1000
-timeout_precommit_delta = 500
-timeout_commit = 1000
-
-# Make progress as soon as we have all the precommits (as if TimeoutCommit = 0)
-skip_timeout_commit = false
-
-# BlockSize
-max_block_size_txs = 10000
-max_block_size_bytes = 1
-
-# EmptyBlocks mode and possible interval between empty blocks in seconds
-create_empty_blocks = true
-create_empty_blocks_interval = 0
-
-# Reactor sleep duration parameters are in milliseconds
-peer_gossip_sleep_duration = 100
-peer_query_maj23_sleep_duration = 2000
-
-##### transactions indexer configuration options #####
-[tx_index]
-
-# What indexer to use for transactions
-#
-# Options:
-#   1) "null" (default)
-#   2) "kv" - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend).
-indexer = "kv"
-
-# Comma-separated list of tags to index (by default the only tag is tx hash)
-#
-# It's recommended to index only a subset of tags due to possible memory
-# bloat. This is, of course, depends on the indexer's DB and the volume of
-# transactions.
-index_tags = ""
-
-# When set to true, tells indexer to index all tags. Note this may be not
-# desirable (see the comment above). IndexTags has a precedence over
-# IndexAllTags (i.e. when given both, IndexTags will be indexed).
-index_all_tags = false

docs/examples/node0/config/genesis.json

@@ -1,39 +0,0 @@
-{
-  "genesis_time": "0001-01-01T00:00:00Z",
-  "chain_id": "test-chain-A2i3OZ",
-  "validators": [
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "D+k4AdjnYPWbB9wmad137Bdpo/kAulOoTRQrLy/Qc4k="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "b56N5GCR1adcVRuENjfKw/mrm2dkhT7wNZXV/SDsKsU="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "IgZDpJvGA0TAamicA8ircy+RX/BkUlj6DXwM791ywIU="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "KGAZfxZvIZ7abbeIQ85U1ECG6+I62KSdaH8ulc0+OiU="
-      },
-      "power": "10",
-      "name": ""
-    }
-  ],
-  "app_hash": ""
-}

docs/examples/node0/config/node_key.json

@@ -1 +0,0 @@
-{"priv_key":{"type":"tendermint/PrivKeyEd25519","value":"7lY+k6EDllG8Q9gVbF5313t/ag2YGkBVKdVa0YHJ9xO5k0w3Q/hke0Z7UFT1KgVDGRUEKzwAwwjwFQUvgF0ZWg=="}}

docs/examples/node0/config/priv_validator.json

@@ -1,14 +0,0 @@
-{
-  "address": "122A9414774A2FCAD026201DA477EF3F41970EF0",
-  "pub_key": {
-    "type": "tendermint/PubKeyEd25519",
-    "value": "D+k4AdjnYPWbB9wmad137Bdpo/kAulOoTRQrLy/Qc4k="
-  },
-  "last_height": "0",
-  "last_round": "0",
-  "last_step": 0,
-  "priv_key": {
-    "type": "tendermint/PrivKeyEd25519",
-    "value": "YLxp3ho+kySgAnzjBptbxDzSGw2ntGZLsIHQsaVxY/cP6TgB2Odg9ZsH3CZp3XfsF2mj+QC6U6hNFCsvL9BziQ=="
-  }
-}

docs/examples/node1/config/config.toml

@@ -1,166 +0,0 @@
-# This is a TOML config file.
-# For more information, see https://github.com/toml-lang/toml
-
-##### main base config options #####
-
-# TCP or UNIX socket address of the ABCI application,
-# or the name of an ABCI application compiled in with the Tendermint binary
-proxy_app = "tcp://127.0.0.1:26658"
-
-# A custom human readable name for this node
-moniker = "bravo"
-
-# If this node is many blocks behind the tip of the chain, FastSync
-# allows them to catchup quickly by downloading blocks in parallel
-# and verifying their commits
-fast_sync = true
-
-# Database backend: leveldb | memdb
-db_backend = "leveldb"
-
-# Database directory
-db_path = "data"
-
-# Output level for logging, including package level options
-log_level = "main:info,state:info,*:error"
-
-##### additional base config options #####
-
-# Path to the JSON file containing the initial validator set and other meta data
-genesis_file = "config/genesis.json"
-
-# Path to the JSON file containing the private key to use as a validator in the consensus protocol
-priv_validator_file = "config/priv_validator.json"
-
-# Path to the JSON file containing the private key to use for node authentication in the p2p protocol
-node_key_file = "config/node_key.json"
-
-# Mechanism to connect to the ABCI application: socket | grpc
-abci = "socket"
-
-# TCP or UNIX socket address for the profiling server to listen on
-prof_laddr = ""
-
-# If true, query the ABCI app on connecting to a new peer
-# so the app can decide if we should keep the connection or not
-filter_peers = false
-
-##### advanced configuration options #####
-
-##### rpc server configuration options #####
-[rpc]
-
-# TCP or UNIX socket address for the RPC server to listen on
-laddr = "tcp://0.0.0.0:26657"
-
-# TCP or UNIX socket address for the gRPC server to listen on
-# NOTE: This server only supports /broadcast_tx_commit
-grpc_laddr = ""
-
-# Activate unsafe RPC commands like /dial_seeds and /unsafe_flush_mempool
-unsafe = false
-
-##### peer to peer configuration options #####
-[p2p]
-
-# Address to listen for incoming connections
-laddr = "tcp://0.0.0.0:26656"
-
-# Comma separated list of seed nodes to connect to
-seeds = ""
-
-# Comma separated list of nodes to keep persistent connections to
-# Do not add private peers to this list if you don't want them advertised
-persistent_peers = ""
-
-# Path to address book
-addr_book_file = "config/addrbook.json"
-
-# Set true for strict address routability rules
-addr_book_strict = true
-
-# Time to wait before flushing messages out on the connection, in ms
-flush_throttle_timeout = 100
-
-# Maximum number of peers to connect to
-max_num_peers = 50
-
-# Maximum size of a message packet payload, in bytes
-max_packet_msg_payload_size = 1024
-
-# Rate at which packets can be sent, in bytes/second
-send_rate = 512000
-
-# Rate at which packets can be received, in bytes/second
-recv_rate = 512000
-
-# Set true to enable the peer-exchange reactor
-pex = true
-
-# Seed mode, in which node constantly crawls the network and looks for
-# peers. If another node asks it for addresses, it responds and disconnects.
-#
-# Does not work if the peer-exchange reactor is disabled.
-seed_mode = false
-
-# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
-private_peer_ids = ""
-
-##### mempool configuration options #####
-[mempool]
-
-recheck = true
-recheck_empty = true
-broadcast = true
-wal_dir = "data/mempool.wal"
-
-##### consensus configuration options #####
-[consensus]
-
-wal_file = "data/cs.wal/wal"
-
-# All timeouts are in milliseconds
-timeout_propose = 3000
-timeout_propose_delta = 500
-timeout_prevote = 1000
-timeout_prevote_delta = 500
-timeout_precommit = 1000
-timeout_precommit_delta = 500
-timeout_commit = 1000
-
-# Make progress as soon as we have all the precommits (as if TimeoutCommit = 0)
-skip_timeout_commit = false
-
-# BlockSize
-max_block_size_txs = 10000
-max_block_size_bytes = 1
-
-# EmptyBlocks mode and possible interval between empty blocks in seconds
-create_empty_blocks = true
-create_empty_blocks_interval = 0
-
-# Reactor sleep duration parameters are in milliseconds
-peer_gossip_sleep_duration = 100
-peer_query_maj23_sleep_duration = 2000
-
-##### transactions indexer configuration options #####
-[tx_index]
-
-# What indexer to use for transactions
-#
-# Options:
-#   1) "null" (default)
-#   2) "kv" - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend).
-indexer = "kv"
-
-# Comma-separated list of tags to index (by default the only tag is tx hash)
-#
-# It's recommended to index only a subset of tags due to possible memory
-# bloat. This is, of course, depends on the indexer's DB and the volume of
-# transactions.
-index_tags = ""
-
-# When set to true, tells indexer to index all tags. Note this may be not
-# desirable (see the comment above). IndexTags has a precedence over
-# IndexAllTags (i.e. when given both, IndexTags will be indexed).
-index_all_tags = false

docs/examples/node1/config/genesis.json

@@ -1,39 +0,0 @@
-{
-  "genesis_time": "0001-01-01T00:00:00Z",
-  "chain_id": "test-chain-A2i3OZ",
-  "validators": [
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "D+k4AdjnYPWbB9wmad137Bdpo/kAulOoTRQrLy/Qc4k="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "b56N5GCR1adcVRuENjfKw/mrm2dkhT7wNZXV/SDsKsU="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "IgZDpJvGA0TAamicA8ircy+RX/BkUlj6DXwM791ywIU="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "KGAZfxZvIZ7abbeIQ85U1ECG6+I62KSdaH8ulc0+OiU="
-      },
-      "power": "10",
-      "name": ""
-    }
-  ],
-  "app_hash": ""
-}

docs/examples/node1/config/node_key.json

@@ -1 +0,0 @@
-{"priv_key":{"type":"tendermint/PrivKeyEd25519","value":"H71dc/TIG7nTselfa9nG0WRArXLKYnm7P5eFCk2lk8ASKQ3sIHpbdxCSHQD/RcdHe7TiabJeuOssNPvPWiyQEQ=="}}

docs/examples/node1/config/priv_validator.json

@@ -1,14 +0,0 @@
-{
-  "address": "BEA1B57F5806CF9AC4D54C8CF806DED5C0F102E1",
-  "pub_key": {
-    "type": "tendermint/PubKeyEd25519",
-    "value": "b56N5GCR1adcVRuENjfKw/mrm2dkhT7wNZXV/SDsKsU="
-  },
-  "last_height": "0",
-  "last_round": "0",
-  "last_step": 0,
-  "priv_key": {
-    "type": "tendermint/PrivKeyEd25519",
-    "value": "o0IqrHSPtd5YqGefodWxpJuRzvuVBjgbH785vbMgk7Vvno3kYJHVp1xVG4Q2N8rD+aubZ2SFPvA1ldX9IOwqxQ=="
-  }
-}

docs/examples/node2/config/config.toml

@@ -1,166 +0,0 @@
-# This is a TOML config file.
-# For more information, see https://github.com/toml-lang/toml
-
-##### main base config options #####
-
-# TCP or UNIX socket address of the ABCI application,
-# or the name of an ABCI application compiled in with the Tendermint binary
-proxy_app = "tcp://127.0.0.1:26658"
-
-# A custom human readable name for this node
-moniker = "charlie"
-
-# If this node is many blocks behind the tip of the chain, FastSync
-# allows them to catchup quickly by downloading blocks in parallel
-# and verifying their commits
-fast_sync = true
-
-# Database backend: leveldb | memdb
-db_backend = "leveldb"
-
-# Database directory
-db_path = "data"
-
-# Output level for logging, including package level options
-log_level = "main:info,state:info,*:error"
-
-##### additional base config options #####
-
-# Path to the JSON file containing the initial validator set and other meta data
-genesis_file = "config/genesis.json"
-
-# Path to the JSON file containing the private key to use as a validator in the consensus protocol
-priv_validator_file = "config/priv_validator.json"
-
-# Path to the JSON file containing the private key to use for node authentication in the p2p protocol
-node_key_file = "config/node_key.json"
-
-# Mechanism to connect to the ABCI application: socket | grpc
-abci = "socket"
-
-# TCP or UNIX socket address for the profiling server to listen on
-prof_laddr = ""
-
-# If true, query the ABCI app on connecting to a new peer
-# so the app can decide if we should keep the connection or not
-filter_peers = false
-
-##### advanced configuration options #####
-
-##### rpc server configuration options #####
-[rpc]
-
-# TCP or UNIX socket address for the RPC server to listen on
-laddr = "tcp://0.0.0.0:26657"
-
-# TCP or UNIX socket address for the gRPC server to listen on
-# NOTE: This server only supports /broadcast_tx_commit
-grpc_laddr = ""
-
-# Activate unsafe RPC commands like /dial_seeds and /unsafe_flush_mempool
-unsafe = false
-
-##### peer to peer configuration options #####
-[p2p]
-
-# Address to listen for incoming connections
-laddr = "tcp://0.0.0.0:26656"
-
-# Comma separated list of seed nodes to connect to
-seeds = ""
-
-# Comma separated list of nodes to keep persistent connections to
-# Do not add private peers to this list if you don't want them advertised
-persistent_peers = ""
-
-# Path to address book
-addr_book_file = "config/addrbook.json"
-
-# Set true for strict address routability rules
-addr_book_strict = true
-
-# Time to wait before flushing messages out on the connection, in ms
-flush_throttle_timeout = 100
-
-# Maximum number of peers to connect to
-max_num_peers = 50
-
-# Maximum size of a message packet payload, in bytes
-max_packet_msg_payload_size = 1024
-
-# Rate at which packets can be sent, in bytes/second
-send_rate = 512000
-
-# Rate at which packets can be received, in bytes/second
-recv_rate = 512000
-
-# Set true to enable the peer-exchange reactor
-pex = true
-
-# Seed mode, in which node constantly crawls the network and looks for
-# peers. If another node asks it for addresses, it responds and disconnects.
-#
-# Does not work if the peer-exchange reactor is disabled.
-seed_mode = false
-
-# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
-private_peer_ids = ""
-
-##### mempool configuration options #####
-[mempool]
-
-recheck = true
-recheck_empty = true
-broadcast = true
-wal_dir = "data/mempool.wal"
-
-##### consensus configuration options #####
-[consensus]
-
-wal_file = "data/cs.wal/wal"
-
-# All timeouts are in milliseconds
-timeout_propose = 3000
-timeout_propose_delta = 500
-timeout_prevote = 1000
-timeout_prevote_delta = 500
-timeout_precommit = 1000
-timeout_precommit_delta = 500
-timeout_commit = 1000
-
-# Make progress as soon as we have all the precommits (as if TimeoutCommit = 0)
-skip_timeout_commit = false
-
-# BlockSize
-max_block_size_txs = 10000
-max_block_size_bytes = 1
-
-# EmptyBlocks mode and possible interval between empty blocks in seconds
-create_empty_blocks = true
-create_empty_blocks_interval = 0
-
-# Reactor sleep duration parameters are in milliseconds
-peer_gossip_sleep_duration = 100
-peer_query_maj23_sleep_duration = 2000
-
-##### transactions indexer configuration options #####
-[tx_index]
-
-# What indexer to use for transactions
-#
-# Options:
-#   1) "null" (default)
-#   2) "kv" - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend).
-indexer = "kv"
-
-# Comma-separated list of tags to index (by default the only tag is tx hash)
-#
-# It's recommended to index only a subset of tags due to possible memory
-# bloat. This is, of course, depends on the indexer's DB and the volume of
-# transactions.
-index_tags = ""
-
-# When set to true, tells indexer to index all tags. Note this may be not
-# desirable (see the comment above). IndexTags has a precedence over
-# IndexAllTags (i.e. when given both, IndexTags will be indexed).
-index_all_tags = false

docs/examples/node2/config/genesis.json

@@ -1,39 +0,0 @@
-{
-  "genesis_time": "0001-01-01T00:00:00Z",
-  "chain_id": "test-chain-A2i3OZ",
-  "validators": [
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "D+k4AdjnYPWbB9wmad137Bdpo/kAulOoTRQrLy/Qc4k="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "b56N5GCR1adcVRuENjfKw/mrm2dkhT7wNZXV/SDsKsU="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "IgZDpJvGA0TAamicA8ircy+RX/BkUlj6DXwM791ywIU="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "KGAZfxZvIZ7abbeIQ85U1ECG6+I62KSdaH8ulc0+OiU="
-      },
-      "power": "10",
-      "name": ""
-    }
-  ],
-  "app_hash": ""
-}

docs/examples/node2/config/node_key.json

@@ -1 +0,0 @@
-{"priv_key":{"type":"tendermint/PrivKeyEd25519","value":"COHZ/Y2cWGWxJNkRwtpQBt5sYvOnb6Gpz0lO46XERRJFBIdSWD5x1UMGRSTmnvW1ec5G4bMdg6zUZKOZD+vVPg=="}}

docs/examples/node2/config/priv_validator.json

@@ -1,14 +0,0 @@
-{
-  "address": "F0AA266949FB29ADA0B679C27889ED930BD1BDA1",
-  "pub_key": {
-    "type": "tendermint/PubKeyEd25519",
-    "value": "IgZDpJvGA0TAamicA8ircy+RX/BkUlj6DXwM791ywIU="
-  },
-  "last_height": "0",
-  "last_round": "0",
-  "last_step": 0,
-  "priv_key": {
-    "type": "tendermint/PrivKeyEd25519",
-    "value": "khADeZ5K/8u/L99DFaZNRq8V5g+EHWbwfqFjhCrppaAiBkOkm8YDRMBqaJwDyKtzL5Ff8GRSWPoNfAzv3XLAhQ=="
-  }
-}

docs/examples/node3/config/config.toml

@@ -1,166 +0,0 @@
-# This is a TOML config file.
-# For more information, see https://github.com/toml-lang/toml
-
-##### main base config options #####
-
-# TCP or UNIX socket address of the ABCI application,
-# or the name of an ABCI application compiled in with the Tendermint binary
-proxy_app = "tcp://127.0.0.1:26658"
-
-# A custom human readable name for this node
-moniker = "delta"
-
-# If this node is many blocks behind the tip of the chain, FastSync
-# allows them to catchup quickly by downloading blocks in parallel
-# and verifying their commits
-fast_sync = true
-
-# Database backend: leveldb | memdb
-db_backend = "leveldb"
-
-# Database directory
-db_path = "data"
-
-# Output level for logging, including package level options
-log_level = "main:info,state:info,*:error"
-
-##### additional base config options #####
-
-# Path to the JSON file containing the initial validator set and other meta data
-genesis_file = "config/genesis.json"
-
-# Path to the JSON file containing the private key to use as a validator in the consensus protocol
-priv_validator_file = "config/priv_validator.json"
-
-# Path to the JSON file containing the private key to use for node authentication in the p2p protocol
-node_key_file = "config/node_key.json"
-
-# Mechanism to connect to the ABCI application: socket | grpc
-abci = "socket"
-
-# TCP or UNIX socket address for the profiling server to listen on
-prof_laddr = ""
-
-# If true, query the ABCI app on connecting to a new peer
-# so the app can decide if we should keep the connection or not
-filter_peers = false
-
-##### advanced configuration options #####
-
-##### rpc server configuration options #####
-[rpc]
-
-# TCP or UNIX socket address for the RPC server to listen on
-laddr = "tcp://0.0.0.0:26657"
-
-# TCP or UNIX socket address for the gRPC server to listen on
-# NOTE: This server only supports /broadcast_tx_commit
-grpc_laddr = ""
-
-# Activate unsafe RPC commands like /dial_seeds and /unsafe_flush_mempool
-unsafe = false
-
-##### peer to peer configuration options #####
-[p2p]
-
-# Address to listen for incoming connections
-laddr = "tcp://0.0.0.0:26656"
-
-# Comma separated list of seed nodes to connect to
-seeds = ""
-
-# Comma separated list of nodes to keep persistent connections to
-# Do not add private peers to this list if you don't want them advertised
-persistent_peers = ""
-
-# Path to address book
-addr_book_file = "config/addrbook.json"
-
-# Set true for strict address routability rules
-addr_book_strict = true
-
-# Time to wait before flushing messages out on the connection, in ms
-flush_throttle_timeout = 100
-
-# Maximum number of peers to connect to
-max_num_peers = 50
-
-# Maximum size of a message packet payload, in bytes
-max_packet_msg_payload_size = 1024
-
-# Rate at which packets can be sent, in bytes/second
-send_rate = 512000
-
-# Rate at which packets can be received, in bytes/second
-recv_rate = 512000
-
-# Set true to enable the peer-exchange reactor
-pex = true
-
-# Seed mode, in which node constantly crawls the network and looks for
-# peers. If another node asks it for addresses, it responds and disconnects.
-#
-# Does not work if the peer-exchange reactor is disabled.
-seed_mode = false
-
-# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
-private_peer_ids = ""
-
-##### mempool configuration options #####
-[mempool]
-
-recheck = true
-recheck_empty = true
-broadcast = true
-wal_dir = "data/mempool.wal"
-
-##### consensus configuration options #####
-[consensus]
-
-wal_file = "data/cs.wal/wal"
-
-# All timeouts are in milliseconds
-timeout_propose = 3000
-timeout_propose_delta = 500
-timeout_prevote = 1000
-timeout_prevote_delta = 500
-timeout_precommit = 1000
-timeout_precommit_delta = 500
-timeout_commit = 1000
-
-# Make progress as soon as we have all the precommits (as if TimeoutCommit = 0)
-skip_timeout_commit = false
-
-# BlockSize
-max_block_size_txs = 10000
-max_block_size_bytes = 1
-
-# EmptyBlocks mode and possible interval between empty blocks in seconds
-create_empty_blocks = true
-create_empty_blocks_interval = 0
-
-# Reactor sleep duration parameters are in milliseconds
-peer_gossip_sleep_duration = 100
-peer_query_maj23_sleep_duration = 2000
-
-##### transactions indexer configuration options #####
-[tx_index]
-
-# What indexer to use for transactions
-#
-# Options:
-#   1) "null" (default)
-#   2) "kv" - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend).
-indexer = "kv"
-
-# Comma-separated list of tags to index (by default the only tag is tx hash)
-#
-# It's recommended to index only a subset of tags due to possible memory
-# bloat. This is, of course, depends on the indexer's DB and the volume of
-# transactions.
-index_tags = ""
-
-# When set to true, tells indexer to index all tags. Note this may be not
-# desirable (see the comment above). IndexTags has a precedence over
-# IndexAllTags (i.e. when given both, IndexTags will be indexed).
-index_all_tags = false

docs/examples/node3/config/genesis.json

@@ -1,39 +0,0 @@
-{
-  "genesis_time": "0001-01-01T00:00:00Z",
-  "chain_id": "test-chain-A2i3OZ",
-  "validators": [
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "D+k4AdjnYPWbB9wmad137Bdpo/kAulOoTRQrLy/Qc4k="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "b56N5GCR1adcVRuENjfKw/mrm2dkhT7wNZXV/SDsKsU="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "IgZDpJvGA0TAamicA8ircy+RX/BkUlj6DXwM791ywIU="
-      },
-      "power": "10",
-      "name": ""
-    },
-    {
-      "pub_key": {
-        "type": "tendermint/PubKeyEd25519",
-        "value": "KGAZfxZvIZ7abbeIQ85U1ECG6+I62KSdaH8ulc0+OiU="
-      },
-      "power": "10",
-      "name": ""
-    }
-  ],
-  "app_hash": ""
-}

docs/examples/node3/config/node_key.json

@@ -1 +0,0 @@
-{"priv_key":{"type":"tendermint/PrivKeyEd25519","value":"9Y9xp/tUJJ6pHTF5SUV0bGKYSdVbFtMHu+Lr8S0JBSZAwneaejnfOEU1LMKOnQ07skrDUaJcj5di3jAyjxJzqg=="}}

docs/examples/node3/config/priv_validator.json

@@ -1,14 +0,0 @@
-{
-  "address": "9A1A6914EB5F4FF0269C7EEEE627C27310CC64F9",
-  "pub_key": {
-    "type": "tendermint/PubKeyEd25519",
-    "value": "KGAZfxZvIZ7abbeIQ85U1ECG6+I62KSdaH8ulc0+OiU="
-  },
-  "last_height": "0",
-  "last_round": "0",
-  "last_step": 0,
-  "priv_key": {
-    "type": "tendermint/PrivKeyEd25519",
-    "value": "jb52LZ5gp+eQ8nJlFK1z06nBMp1gD8ICmyzdM1icGOgoYBl/Fm8hntptt4hDzlTUQIbr4jrYpJ1ofy6VzT46JQ=="
-  }
-}

docs/how-to-read-logs.md

@@ -1,130 +0,0 @@
-# How to read logs
-
-## Walkabout example
-
-We first create three connections (mempool, consensus and query) to the
-application (running `kvstore` locally in this case).
-
-    I[10-04|13:54:27.364] Starting multiAppConn                        module=proxy impl=multiAppConn
-    I[10-04|13:54:27.366] Starting localClient                         module=abci-client connection=query impl=localClient
-    I[10-04|13:54:27.366] Starting localClient                         module=abci-client connection=mempool impl=localClient
-    I[10-04|13:54:27.367] Starting localClient                         module=abci-client connection=consensus impl=localClient
-
-Then Tendermint Core and the application perform a handshake.
-
-    I[10-04|13:54:27.367] ABCI Handshake                               module=consensus appHeight=90 appHash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
-    I[10-04|13:54:27.368] ABCI Replay Blocks                           module=consensus appHeight=90 storeHeight=90 stateHeight=90
-    I[10-04|13:54:27.368] Completed ABCI Handshake - Tendermint and App are synced module=consensus appHeight=90 appHash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
-
-After that, we start a few more things like the event switch, reactors,
-and perform UPNP discover in order to detect the IP address.
-
-    I[10-04|13:54:27.374] Starting EventSwitch                         module=types impl=EventSwitch
-    I[10-04|13:54:27.375] This node is a validator                     module=consensus
-    I[10-04|13:54:27.379] Starting Node                                module=main impl=Node
-    I[10-04|13:54:27.381] Local listener                               module=p2p ip=:: port=26656
-    I[10-04|13:54:27.382] Getting UPNP external address                module=p2p
-    I[10-04|13:54:30.386] Could not perform UPNP discover              module=p2p err="write udp4 0.0.0.0:38238->239.255.255.250:1900: i/o timeout"
-    I[10-04|13:54:30.386] Starting DefaultListener                     module=p2p impl=Listener(@10.0.2.15:26656)
-    I[10-04|13:54:30.387] Starting P2P Switch                          module=p2p impl="P2P Switch"
-    I[10-04|13:54:30.387] Starting MempoolReactor                      module=mempool impl=MempoolReactor
-    I[10-04|13:54:30.387] Starting BlockchainReactor                   module=blockchain impl=BlockchainReactor
-    I[10-04|13:54:30.387] Starting ConsensusReactor                    module=consensus impl=ConsensusReactor
-    I[10-04|13:54:30.387] ConsensusReactor                             module=consensus fastSync=false
-    I[10-04|13:54:30.387] Starting ConsensusState                      module=consensus impl=ConsensusState
-    I[10-04|13:54:30.387] Starting WAL                                 module=consensus wal=/home/vagrant/.tendermint/data/cs.wal/wal impl=WAL
-    I[10-04|13:54:30.388] Starting TimeoutTicker                       module=consensus impl=TimeoutTicker
-
-Notice the second row where Tendermint Core reports that "This node is a
-validator". It also could be just an observer (regular node).
-
-Next we replay all the messages from the WAL.
-
-    I[10-04|13:54:30.390] Catchup by replaying consensus messages      module=consensus height=91
-    I[10-04|13:54:30.390] Replay: New Step                             module=consensus height=91 round=0 step=RoundStepNewHeight
-    I[10-04|13:54:30.390] Replay: Done                                 module=consensus
-
-"Started node" message signals that everything is ready for work.
-
-    I[10-04|13:54:30.391] Starting RPC HTTP server on tcp socket 0.0.0.0:26657 module=rpc-server
-    I[10-04|13:54:30.392] Started node                                 module=main nodeInfo="NodeInfo{id: DF22D7C92C91082324A1312F092AA1DA197FA598DBBFB6526E, moniker: anonymous, network: test-chain-3MNw2N [remote , listen 10.0.2.15:26656], version: 0.11.0-10f361fc ([wire_version=0.6.2 p2p_version=0.5.0 consensus_version=v1/0.2.2 rpc_version=0.7.0/3 tx_index=on rpc_addr=tcp://0.0.0.0:26657])}"
-
-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).
-
-    I[10-04|13:54:30.393] enterNewRound(91/0). Current: 91/0/RoundStepNewHeight module=consensus
-    I[10-04|13:54:30.393] enterPropose(91/0). Current: 91/0/RoundStepNewRound module=consensus
-    I[10-04|13:54:30.393] enterPropose: Our turn to propose            module=consensus proposer=125B0E3C5512F5C2B0E1109E31885C4511570C42 privValidator="PrivValidator{125B0E3C5512F5C2B0E1109E31885C4511570C42 LH:90, LR:0, LS:3}"
-    I[10-04|13:54:30.394] Signed proposal                              module=consensus height=91 round=0 proposal="Proposal{91/0 1:21B79872514F (-1,:0:000000000000) {/10EDEDD7C84E.../}}"
-    I[10-04|13:54:30.397] Received complete proposal block             module=consensus height=91 hash=F671D562C7B9242900A286E1882EE64E5556FE9E
-    I[10-04|13:54:30.397] enterPrevote(91/0). Current: 91/0/RoundStepPropose module=consensus
-    I[10-04|13:54:30.397] enterPrevote: ProposalBlock is valid         module=consensus height=91 round=0
-    I[10-04|13:54:30.398] Signed and pushed vote                       module=consensus height=91 round=0 vote="Vote{0:125B0E3C5512 91/00/1(Prevote) F671D562C7B9 {/89047FFC21D8.../}}" err=null
-    I[10-04|13:54:30.401] Added to prevote                             module=consensus vote="Vote{0:125B0E3C5512 91/00/1(Prevote) F671D562C7B9 {/89047FFC21D8.../}}" prevotes="VoteSet{H:91 R:0 T:1 +2/3:F671D562C7B9242900A286E1882EE64E5556FE9E:1:21B79872514F BA{1:X} map[]}"
-    I[10-04|13:54:30.401] enterPrecommit(91/0). Current: 91/0/RoundStepPrevote module=consensus
-    I[10-04|13:54:30.401] enterPrecommit: +2/3 prevoted proposal block. Locking module=consensus hash=F671D562C7B9242900A286E1882EE64E5556FE9E
-    I[10-04|13:54:30.402] Signed and pushed vote                       module=consensus height=91 round=0 vote="Vote{0:125B0E3C5512 91/00/2(Precommit) F671D562C7B9 {/80533478E41A.../}}" err=null
-    I[10-04|13:54:30.404] Added to precommit                           module=consensus vote="Vote{0:125B0E3C5512 91/00/2(Precommit) F671D562C7B9 {/80533478E41A.../}}" precommits="VoteSet{H:91 R:0 T:2 +2/3:F671D562C7B9242900A286E1882EE64E5556FE9E:1:21B79872514F BA{1:X} map[]}"
-    I[10-04|13:54:30.404] enterCommit(91/0). Current: 91/0/RoundStepPrecommit module=consensus
-    I[10-04|13:54:30.405] Finalizing commit of block with 0 txs        module=consensus height=91 hash=F671D562C7B9242900A286E1882EE64E5556FE9E root=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
-    I[10-04|13:54:30.405] Block{
-      Header{
-        ChainID:        test-chain-3MNw2N
-        Height:         91
-        Time:           2017-10-04 13:54:30.393 +0000 UTC
-        NumTxs:         0
-        LastBlockID:    F15AB8BEF9A6AAB07E457A6E16BC410546AA4DC6:1:D505DA273544
-        LastCommit:     56FEF2EFDB8B37E9C6E6D635749DF3169D5F005D
-        Data:
-        Validators:     CE25FBFF2E10C0D51AA1A07C064A96931BC8B297
-        App:            E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
-      }#F671D562C7B9242900A286E1882EE64E5556FE9E
-      Data{
-
-      }#
-      Commit{
-        BlockID:    F15AB8BEF9A6AAB07E457A6E16BC410546AA4DC6:1:D505DA273544
-        Precommits: Vote{0:125B0E3C5512 90/00/2(Precommit) F15AB8BEF9A6 {/FE98E2B956F0.../}}
-      }#56FEF2EFDB8B37E9C6E6D635749DF3169D5F005D
-    }#F671D562C7B9242900A286E1882EE64E5556FE9E module=consensus
-    I[10-04|13:54:30.408] Executed block                               module=state height=91 validTxs=0 invalidTxs=0
-    I[10-04|13:54:30.410] Committed state                              module=state height=91 txs=0 hash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
-    I[10-04|13:54:30.410] Recheck txs                                  module=mempool numtxs=0 height=91
-
-## List of modules
-
-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
-    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).
--   `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
-    implementation of the consensus algorithm. Includes two
-    "submodules": `wal` (write-ahead logging) for ensuring data
-    integrity and `replay` to replay blocks and messages on recovery
-    from a crash.
--   `events` Simple event notification system. The list of events can be
-    found
-    [here](https://github.com/tendermint/tendermint/blob/master/types/events.go).
-    You can subscribe to them by calling `subscribe` RPC method. Refer
-    to [RPC docs](./specification/rpc.md) for additional information.
--   `mempool` Mempool module handles all incoming transactions, whenever
-    they are coming from peers or the application.
--   `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-server` RPC server. For implementation details, please read the
-    [README](https://github.com/tendermint/tendermint/blob/master/rpc/lib/README.md).
--   `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
-    work with them.

docs/index.rst

@@ -8,7 +8,7 @@ Welcome to Tendermint!
 
 This location for our documentation has been deprecated, please see:
 
-- https://tendermint.com/docs
+- https://tendermint.com/docs/
 
 The last version built by Read The Docs will still be available at:
 

docs/indexing-transactions.md

@@ -1,89 +0,0 @@
-# Indexing Transactions
-
-Tendermint allows you to index transactions and later query or subscribe
-to their results.
-
-Let's take a look at the `[tx_index]` config section:
-
-    ##### transactions indexer configuration options #####
-    [tx_index]
-
-    # What indexer to use for transactions
-    #
-    # Options:
-    #   1) "null" (default)
-    #   2) "kv" - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend).
-    indexer = "kv"
-
-    # Comma-separated list of tags to index (by default the only tag is tx hash)
-    #
-    # It's recommended to index only a subset of tags due to possible memory
-    # bloat. This is, of course, depends on the indexer's DB and the volume of
-    # transactions.
-    index_tags = ""
-
-    # When set to true, tells indexer to index all tags. Note this may be not
-    # desirable (see the comment above). IndexTags has a precedence over
-    # IndexAllTags (i.e. when given both, IndexTags will be indexed).
-    index_all_tags = false
-
-By default, Tendermint will index all transactions by their respective
-hashes using an embedded simple indexer. Note, we are planning to add
-more options in the future (e.g., Postgresql indexer).
-
-## Adding tags
-
-In your application's `DeliverTx` method, add the `Tags` field with the
-pairs of UTF-8 encoded strings (e.g. "account.owner": "Bob", "balance":
-"100.0", "date": "2018-01-02").
-
-Example:
-
-    func (app *KVStoreApplication) DeliverTx(tx []byte) types.Result {
-        ...
-        tags := []cmn.KVPair{
-          {[]byte("account.name"), []byte("igor")},
-          {[]byte("account.address"), []byte("0xdeadbeef")},
-          {[]byte("tx.amount"), []byte("7")},
-        }
-        return types.ResponseDeliverTx{Code: code.CodeTypeOK, Tags: tags}
-    }
-
-If you want Tendermint to only index transactions by "account.name" tag,
-in the config set `tx_index.index_tags="account.name"`. If you to index
-all tags, set `index_all_tags=true`
-
-Note, there are a few predefined tags:
-
--   `tm.event` (event type)
--   `tx.hash` (transaction's hash)
--   `tx.height` (height of the block transaction was committed in)
-
-Tendermint will throw a warning if you try to use any of the above keys.
-
-## Querying transactions
-
-You can query the transaction results by calling `/tx_search` RPC
-endpoint:
-
-    curl "localhost:26657/tx_search?query=\"account.name='igor'\"&prove=true"
-
-Check out [API docs](https://tendermint.github.io/slate/?shell#txsearch)
-for more information on query syntax and other options.
-
-## Subscribing to transactions
-
-Clients can subscribe to transactions with the given tags via Websocket
-by providing a query to `/subscribe` RPC endpoint.
-
-    {
-        "jsonrpc": "2.0",
-        "method": "subscribe",
-        "id": "0",
-        "params": {
-            "query": "account.name='igor'"
-        }
-    }
-
-Check out [API docs](https://tendermint.github.io/slate/#subscribe) for
-more information on query syntax and other options.

docs/interviews/tendermint-bft.md

@@ -0,0 +1,250 @@
+# Interview Transcript with Tendermint core researcher, Zarko Milosevic, by Chjango
+
+**ZM**: Regarding leader election, it's round robin, but a weighted one. You
+take into account the amount of bonded tokens. Depending on how much weight
+they have of voting power, they would be elected more frequently. So we do
+rotate, but just the guys who are having more voting power would be elected
+more frequently. We are having 4 validators, and 1 of them have 2 times more
+voting power, they have 2 times more elected as a leader.
+
+**CC**: 2x more absolute voting power or probabilistic voting power?
+
+**ZM**: It's actually very deterministic. It's not probabilistic at all. See
+[Tendermint proposal election specification][1]. In Tendermint, there is no
+pseudorandom leader election. It's a deterministic protocol. So leader election
+is a built-in function in the code, so you know exactly—depending on the voting
+power in the validator set, you'd know who exactly would be the leader in round
+x, x + 1, and so on. There is nothing random there; we are not trying to hide
+who would be the leader. It's really well known. It's just that there is a
+function, it's a mathematical function, and it's just basically—it's kind of an
+implementation detail—it starts from the voting power, and when you are
+elected, you get decreased some number, and in each round you keep increasing
+depending on your voting power, so that you are elected after k rounds again.
+But knowing the validator set and the voting power, it's very simple function,
+you can calculate yourself to know exactly who would be next. For each round,
+this function will return you the leader for that round. In every round, we do
+this computation. It's all part of the same flow. It enforces the properties
+which are: proportional to your voting power, you will be elected, and we keep
+changing the leaders. So it can't happen to have one guy being more elected
+than other guys, if they have the same voting power. So one time it will be guy
+B, and next time it will be guy B1. So it's not random.
+
+**CC**: Assuming the validator set remains unchanged for a month, then if you
+run this function, are you able to know exactly who is going to go for that
+entire month?
+
+**ZM**: Yes.
+
+**CC**: What're the attack scenarios for this?
+
+**ZM**: This is something which is easily attacked by people who argue that
+Tendermint is not decentralized enough. They say that by knowing the leader,
+you can DDoS the leader. And by DDoSing the leader, you are able to stop the
+progress. Because it's true. If you would be able to DDoS the leader, the
+leader would not be able to propose and then effectively will not be making
+progress. How we are addressing this thing is Sentry Architecture. So the
+validator—or at least a proper validator—will never be available. You don't
+know the ip address of the validator. You are never able to open the connection
+to the validator. So validator is spawning sentry nodes and this is the single
+administration domain and there is only connection from validator in the sense
+of sentry nodes. And ip address of validator is not shared in the p2p network.
+It’s completely private. This is our answer to DDoS attack. By playing clever
+at this sentry node architecture and spawning additional sentry nodes in case,
+for ex your sentry nodes are being DDoS’d, bc your sentry nodes are public,
+then you will be able to connect to sentry nodes. this is where we will expect
+the validator to be clever enough that so that in case they are DDoS’d at the
+sentry level, they will spawn a different sentry node and then you communicate
+through them. We are in a sense pushing the responsibility on the validator.
+
+**CC**: So if I understand this correctly, the public identity of the validator
+doesn’t even matter because that entity can obfuscate where their real full
+nodes reside via a proxy through this sentry architecture.
+
+**ZM**: Exactly. So you do know what is the address or identity of the validator
+but you don’t know the network address of it; you’re not able to attack it
+because you don’t know where they are. They are completely obfuscated by the
+sentry nodes. There is now, if you really want to figure out….There is the
+Tendermint protocol, the structure of the protocol is not fully decentralized
+in the sense that the flow of information is going from the round proposer, or
+the round coordinator, to other nodes, and then after they receive this it’s
+basically like [inaudible: “O to 1”]. So by tracking where this information is
+coming from, you might be able to identify who are the sentry nodes behind it.
+So if you are doing some network analysis, you might be able to deduce
+something. If the thing would be completely stuck, where the validator would
+never change their sentry nodes or ip addresses of sentry nodes, it could be
+possible to deduce something. This is where economic game comes into play. We
+are doing an economics game there. We say that it’s a validator business. If
+they are not able to hide themselves well enough, they’ll be DDoS’d and they
+will be kicked out of the active validator set. So it’s in their interest.
+
+[Proposer Selection Procedure in Tendermint][1]. This is how it should work no
+matter what implementation.
+
+**CC**: Going back to the proposer, lets say the validator does get DDoS’d, then
+the proposer goes down. What happens?
+
+**ZM**: How the proposal mechanism works—there’s nothing special there—it goes
+through a sequence of rounds. Normal execution of Tendermint is that for each
+height, we are going through a sequence of rounds, starting from round 0, and
+then we are incrementing through the rounds. The nodes are moving through the
+rounds as part of normal procedure until they decide to commit. In case you
+have one proposer—the proposer of a single round—being DDoS’d, we will probably
+not decide in that round, because he will not be able to send his proposal. So
+we will go to the next round, and hopefully the next proposer will be able to
+communicate with the validators and then we’ll decide in the next round.
+
+**CC**: Are there timeouts between one round to another, if a round gets
+skipped?
+
+**ZM**: There are timeouts. It’s a bit more complex. I think we have 5 timeouts.
+We may be able to simplify this a bit. What is important to understand is: The
+only condition which needs to be satisfied so we can go to the next round is
+that your validator is able to communicate with more than 2/3rds of voting
+power. To be able to move to the next round, you need to receive more than
+2/3rd of voting power equivalent of pre-commit messages.
+
+We have two kinds of messages: 1) Proposal: Where the current round proposer is
+suggesting how the next block should look like. This is first one. Every round
+starts with proposer sending a proposal. And then there are two more rounds of
+voting, where the validator is trying to agree whether they will commit the
+proposal or not. And the first of such vote messages is called `pre-vote` and
+the second one is `pre-commit`. Now, to be able to move between steps, between
+a `pre-vote` and `pre-commit` step, you need to receive enough number of
+messages where if message is sent by validator A, then also this message has a
+weight, or voting power which is equal to the voting power of the validator who
+sent this message. Before you receive more than 2/3 of voting power messages, you are not
+able to move to the higher round. Only when you receive more than 2/3 of
+messages, you actually start the timeout. The timeout is happening only after
+you receive enough messages. And it happens because of the asynchrony of the
+message communication so you give more time to guys with this timeout to
+receive some messages which are maybe delayed.
+
+**CC**: In this way that you just described via the whole network gossiping
+before we commit a block, that is what makes Tendermint BFT deterministic in a
+partially synchronous setting vs Bitcoin which has synchrony assumptions
+whereby blocks are first mined and then gossiped to the network.
+
+**ZM**: It's true that in Bitcoin, this is where the synchrony assumption comes
+to play because if they're not able to communicate timely, they are not able to
+converge to a single longest chain. Why are they not able to decrease timeout
+in Bitcoin? Because if they would decrease, there would be so many forks that
+they won't be able to converge to a single chain. By increasing this
+complexity and the block time, they're able to have not so many forks. This is
+effectively the timing assumption—the block duration in a sense because it's
+enough time so that the decided block is propagated through the network before
+someone else start deciding on the same block and creating forks. It's very
+different from the consensus algorithms in a distributed computing setup where
+Tendermint fits. In Tendermint, where we talk about the timing dependency, they
+are really part of this 3-communication step protocol I just explained. We have
+the following assumption: If the good guys are not able to communicate timely
+and reliably without having message loss within a round, the Tendermint will
+not make progress—it will not be making blocks. So if you are in a completely
+asynchronous network where messages get lost or delayed unpredictably,
+Tendermint will not make progress, it will not create forks, but it will not
+decide, it will not tell you what is the next block. For termination, it's a
+liveness property of consensus. It's a guarantee to decide. We do need timing
+assumptions. Within a round, correct validators are able to communicate to each
+other the consensus messages, not the transactions, but consensus messages.
+They need to communicate in a timely and reliable fashion. But this doesn't
+need to hold forever. It's just that what we are assuming when we say it's a
+partially synchronous system, we assume that the system will be going through a
+period of asynchrony, where we don't have this guarantee; the messages will be
+delayed or some will be lost and then will not make progress for some period of
+time, or we're not guaranteed to make progress. And the period of synchrony
+where these guarantees hold. And if we think about internet, internet is best
+described using such a model. Sometimes when we send a message to SF to
+Belgrade, it takes 100 ms, sometimes it takes 300 ms, sometimes it takes 1 s.
+But in most cases, it takes 100 ms or less than this.
+
+There is one thing which would be really nice if you understand it. In a global
+wide area network, we can't make assumption on the communication unless we are
+very conservative about this. If you want to be very fast, then we can't make
+assumption and say we'll be for sure communicating with 1 ms communication
+delay. Because of the complexity and various congestion issues on the network,
+it might happen that during a short period of time, this doesn't hold. If this
+doesn't hold and you depend on this for correctness of your protocol, you will
+have a fork. So the partially synchronous protocol, most of them like
+Tendermint, they don't depend on the timing assumption from the internet for
+correctness. This is where we state: safety always. So we never make a fork no
+matter how bad our estimates about the internet communication delays are. We'll
+never make a fork, but we do make some assumptions, and these assumptions are
+built-in our timeouts in our protocol which are actually adaptive. So we are
+adapting to the current condition and this is where we're saying...We do assume
+some properties, or some communication delays, to eventually hold on the
+network. During this period, we guarantee that we will be deciding and
+committing blocks. And we will be doing this very fast. We will be basically on
+the speed of the current network.
+
+**CC**: We make liveness assumptions based on the integrity of the validator
+businesses, assuming they're up and running fine.
+
+**ZM**: This is where we are saying, the protocol will be live if we have at
+most 1/3, or a bit less than 1/3, of faulty validators. Which means that all
+other guys should be online and available. This is also for liveness. This is
+related to the condition that we are not able to make progress in rounds if we
+don't receive enough messages. If half of our voting power, or half of our
+validators are down, we don't have enough messages, so the protocol is
+completely blocked. It doesn't make progress in a round, which means it's not
+able to be signed. So it's completely critical for Tendermint that we make
+progress in rounds. It's like breathing. Tendermint is breathing. If there is
+no progress, it's dead; it's blocked, we're not able to breathe, that's why
+we're not able to make progress.
+
+**CC**: How does Tendermint compare to other consensus algos?
+
+**ZM**: Tendermint is a very interesting protocol. From an academic point of
+view, I'm convinced that there is value there. Hopefully, we prove it by
+publishing it on some good conference. What is novel is, if we compare first
+Tendermint to this existing BFT problem, it's a continuation of academic
+research on BFT consensus. What is novel in Tendermint is that it somehow
+merges consensus protocol with gossip. This is completely novel idea.
+Originally, in BFT, people were assuming the single administration domain,
+small number of nodes, local area network, 4-7 nodes max. If you look at the
+research paper, 99% of them have this kind of setup. Wide area was studied but
+there is significantly less work in wide area networks. No one studied how to
+scale those protocols to hundreds or thousands of nodes before blockchain. It
+was always a single administration domain. So in Tendermint now, you are able
+to reach consensus among different administration domains which are potentially
+hundreds of them in wide area network. The system model is potentially harder
+because we have more nodes and wide area network. The second thing is that:
+normally, in bft protocols, the protocol itself are normally designed in a way
+that has two phases, or two parts. The one which is called normal case, which
+is normally quite simple, in this normal case. In spite of some failures, which
+are part of the normal execution of the protocol, like for example leader
+crashes or leader being DDoS'd, they need to go through a quite complex
+protocol, which is like being called view change or leader election or
+whatever. These two parts of the same protocol are having quite different
+complexity. And most of the people only understand this normal case. In
+Tendermint, there is no this difference. We have only one protocol, there are
+not two protocols. It's always the same steps and they are much closer to the
+normal case than this complex view change protocol.
+
+_This is a bit too technical but this is on a high level things to remember,
+that: The system it addresses it's harder than the others and the algorithm
+complexity in Tendermint is simpler._ The initial goal of Jae and Bucky which
+is inspired by Raft, is that it's simpler so normal engineers could understand.
+
+**CC**: Can you expand on the termination requirement?
+
+_Important point about Liveness in Tendermint_
+
+**ZM**: In Tendermint, we are saying, for termination, we are making assumption
+that the system is partially synchronous. And in a partially synchronous system
+model, we are able to mathematically prove that the protocol will make
+decisions; it will decide.
+
+**CC**: What is a persistent peer?
+
+**ZM**: It's a list of peer identities, which you will try to establish
+connection to them, in case connection is broken, Tendermint will automatically
+try to reestablish connection. These are important peers, you will really try
+persistently to establish connection to them. For other peers, you just drop it
+and try from your address book to connect to someone else. The address book is a
+list of peers which you discover that they exist, because we are talking about a
+very dynamic network—so the nodes are coming and going away—and the gossiping
+protocol is discovering new nodes and gossiping them around. So every node will
+keep the list of new nodes it discovers, and when you need to establish
+connection to a peer, you'll look to address book and get some addresses from
+there. There's categorization/ranking of nodes there.
+
+[1]: https://github.com/tendermint/tendermint/blob/master/docs/spec/reactors/consensus/proposer-selection.md

docs/introduction/install.md

@@ -57,7 +57,7 @@ cd $GOPATH/src/github.com/tendermint/tendermint
 make install
 ```
 
-To upgrade, run 
+To upgrade, run
 
 ```
 cd $GOPATH/src/github.com/tendermint/tendermint

docs/introduction/introduction.md

@@ -61,13 +61,14 @@ providing basic services to distributed systems, such as dynamic
 configuration, service discovery, locking, leader-election, and so on.
 
 Tendermint is in essence similar software, but with two key differences:
+
 - It is Byzantine Fault Tolerant, meaning it can only tolerate up to a
-1/3 of failures, but those failures can include arbitrary behaviour -
-including hacking and malicious attacks. - It does not specify a
-particular application, like a fancy key-value store. Instead, it
-focuses on arbitrary state machine replication, so developers can build
-the application logic that's right for them, from key-value store to
-cryptocurrency to e-voting platform and beyond.
+  1/3 of failures, but those failures can include arbitrary behaviour -
+  including hacking and malicious attacks. - It does not specify a
+  particular application, like a fancy key-value store. Instead, it
+  focuses on arbitrary state machine replication, so developers can build
+  the application logic that's right for them, from key-value store to
+  cryptocurrency to e-voting platform and beyond.
 
 The layout of this Tendermint website content is also ripped directly
 and without shame from [consul.io](https://www.consul.io/) and the other
@@ -167,16 +168,16 @@ maintains a fully audited Unspent Transaction Output (UTXO) database. If
 one wanted to create a Bitcoin-like system on top of ABCI, Tendermint
 Core would be responsible for
 
--   Sharing blocks and transactions between nodes
--   Establishing a canonical/immutable order of transactions
-    (the blockchain)
+- Sharing blocks and transactions between nodes
+- Establishing a canonical/immutable order of transactions
+  (the blockchain)
 
 The application will be responsible for
 
--   Maintaining the UTXO database
--   Validating cryptographic signatures of transactions
--   Preventing transactions from spending non-existent transactions
--   Allowing clients to query the UTXO database.
+- Maintaining the UTXO database
+- Validating cryptographic signatures of transactions
+- Preventing transactions from spending non-existent transactions
+- Allowing clients to query the UTXO database.
 
 Tendermint is able to decompose the blockchain design by offering a very
 simple API (ie. the ABCI) between the application process and consensus
@@ -242,14 +243,14 @@ Java, C++, Python, or Go. Game programmers and blockchain developers are
 already familiar with creating deterministic programs by avoiding
 sources of non-determinism such as:
 
--   random number generators (without deterministic seeding)
--   race conditions on threads (or avoiding threads altogether)
--   the system clock
--   uninitialized memory (in unsafe programming languages like C
-    or C++)
--   [floating point
-    arithmetic](http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/)
--   language features that are random (e.g. map iteration in Go)
+- random number generators (without deterministic seeding)
+- race conditions on threads (or avoiding threads altogether)
+- the system clock
+- uninitialized memory (in unsafe programming languages like C
+  or C++)
+- [floating point
+  arithmetic](http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/)
+- language features that are random (e.g. map iteration in Go)
 
 While programmers can avoid non-determinism by being careful, it is also
 possible to create a special linter or static analyzer for each language
@@ -298,8 +299,8 @@ introduces a few **locking** rules which modulate which paths can be
 followed in the flow diagram. Once a validator precommits a block, it is
 locked on that block. Then,
 
-1)  it must prevote for the block it is locked on
-2)  it can only unlock, and precommit for a new block, if there is a
+1.  it must prevote for the block it is locked on
+2.  it can only unlock, and precommit for a new block, if there is a
     polka for that block in a later round
 
 ## Stake

docs/introduction/quick-start.md

@@ -3,17 +3,16 @@
 ## Overview
 
 This is a quick start guide. If you have a vague idea about how Tendermint
-works and want to get started right away, continue. Otherwise, [review the
-documentation](http://tendermint.readthedocs.io/en/master/).
+works and want to get started right away, continue.
 
 ## Install
 
 ### Quick Install
 
-On a fresh Ubuntu 16.04 machine can be done with [this script](https://git.io/vpgEI), like so:
+On a fresh Ubuntu 16.04 machine can be done with [this script](https://git.io/fFfOR), like so:
 
 ```
-curl -L https://git.io/vpgEI | bash
+curl -L https://git.io/fFfOR | bash
 source ~/.profile
 ```
 
@@ -24,6 +23,7 @@ The script is also used to facilitate cluster deployment below.
 ### Manual Install
 
 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)
@@ -43,7 +43,7 @@ Confirm installation:
 
 ```
 $ tendermint version
-0.18.0-XXXXXXX
+0.23.0-dev
 ```
 
 ## Initialization
@@ -122,22 +122,22 @@ First create four Ubuntu cloud machines. The following was tested on Digital
 Ocean Ubuntu 16.04 x64 (3GB/1CPU, 20GB SSD). We'll refer to their respective IP
 addresses below as IP1, IP2, IP3, IP4.
 
-Then, `ssh` into each machine, and execute [this script](https://git.io/vNLfY):
+Then, `ssh` into each machine, and execute [this script](https://git.io/fFfOR):
 
 ```
-curl -L https://git.io/vpgEI | bash
+curl -L https://git.io/fFfOR | bash
 source ~/.profile
 ```
 
 This will install `go` and other dependencies, get the Tendermint source code, then compile the `tendermint` binary.
 
-Next, `cd` into `docs/examples`. Each command below should be run from each node, in sequence:
+Next, use the `tendermint testnet` command to create four directories of config files (found in `./mytestnet`) and copy each directory to the relevant machine in the cloud, so that each machine has `$HOME/mytestnet/node[0-3]` directory. Then from each machine, run:
 
 ```
-tendermint node --home ./node0 --proxy_app=kvstore --p2p.persistent_peers="167b80242c300bf0ccfb3ced3dec60dc2a81776e@IP1:26656,3c7a5920811550c04bf7a0b2f1e02ab52317b5e6@IP2:26656,303a1a4312c30525c99ba66522dd81cca56a361a@IP3:26656,b686c2a7f4b1b46dca96af3a0f31a6a7beae0be4@IP4:26656"
-tendermint node --home ./node1 --proxy_app=kvstore --p2p.persistent_peers="167b80242c300bf0ccfb3ced3dec60dc2a81776e@IP1:26656,3c7a5920811550c04bf7a0b2f1e02ab52317b5e6@IP2:26656,303a1a4312c30525c99ba66522dd81cca56a361a@IP3:26656,b686c2a7f4b1b46dca96af3a0f31a6a7beae0be4@IP4:26656"
-tendermint node --home ./node2 --proxy_app=kvstore --p2p.persistent_peers="167b80242c300bf0ccfb3ced3dec60dc2a81776e@IP1:26656,3c7a5920811550c04bf7a0b2f1e02ab52317b5e6@IP2:26656,303a1a4312c30525c99ba66522dd81cca56a361a@IP3:26656,b686c2a7f4b1b46dca96af3a0f31a6a7beae0be4@IP4:26656"
-tendermint node --home ./node3 --proxy_app=kvstore --p2p.persistent_peers="167b80242c300bf0ccfb3ced3dec60dc2a81776e@IP1:26656,3c7a5920811550c04bf7a0b2f1e02ab52317b5e6@IP2:26656,303a1a4312c30525c99ba66522dd81cca56a361a@IP3:26656,b686c2a7f4b1b46dca96af3a0f31a6a7beae0be4@IP4:26656"
+tendermint node --home ./mytestnet/node0 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656"
+tendermint node --home ./mytestnet/node1 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656"
+tendermint node --home ./mytestnet/node2 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656"
+tendermint node --home ./mytestnet/node3 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656"
 ```
 
 Note that after the third node is started, blocks will start to stream in

docs/networks/deploy-testnets.md

@@ -0,0 +1,74 @@
+# Deploy a Testnet
+
+Now that we've seen how ABCI works, and even played with a few
+applications on a single validator node, it's time to deploy a test
+network to four validator nodes.
+
+## Manual Deployments
+
+It's relatively easy to setup a Tendermint cluster manually. The only
+requirements for a particular Tendermint node are a private key for the
+validator, stored as `priv_validator.json`, a node key, stored as
+`node_key.json` and a list of the public keys of all validators, stored
+as `genesis.json`. These files should be stored in
+`~/.tendermint/config`, or wherever the `$TMHOME` variable might be set
+to.
+
+Here are the steps to setting up a testnet manually:
+
+1.  Provision nodes on your cloud provider of choice
+2.  Install Tendermint and the application of interest on all nodes
+3.  Generate a private key and a node key for each validator using
+    `tendermint init`
+4.  Compile a list of public keys for each validator into a
+    `genesis.json` file and replace the existing file with it.
+5.  Run
+    `tendermint node --proxy_app=kvstore --p2p.persistent_peers=< peer addresses >` on each node, where `< peer addresses >` is a comma separated
+    list of the ID@IP:PORT combination for each node. The default port for
+    Tendermint is `26656`. The ID of a node can be obtained by running
+    `tendermint show_node_id` command. Thus, if the IP addresses of your nodes
+    were `192.168.0.1, 192.168.0.2, 192.168.0.3, 192.168.0.4`, the command
+    would look like:
+
+```
+tendermint node --proxy_app=kvstore --p2p.persistent_peers=96663a3dd0d7b9d17d4c8211b191af259621c693@192.168.0.1:26656, 429fcf25974313b95673f58d77eacdd434402665@192.168.0.2:26656, 0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@192.168.0.3:26656, f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@192.168.0.4:26656
+```
+
+After a few seconds, all the nodes should connect to each other and
+start making blocks! For more information, see the Tendermint Networks
+section of [the guide to using Tendermint](./using-tendermint.md).
+
+But wait! Steps 3, 4 and 5 are quite manual. Instead, use the `tendermint testnet` command. By default, running `tendermint testnet` will create all the
+required files, but it won't populate the list of persistent peers. It will do
+it however if you provide the `--populate-persistent-peers` flag and optional
+`--starting-ip-address` flag. Run `tendermint testnet --help` for more details
+on the available flags.
+
+```
+tendermint testnet --populate-persistent-peers --starting-ip-address 192.168.0.1
+```
+
+This command will generate four folders, prefixed with "node" and put them into
+the "./mytestnet" directory by default.
+
+As you might imagine, this command is useful for manual or automated
+deployments.
+
+## Automated Deployments
+
+The easiest and fastest way to get a testnet up in less than 5 minutes.
+
+### Local
+
+With `docker` and `docker-compose` installed, run the command:
+
+```
+make localnet-start
+```
+
+from the root of the tendermint repository. This will spin up a 4-node
+local testnet. Review the target in the Makefile to debug any problems.
+
+### Cloud
+
+See the [next section](./terraform-and-ansible.html) for details.

docs/networks/fast-sync.md

@@ -1,8 +1,4 @@
-Fast Sync
-=========
-
-Background
-----------
+# Fast Sync
 
 In a proof of work blockchain, syncing with the chain is the same
 process as staying up-to-date with the consensus: download blocks, and
@@ -14,21 +10,19 @@ scratch can take a very long time. It's much faster to just download
 blocks and check the merkle tree of validators than to run the real-time
 consensus gossip protocol.
 
-Fast Sync
----------
+## Using Fast Sync
 
-To support faster syncing, tendermint offers a ``fast-sync`` mode, which
-is enabled by default, and can be toggled in the ``config.toml`` or via
-``--fast_sync=false``.
+To support faster syncing, tendermint offers a `fast-sync` mode, which
+is enabled by default, and can be toggled in the `config.toml` or via
+`--fast_sync=false`.
 
 In this mode, the tendermint daemon will sync hundreds of times faster
 than if it used the real-time consensus process. Once caught up, the
 daemon will switch out of fast sync and into the normal consensus mode.
-After running for some time, the node is considered ``caught up`` if it
+After running for some time, the node is considered `caught up` if it
 has at least one peer and it's height is at least as high as the max
-reported peer height. See `the IsCaughtUp
-method <https://github.com/tendermint/tendermint/blob/b467515719e686e4678e6da4e102f32a491b85a0/blockchain/pool.go#L128>`__.
+reported peer height. See [the IsCaughtUp
+method](https://github.com/tendermint/tendermint/blob/b467515719e686e4678e6da4e102f32a491b85a0/blockchain/pool.go#L128).
 
 If we're lagging sufficiently, we should go back to fast syncing, but
-this is an open issue:
-https://github.com/tendermint/tendermint/issues/129
+this is an [open issue](https://github.com/tendermint/tendermint/issues/129).

docs/networks/terraform-and-ansible.md

@@ -12,17 +12,17 @@ script](https://github.com/tendermint/tendermint/blob/develop/networks/remote/in
 that can be run on a fresh DO droplet and will automatically spin up a 4
 node testnet. The script more or less does everything described below.
 
--   Install [Terraform](https://www.terraform.io/downloads.html) and
-    [Ansible](http://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html)
-    on a Linux machine.
--   Create a [DigitalOcean API
-    token](https://cloud.digitalocean.com/settings/api/tokens) with read
-    and write capability.
--   Install the python dopy package (`pip install dopy`)
--   Create SSH keys (`ssh-keygen`)
--   Set environment variables:
+- Install [Terraform](https://www.terraform.io/downloads.html) and
+  [Ansible](http://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html)
+  on a Linux machine.
+- Create a [DigitalOcean API
+  token](https://cloud.digitalocean.com/settings/api/tokens) with read
+  and write capability.
+- Install the python dopy package (`pip install dopy`)
+- Create SSH keys (`ssh-keygen`)
+- Set environment variables:
 
-```    
+```
 export DO_API_TOKEN="abcdef01234567890abcdef01234567890"
 export SSH_KEY_FILE="$HOME/.ssh/id_rsa.pub"
 ```
@@ -44,6 +44,7 @@ then:
 terraform init
 terraform apply -var DO_API_TOKEN="$DO_API_TOKEN" -var SSH_KEY_FILE="$SSH_KEY_FILE"
 ```
+
 and you will get a list of IP addresses that belong to your droplets.
 
 With the droplets created and running, let's setup Ansible.
@@ -154,7 +155,7 @@ page](https://app.logz.io/#/dashboard/data-sources/Filebeat), then:
 ```
 yum install systemd-devel || echo "This will only work on RHEL-based systems."
 apt-get install libsystemd-dev || echo "This will only work on Debian-based systems."
-    
+
 go get github.com/mheese/journalbeat
 ansible-playbook -i inventory/digital_ocean.py -l sentrynet logzio.yml -e LOGZIO_TOKEN=ABCDEFGHIJKLMNOPQRSTUVWXYZ012345
 ```

docs/package.json

@@ -0,0 +1,37 @@
+{
+  "dependencies": {
+    "prettier": "^1.13.7",
+    "remark-cli": "^5.0.0",
+    "remark-lint-no-dead-urls": "^0.3.0",
+    "textlint": "^10.2.1"
+  },
+  "name": "tendermint",
+  "description": "Tendermint Core Documentation",
+  "version": "0.0.1",
+  "main": "README.md",
+  "devDependencies": {},
+  "scripts": {
+    "lint:json": "prettier \"**/*.json\" --write",
+    "lint:md": "prettier \"**/*.md\" --write && remark . && textlint \"md/**\"",
+    "lint": "yarn lint:json && yarn lint:md"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/tendermint/tendermint.git"
+  },
+  "keywords": [
+    "tendermint",
+    "blockchain"
+  ],
+  "author": "Tendermint",
+  "license": "ISC",
+  "bugs": {
+    "url": "https://github.com/tendermint/tendermint/issues"
+  },
+  "homepage": "https://tendermint.com/docs/",
+  "remarkConfig": {
+    "plugins": [
+      "remark-lint-no-dead-urls"
+    ]
+  }
+}

docs/spec/blockchain/encoding.md

@@ -149,7 +149,33 @@ func MakeParts(obj interface{}, partSize int) []Part
 
 ## Merkle Trees
 
-Simple Merkle trees are used in numerous places in Tendermint to compute a cryptographic digest of a data structure.
+For an overview of Merkle trees, see
+[wikipedia](https://en.wikipedia.org/wiki/Merkle_tree)
+
+
+A Simple Tree is a simple compact binary tree for a static list of items. Simple Merkle trees are used in numerous places in Tendermint to compute a cryptographic digest of a data structure. In a Simple Tree, the transactions and validation signatures of a block are hashed using this simple merkle tree logic.
+
+If the number of items is not a power of two, the tree will not be full
+and some leaf nodes will be at different levels. Simple Tree tries to
+keep both sides of the tree the same size, but the left side may be one
+greater, for example: 
+
+```
+   Simple Tree with 6 items           Simple Tree with 7 items 
+                                                        
+              *                                  *             
+             / \                                / \            
+           /     \                            /     \          
+         /         \                        /         \        
+       /             \                    /             \      
+      *               *                  *               *     
+     / \             / \                / \             / \    
+    /   \           /   \              /   \           /   \   
+   /     \         /     \            /     \         /     \  
+  *       h2      *       h5         *       *       *       h6
+ / \             / \                / \     / \     / \        
+h0  h1          h3  h4             h0  h1  h2  h3  h4  h5
+```
 
 Tendermint always uses the `TMHASH` hash function, which is the first 20-bytes
 of the SHA256:
@@ -235,6 +261,18 @@ func computeHashFromAunts(index, total int, leafHash []byte, innerHashes [][]byt
 }
 ```
 
+### Simple Tree with Dictionaries
+
+The Simple Tree is used to merkelize a list of items, so to merkelize a
+(short) dictionary of key-value pairs, encode the dictionary as an
+ordered list of ``KVPair`` structs. The block hash is such a hash
+derived from all the fields of the block ``Header``. The state hash is
+similarly derived.
+
+### IAVL+ Tree
+
+Because Tendermint only uses a Simple Merkle Tree, application developers are expect to use their own Merkle tree in their applications. For example, the IAVL+ Tree - an immutable self-balancing binary tree for persisting application state is used by the [Cosmos SDK](https://github.com/cosmos/cosmos-sdk/blob/develop/docs/core/multistore.md)
+
 ## JSON
 
 ### Amino

docs/spec/consensus/consensus.md

@@ -1,9 +1,329 @@
-We are working to finalize an updated Tendermint specification with formal
-proofs of safety and liveness.
+# Byzantine Consensus Algorithm
 
-In the meantime, see the [description in the
-docs](http://tendermint.readthedocs.io/en/master/specification/byzantine-consensus-algorithm.html).
+## Terms
 
-There are also relevant but somewhat outdated descriptions in Jae Kwon's [original
-whitepaper](https://tendermint.com/static/docs/tendermint.pdf) and Ethan Buchman's [master's
-thesis](https://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769).
+-   The network is composed of optionally connected *nodes*. Nodes
+    directly connected to a particular node are called *peers*.
+-   The consensus process in deciding the next block (at some *height*
+    `H`) is composed of one or many *rounds*.
+-   `NewHeight`, `Propose`, `Prevote`, `Precommit`, and `Commit`
+    represent state machine states of a round. (aka `RoundStep` or
+    just "step").
+-   A node is said to be *at* a given height, round, and step, or at
+    `(H,R,S)`, or at `(H,R)` in short to omit the step.
+-   To *prevote* or *precommit* something means to broadcast a [prevote
+    vote](https://godoc.org/github.com/tendermint/tendermint/types#Vote)
+    or [first precommit
+    vote](https://godoc.org/github.com/tendermint/tendermint/types#FirstPrecommit)
+    for something.
+-   A vote *at* `(H,R)` is a vote signed with the bytes for `H` and `R`
+    included in its [sign-bytes](block-structure.html#vote-sign-bytes).
+-   *+2/3* is short for "more than 2/3"
+-   *1/3+* is short for "1/3 or more"
+-   A set of +2/3 of prevotes for a particular block or `<nil>` at
+    `(H,R)` is called a *proof-of-lock-change* or *PoLC* for short.
+
+## State Machine Overview
+
+At each height of the blockchain a round-based protocol is run to
+determine the next block. Each round is composed of three *steps*
+(`Propose`, `Prevote`, and `Precommit`), along with two special steps
+`Commit` and `NewHeight`.
+
+In the optimal scenario, the order of steps is:
+
+```
+NewHeight -> (Propose -> Prevote -> Precommit)+ -> Commit -> NewHeight ->...
+```
+
+The sequence `(Propose -> Prevote -> Precommit)` is called a *round*.
+There may be more than one round required to commit a block at a given
+height. Examples for why more rounds may be required include:
+
+-   The designated proposer was not online.
+-   The block proposed by the designated proposer was not valid.
+-   The block proposed by the designated proposer did not propagate
+    in time.
+-   The block proposed was valid, but +2/3 of prevotes for the proposed
+    block were not received in time for enough validator nodes by the
+    time they reached the `Precommit` step. Even though +2/3 of prevotes
+    are necessary to progress to the next step, at least one validator
+    may have voted `<nil>` or maliciously voted for something else.
+-   The block proposed was valid, and +2/3 of prevotes were received for
+    enough nodes, but +2/3 of precommits for the proposed block were not
+    received for enough validator nodes.
+
+Some of these problems are resolved by moving onto the next round &
+proposer. Others are resolved by increasing certain round timeout
+parameters over each successive round.
+
+## State Machine Diagram
+
+```
+                         +-------------------------------------+
+                         v                                     |(Wait til `CommmitTime+timeoutCommit`)
+                   +-----------+                         +-----+-----+
+      +----------> |  Propose  +--------------+          | NewHeight |
+      |            +-----------+              |          +-----------+
+      |                                       |                ^
+      |(Else, after timeoutPrecommit)         v                |
++-----+-----+                           +-----------+          |
+| Precommit |  <------------------------+  Prevote  |          |
++-----+-----+                           +-----------+          |
+      |(When +2/3 Precommits for block found)                  |
+      v                                                        |
++--------------------------------------------------------------------+
+       |  Commit                                                            |
+       |                                                                    |
+       |  * Set CommitTime = now;                                           |
+       |  * Wait for block, then stage/save/commit block;                   |
+       +--------------------------------------------------------------------+
+```
+
+Background Gossip
+=================
+
+A node may not have a corresponding validator private key, but it
+nevertheless plays an active role in the consensus process by relaying
+relevant meta-data, proposals, blocks, and votes to its peers. A node
+that has the private keys of an active validator and is engaged in
+signing votes is called a *validator-node*. All nodes (not just
+validator-nodes) have an associated state (the current height, round,
+and step) and work to make progress.
+
+Between two nodes there exists a `Connection`, and multiplexed on top of
+this connection are fairly throttled `Channel`s of information. An
+epidemic gossip protocol is implemented among some of these channels to
+bring peers up to speed on the most recent state of consensus. For
+example,
+
+-   Nodes gossip `PartSet` parts of the current round's proposer's
+    proposed block. A LibSwift inspired algorithm is used to quickly
+    broadcast blocks across the gossip network.
+-   Nodes gossip prevote/precommit votes. A node `NODE_A` that is ahead
+    of `NODE_B` can send `NODE_B` prevotes or precommits for `NODE_B`'s
+    current (or future) round to enable it to progress forward.
+-   Nodes gossip prevotes for the proposed PoLC (proof-of-lock-change)
+    round if one is proposed.
+-   Nodes gossip to nodes lagging in blockchain height with block
+    [commits](https://godoc.org/github.com/tendermint/tendermint/types#Commit)
+    for older blocks.
+-   Nodes opportunistically gossip `HasVote` messages to hint peers what
+    votes it already has.
+-   Nodes broadcast their current state to all neighboring peers. (but
+    is not gossiped further)
+
+There's more, but let's not get ahead of ourselves here.
+
+## Proposals
+
+A proposal is signed and published by the designated proposer at each
+round. The proposer is chosen by a deterministic and non-choking round
+robin selection algorithm that selects proposers in proportion to their
+voting power (see
+[implementation](https://github.com/tendermint/tendermint/blob/develop/types/validator_set.go)).
+
+A proposal at `(H,R)` is composed of a block and an optional latest
+`PoLC-Round < R` which is included iff the proposer knows of one. This
+hints the network to allow nodes to unlock (when safe) to ensure the
+liveness property.
+
+## State Machine Spec
+
+### Propose Step (height:H,round:R)
+
+Upon entering `Propose`: - The designated proposer proposes a block at
+`(H,R)`.
+
+The `Propose` step ends: - After `timeoutProposeR` after entering
+`Propose`. --> goto `Prevote(H,R)` - After receiving proposal block
+and all prevotes at `PoLC-Round`. --> goto `Prevote(H,R)` - After
+[common exit conditions](#common-exit-conditions)
+
+### Prevote Step (height:H,round:R)
+
+Upon entering `Prevote`, each validator broadcasts its prevote vote.
+
+-   First, if the validator is locked on a block since `LastLockRound`
+    but now has a PoLC for something else at round `PoLC-Round` where
+    `LastLockRound < PoLC-Round < R`, then it unlocks.
+-   If the validator is still locked on a block, it prevotes that.
+-   Else, if the proposed block from `Propose(H,R)` is good, it
+    prevotes that.
+-   Else, if the proposal is invalid or wasn't received on time, it
+    prevotes `<nil>`.
+
+The `Prevote` step ends: - After +2/3 prevotes for a particular block or
+`<nil>`. -->; goto `Precommit(H,R)` - After `timeoutPrevote` after
+receiving any +2/3 prevotes. --> goto `Precommit(H,R)` - After
+[common exit conditions](#common-exit-conditions)
+
+### Precommit Step (height:H,round:R)
+
+Upon entering `Precommit`, each validator broadcasts its precommit vote.
+- If the validator has a PoLC at `(H,R)` for a particular block `B`, it
+(re)locks (or changes lock to) and precommits `B` and sets
+`LastLockRound = R`. - Else, if the validator has a PoLC at `(H,R)` for
+`<nil>`, it unlocks and precommits `<nil>`. - Else, it keeps the lock
+unchanged and precommits `<nil>`.
+
+A precommit for `<nil>` means "I didn’t see a PoLC for this round, but I
+did get +2/3 prevotes and waited a bit".
+
+The Precommit step ends: - After +2/3 precommits for `<nil>`. -->
+goto `Propose(H,R+1)` - After `timeoutPrecommit` after receiving any
++2/3 precommits. --> goto `Propose(H,R+1)` - After [common exit
+conditions](#common-exit-conditions)
+
+### Common exit conditions
+
+-   After +2/3 precommits for a particular block. --> goto
+    `Commit(H)`
+-   After any +2/3 prevotes received at `(H,R+x)`. --> goto
+    `Prevote(H,R+x)`
+-   After any +2/3 precommits received at `(H,R+x)`. --> goto
+    `Precommit(H,R+x)`
+
+### Commit Step (height:H)
+
+-   Set `CommitTime = now()`
+-   Wait until block is received. --> goto `NewHeight(H+1)`
+
+### NewHeight Step (height:H)
+
+-   Move `Precommits` to `LastCommit` and increment height.
+-   Set `StartTime = CommitTime+timeoutCommit`
+-   Wait until `StartTime` to receive straggler commits. --> goto
+    `Propose(H,0)`
+
+## Proofs
+
+### Proof of Safety
+
+Assume that at most -1/3 of the voting power of validators is byzantine.
+If a validator commits block `B` at round `R`, it's because it saw +2/3
+of precommits at round `R`. This implies that 1/3+ of honest nodes are
+still locked at round `R' > R`. These locked validators will remain
+locked until they see a PoLC at `R' > R`, but this won't happen because
+1/3+ are locked and honest, so at most -2/3 are available to vote for
+anything other than `B`.
+
+### Proof of Liveness
+
+If 1/3+ honest validators are locked on two different blocks from
+different rounds, a proposers' `PoLC-Round` will eventually cause nodes
+locked from the earlier round to unlock. Eventually, the designated
+proposer will be one that is aware of a PoLC at the later round. Also,
+`timeoutProposalR` increments with round `R`, while the size of a
+proposal are capped, so eventually the network is able to "fully gossip"
+the whole proposal (e.g. the block & PoLC).
+
+### Proof of Fork Accountability
+
+Define the JSet (justification-vote-set) at height `H` of a validator
+`V1` to be all the votes signed by the validator at `H` along with
+justification PoLC prevotes for each lock change. For example, if `V1`
+signed the following precommits: `Precommit(B1 @ round 0)`,
+`Precommit(<nil> @ round 1)`, `Precommit(B2 @ round 4)` (note that no
+precommits were signed for rounds 2 and 3, and that's ok),
+`Precommit(B1 @ round 0)` must be justified by a PoLC at round 0, and
+`Precommit(B2 @ round 4)` must be justified by a PoLC at round 4; but
+the precommit for `<nil>` at round 1 is not a lock-change by definition
+so the JSet for `V1` need not include any prevotes at round 1, 2, or 3
+(unless `V1` happened to have prevoted for those rounds).
+
+Further, define the JSet at height `H` of a set of validators `VSet` to
+be the union of the JSets for each validator in `VSet`. For a given
+commit by honest validators at round `R` for block `B` we can construct
+a JSet to justify the commit for `B` at `R`. We say that a JSet
+*justifies* a commit at `(H,R)` if all the committers (validators in the
+commit-set) are each justified in the JSet with no duplicitous vote
+signatures (by the committers).
+
+-   **Lemma**: When a fork is detected by the existence of two
+    conflicting [commits](./validators.html#commiting-a-block), the
+    union of the JSets for both commits (if they can be compiled) must
+    include double-signing by at least 1/3+ of the validator set.
+    **Proof**: The commit cannot be at the same round, because that
+    would immediately imply double-signing by 1/3+. Take the union of
+    the JSets of both commits. If there is no double-signing by at least
+    1/3+ of the validator set in the union, then no honest validator
+    could have precommitted any different block after the first commit.
+    Yet, +2/3 did. Reductio ad absurdum.
+
+As a corollary, when there is a fork, an external process can determine
+the blame by requiring each validator to justify all of its round votes.
+Either we will find 1/3+ who cannot justify at least one of their votes,
+and/or, we will find 1/3+ who had double-signed.
+
+### Alternative algorithm
+
+Alternatively, we can take the JSet of a commit to be the "full commit".
+That is, if light clients and validators do not consider a block to be
+committed unless the JSet of the commit is also known, then we get the
+desirable property that if there ever is a fork (e.g. there are two
+conflicting "full commits"), then 1/3+ of the validators are immediately
+punishable for double-signing.
+
+There are many ways to ensure that the gossip network efficiently share
+the JSet of a commit. One solution is to add a new message type that
+tells peers that this node has (or does not have) a +2/3 majority for B
+(or) at (H,R), and a bitarray of which votes contributed towards that
+majority. Peers can react by responding with appropriate votes.
+
+We will implement such an algorithm for the next iteration of the
+Tendermint consensus protocol.
+
+Other potential improvements include adding more data in votes such as
+the last known PoLC round that caused a lock change, and the last voted
+round/step (or, we may require that validators not skip any votes). This
+may make JSet verification/gossip logic easier to implement.
+
+### Censorship Attacks
+
+Due to the definition of a block
+[commit](../../tendermint-core/validator.md#commiting-a-block), any 1/3+ coalition of
+validators can halt the blockchain by not broadcasting their votes. Such
+a coalition can also censor particular transactions by rejecting blocks
+that include these transactions, though this would result in a
+significant proportion of block proposals to be rejected, which would
+slow down the rate of block commits of the blockchain, reducing its
+utility and value. The malicious coalition might also broadcast votes in
+a trickle so as to grind blockchain block commits to a near halt, or
+engage in any combination of these attacks.
+
+If a global active adversary were also involved, it can partition the
+network in such a way that it may appear that the wrong subset of
+validators were responsible for the slowdown. This is not just a
+limitation of Tendermint, but rather a limitation of all consensus
+protocols whose network is potentially controlled by an active
+adversary.
+
+### Overcoming Forks and Censorship Attacks
+
+For these types of attacks, a subset of the validators through external
+means should coordinate to sign a reorg-proposal that chooses a fork
+(and any evidence thereof) and the initial subset of validators with
+their signatures. Validators who sign such a reorg-proposal forego its
+collateral on all other forks. Clients should verify the signatures on
+the reorg-proposal, verify any evidence, and make a judgement or prompt
+the end-user for a decision. For example, a phone wallet app may prompt
+the user with a security warning, while a refrigerator may accept any
+reorg-proposal signed by +1/2 of the original validators.
+
+No non-synchronous Byzantine fault-tolerant algorithm can come to
+consensus when 1/3+ of validators are dishonest, yet a fork assumes that
+1/3+ of validators have already been dishonest by double-signing or
+lock-changing without justification. So, signing the reorg-proposal is a
+coordination problem that cannot be solved by any non-synchronous
+protocol (i.e. automatically, and without making assumptions about the
+reliability of the underlying network). It must be provided by means
+external to the weakly-synchronous Tendermint consensus algorithm. For
+now, we leave the problem of reorg-proposal coordination to human
+coordination via internet media. Validators must take care to ensure
+that there are no significant network partitions, to avoid situations
+where two conflicting reorg-proposals are signed.
+
+Assuming that the external coordination medium and protocol is robust,
+it follows that forks are less of a concern than [censorship
+attacks](#censorship-attacks).

docs/specification/block-structure.rst

@@ -1,218 +0,0 @@
-Block Structure
-===============
-
-The tendermint consensus engine records all agreements by a
-supermajority of nodes into a blockchain, which is replicated among all
-nodes. This blockchain is accessible via various rpc endpoints, mainly
-``/block?height=`` to get the full block, as well as
-``/blockchain?minHeight=_&maxHeight=_`` to get a list of headers. But
-what exactly is stored in these blocks?
-
-Block
-~~~~~
-
-A
-`Block <https://godoc.org/github.com/tendermint/tendermint/types#Block>`__
-contains:
-
--  a `Header <#header>`__ contains merkle hashes for various chain
-   states
--  the
-   `Data <https://godoc.org/github.com/tendermint/tendermint/types#Data>`__
-   is all transactions which are to be processed
--  the `LastCommit <#commit>`__ > 2/3 signatures for the last block
-
-The signatures returned along with block ``H`` are those validating
-block ``H-1``. This can be a little confusing, but we must also consider
-that the ``Header`` also contains the ``LastCommitHash``. It would be
-impossible for a Header to include the commits that sign it, as it would
-cause an infinite loop here. But when we get block ``H``, we find
-``Header.LastCommitHash``, which must match the hash of ``LastCommit``.
-
-Header
-~~~~~~
-
-The
-`Header <https://godoc.org/github.com/tendermint/tendermint/types#Header>`__
-contains lots of information (follow link for up-to-date info). Notably,
-it maintains the ``Height``, the ``LastBlockID`` (to make it a chain),
-and hashes of the data, the app state, and the validator set. This is
-important as the only item that is signed by the validators is the
-``Header``, and all other data must be validated against one of the
-merkle hashes in the ``Header``.
-
-The ``DataHash`` can provide a nice check on the
-`Data <https://godoc.org/github.com/tendermint/tendermint/types#Data>`__
-returned in this same block. If you are subscribed to new blocks, via
-tendermint RPC, in order to display or process the new transactions you
-should at least validate that the ``DataHash`` is valid. If it is
-important to verify autheniticity, you must wait for the ``LastCommit``
-from the next block to make sure the block header (including
-``DataHash``) was properly signed.
-
-The ``ValidatorHash`` contains a hash of the current
-`Validators <https://godoc.org/github.com/tendermint/tendermint/types#Validator>`__.
-Tracking all changes in the validator set is complex, but a client can
-quickly compare this hash with the `hash of the currently known
-validators <https://godoc.org/github.com/tendermint/tendermint/types#ValidatorSet.Hash>`__
-to see if there have been changes.
-
-The ``AppHash`` serves as the basis for validating any merkle proofs
-that come from the ABCI application. It represents the
-state of the actual application, rather that the state of the blockchain
-itself. This means it's necessary in order to perform any business
-logic, such as verifying an account balance.
-
-**Note** After the transactions are committed to a block, they still
-need to be processed in a separate step, which happens between the
-blocks. If you find a given transaction in the block at height ``H``,
-the effects of running that transaction will be first visible in the
-``AppHash`` from the block header at height ``H+1``.
-
-Like the ``LastCommit`` issue, this is a requirement of the immutability
-of the block chain, as the application only applies transactions *after*
-they are commited to the chain.
-
-Commit
-~~~~~~
-
-The
-`Commit <https://godoc.org/github.com/tendermint/tendermint/types#Commit>`__
-contains a set of
-`Votes <https://godoc.org/github.com/tendermint/tendermint/types#Vote>`__
-that were made by the validator set to reach consensus on this block.
-This is the key to the security in any PoS system, and actually no data
-that cannot be traced back to a block header with a valid set of Votes
-can be trusted. Thus, getting the Commit data and verifying the votes is
-extremely important.
-
-As mentioned above, in order to find the ``precommit votes`` for block
-header ``H``, we need to query block ``H+1``. Then we need to check the
-votes, make sure they really are for that block, and properly formatted.
-Much of this code is implemented in Go in the
-`light-client <https://github.com/tendermint/light-client>`__ package.
-If you look at the code, you will notice that we need to provide the
-``chainID`` of the blockchain in order to properly calculate the votes.
-This is to protect anyone from swapping votes between chains to fake (or
-frame) a validator. Also note that this ``chainID`` is in the
-``genesis.json`` from *Tendermint*, not the ``genesis.json`` from the
-basecoin app (`that is a different
-chainID... <https://github.com/cosmos/cosmos-sdk/issues/32>`__).
-
-Once we have those votes, and we calculated the proper `sign
-bytes <https://godoc.org/github.com/tendermint/tendermint/types#Vote.WriteSignBytes>`__
-using the chainID and a `nice helper
-function <https://godoc.org/github.com/tendermint/tendermint/types#SignBytes>`__,
-we can verify them. The light client is responsible for maintaining a
-set of validators that we trust. Each vote only stores the validators
-``Address``, as well as the ``Signature``. Assuming we have a local copy
-of the trusted validator set, we can look up the ``Public Key`` of the
-validator given its ``Address``, then verify that the ``Signature``
-matches the ``SignBytes`` and ``Public Key``. Then we sum up the total
-voting power of all validators, whose votes fulfilled all these
-stringent requirements. If the total number of voting power for a single
-block is greater than 2/3 of all voting power, then we can finally trust
-the block header, the AppHash, and the proof we got from the ABCI
-application.
-
-Vote Sign Bytes
-^^^^^^^^^^^^^^^
-
-The ``sign-bytes`` of a vote is produced by taking a
-`stable-json <https://github.com/substack/json-stable-stringify>`__-like
-deterministic JSON `wire <./wire-protocol.html>`__ encoding of
-the vote (excluding the ``Signature`` field), and wrapping it with
-``{"chain_id":"my_chain","vote":...}``.
-
-For example, a precommit vote might have the following ``sign-bytes``:
-
-.. code:: json
-
-    {"chain_id":"my_chain","vote":{"block_hash":"611801F57B4CE378DF1A3FFF1216656E89209A99","block_parts_header":{"hash":"B46697379DBE0774CC2C3B656083F07CA7E0F9CE","total":123},"height":1234,"round":1,"type":2}}
-
-Block Hash
-~~~~~~~~~~
-
-The `block
-hash <https://godoc.org/github.com/tendermint/tendermint/types#Block.Hash>`__
-is the `Simple Tree hash <./merkle.html#simple-tree-with-dictionaries>`__
-of the fields of the block ``Header`` encoded as a list of
-``KVPair``\ s.
-
-Transaction
-~~~~~~~~~~~
-
-A transaction is any sequence of bytes. It is up to your
-ABCI application to accept or reject transactions.
-
-BlockID
-~~~~~~~
-
-Many of these data structures refer to the
-`BlockID <https://godoc.org/github.com/tendermint/tendermint/types#BlockID>`__,
-which is the ``BlockHash`` (hash of the block header, also referred to
-by the next block) along with the ``PartSetHeader``. The
-``PartSetHeader`` is explained below and is used internally to
-orchestrate the p2p propogation. For clients, it is basically opaque
-bytes, but they must match for all votes.
-
-PartSetHeader
-~~~~~~~~~~~~~
-
-The
-`PartSetHeader <https://godoc.org/github.com/tendermint/tendermint/types#PartSetHeader>`__
-contains the total number of pieces in a
-`PartSet <https://godoc.org/github.com/tendermint/tendermint/types#PartSet>`__,
-and the Merkle root hash of those pieces.
-
-PartSet
-~~~~~~~
-
-PartSet is used to split a byteslice of data into parts (pieces) for
-transmission. By splitting data into smaller parts and computing a
-Merkle root hash on the list, you can verify that a part is legitimately
-part of the complete data, and the part can be forwarded to other peers
-before all the parts are known. In short, it's a fast way to securely
-propagate a large chunk of data (like a block) over a gossip network.
-
-PartSet was inspired by the LibSwift project.
-
-Usage:
-
-.. code:: go
-
-    data := RandBytes(2 << 20) // Something large
-
-    partSet := NewPartSetFromData(data)
-    partSet.Total()     // Total number of 4KB parts
-    partSet.Count()     // Equal to the Total, since we already have all the parts
-    partSet.Hash()      // The Merkle root hash
-    partSet.BitArray()  // A BitArray of partSet.Total() 1's
-
-    header := partSet.Header() // Send this to the peer
-    header.Total        // Total number of parts
-    header.Hash         // The merkle root hash
-
-    // Now we'll reconstruct the data from the parts
-    partSet2 := NewPartSetFromHeader(header)
-    partSet2.Total()    // Same total as partSet.Total()
-    partSet2.Count()    // Zero, since this PartSet doesn't have any parts yet.
-    partSet2.Hash()     // Same hash as in partSet.Hash()
-    partSet2.BitArray() // A BitArray of partSet.Total() 0's
-
-    // In a gossip network the parts would arrive in arbitrary order, perhaps
-    // in response to explicit requests for parts, or optimistically in response
-    // to the receiving peer's partSet.BitArray().
-    for !partSet2.IsComplete() {
-        part := receivePartFromGossipNetwork()
-        added, err := partSet2.AddPart(part)
-        if err != nil {
-        // A wrong part,
-            // the merkle trail does not hash to partSet2.Hash()
-        } else if !added {
-            // A duplicate part already received
-        }
-    }
-
-    data2, _ := ioutil.ReadAll(partSet2.GetReader())
-    bytes.Equal(data, data2) // true

docs/specification/byzantine-consensus-algorithm.rst

@@ -1,349 +0,0 @@
-Byzantine Consensus Algorithm
-=============================
-
-Terms
------
-
--  The network is composed of optionally connected *nodes*. Nodes
-   directly connected to a particular node are called *peers*.
--  The consensus process in deciding the next block (at some *height*
-   ``H``) is composed of one or many *rounds*.
--  ``NewHeight``, ``Propose``, ``Prevote``, ``Precommit``, and
-   ``Commit`` represent state machine states of a round. (aka
-   ``RoundStep`` or just "step").
--  A node is said to be *at* a given height, round, and step, or at
-   ``(H,R,S)``, or at ``(H,R)`` in short to omit the step.
--  To *prevote* or *precommit* something means to broadcast a `prevote
-   vote <https://godoc.org/github.com/tendermint/tendermint/types#Vote>`__
-   or `first precommit
-   vote <https://godoc.org/github.com/tendermint/tendermint/types#FirstPrecommit>`__
-   for something.
--  A vote *at* ``(H,R)`` is a vote signed with the bytes for ``H`` and
-   ``R`` included in its
-   `sign-bytes <block-structure.html#vote-sign-bytes>`__.
--  *+2/3* is short for "more than 2/3"
--  *1/3+* is short for "1/3 or more"
--  A set of +2/3 of prevotes for a particular block or ``<nil>`` at
-   ``(H,R)`` is called a *proof-of-lock-change* or *PoLC* for short.
-
-State Machine Overview
-----------------------
-
-At each height of the blockchain a round-based protocol is run to
-determine the next block. Each round is composed of three *steps*
-(``Propose``, ``Prevote``, and ``Precommit``), along with two special
-steps ``Commit`` and ``NewHeight``.
-
-In the optimal scenario, the order of steps is:
-
-::
-
-    NewHeight -> (Propose -> Prevote -> Precommit)+ -> Commit -> NewHeight ->...
-
-The sequence ``(Propose -> Prevote -> Precommit)`` is called a *round*.
-There may be more than one round required to commit a block at a given
-height. Examples for why more rounds may be required include:
-
--  The designated proposer was not online.
--  The block proposed by the designated proposer was not valid.
--  The block proposed by the designated proposer did not propagate in
-   time.
--  The block proposed was valid, but +2/3 of prevotes for the proposed
-   block were not received in time for enough validator nodes by the
-   time they reached the ``Precommit`` step. Even though +2/3 of
-   prevotes are necessary to progress to the next step, at least one
-   validator may have voted ``<nil>`` or maliciously voted for something
-   else.
--  The block proposed was valid, and +2/3 of prevotes were received for
-   enough nodes, but +2/3 of precommits for the proposed block were not
-   received for enough validator nodes.
-
-Some of these problems are resolved by moving onto the next round &
-proposer. Others are resolved by increasing certain round timeout
-parameters over each successive round.
-
-State Machine Diagram
----------------------
-
-::
-
-                                +-------------------------------------+
-                                v                                     |(Wait til `CommmitTime+timeoutCommit`)
-                          +-----------+                         +-----+-----+
-             +----------> |  Propose  +--------------+          | NewHeight |
-             |            +-----------+              |          +-----------+
-             |                                       |                ^
-             |(Else, after timeoutPrecommit)         v                |
-       +-----+-----+                           +-----------+          |
-       | Precommit |  <------------------------+  Prevote  |          |
-       +-----+-----+                           +-----------+          |
-             |(When +2/3 Precommits for block found)                  |
-             v                                                        |
-       +--------------------------------------------------------------------+
-       |  Commit                                                            |
-       |                                                                    |
-       |  * Set CommitTime = now;                                           |
-       |  * Wait for block, then stage/save/commit block;                   |
-       +--------------------------------------------------------------------+
-
-Background Gossip
------------------
-
-A node may not have a corresponding validator private key, but it
-nevertheless plays an active role in the consensus process by relaying
-relevant meta-data, proposals, blocks, and votes to its peers. A node
-that has the private keys of an active validator and is engaged in
-signing votes is called a *validator-node*. All nodes (not just
-validator-nodes) have an associated state (the current height, round,
-and step) and work to make progress.
-
-Between two nodes there exists a ``Connection``, and multiplexed on top
-of this connection are fairly throttled ``Channel``\ s of information.
-An epidemic gossip protocol is implemented among some of these channels
-to bring peers up to speed on the most recent state of consensus. For
-example,
-
--  Nodes gossip ``PartSet`` parts of the current round's proposer's
-   proposed block. A LibSwift inspired algorithm is used to quickly
-   broadcast blocks across the gossip network.
--  Nodes gossip prevote/precommit votes. A node NODE\_A that is ahead of
-   NODE\_B can send NODE\_B prevotes or precommits for NODE\_B's current
-   (or future) round to enable it to progress forward.
--  Nodes gossip prevotes for the proposed PoLC (proof-of-lock-change)
-   round if one is proposed.
--  Nodes gossip to nodes lagging in blockchain height with block
-   `commits <https://godoc.org/github.com/tendermint/tendermint/types#Commit>`__
-   for older blocks.
--  Nodes opportunistically gossip ``HasVote`` messages to hint peers
-   what votes it already has.
--  Nodes broadcast their current state to all neighboring peers. (but is
-   not gossiped further)
-
-There's more, but let's not get ahead of ourselves here.
-
-Proposals
----------
-
-A proposal is signed and published by the designated proposer at each
-round. The proposer is chosen by a deterministic and non-choking round
-robin selection algorithm that selects proposers in proportion to their
-voting power. (see
-`implementation <https://github.com/tendermint/tendermint/blob/develop/types/validator_set.go>`__)
-
-A proposal at ``(H,R)`` is composed of a block and an optional latest
-``PoLC-Round < R`` which is included iff the proposer knows of one. This
-hints the network to allow nodes to unlock (when safe) to ensure the
-liveness property.
-
-State Machine Spec
-------------------
-
-Propose Step (height:H,round:R)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Upon entering ``Propose``: - The designated proposer proposes a block at
-``(H,R)``.
-
-The ``Propose`` step ends: - After ``timeoutProposeR`` after entering
-``Propose``. --> goto ``Prevote(H,R)`` - After receiving proposal block
-and all prevotes at ``PoLC-Round``. --> goto ``Prevote(H,R)`` - After
-`common exit conditions <#common-exit-conditions>`__
-
-Prevote Step (height:H,round:R)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Upon entering ``Prevote``, each validator broadcasts its prevote vote.
-
--  First, if the validator is locked on a block since ``LastLockRound``
-   but now has a PoLC for something else at round ``PoLC-Round`` where
-   ``LastLockRound < PoLC-Round < R``, then it unlocks.
--  If the validator is still locked on a block, it prevotes that.
--  Else, if the proposed block from ``Propose(H,R)`` is good, it
-   prevotes that.
--  Else, if the proposal is invalid or wasn't received on time, it
-   prevotes ``<nil>``.
-
-The ``Prevote`` step ends: - After +2/3 prevotes for a particular block
-or ``<nil>``. --> goto ``Precommit(H,R)`` - After ``timeoutPrevote``
-after receiving any +2/3 prevotes. --> goto ``Precommit(H,R)`` - After
-`common exit conditions <#common-exit-conditions>`__
-
-Precommit Step (height:H,round:R)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Upon entering ``Precommit``, each validator broadcasts its precommit
-vote. - If the validator has a PoLC at ``(H,R)`` for a particular block
-``B``, it (re)locks (or changes lock to) and precommits ``B`` and sets
-``LastLockRound = R``. - Else, if the validator has a PoLC at ``(H,R)``
-for ``<nil>``, it unlocks and precommits ``<nil>``. - Else, it keeps the
-lock unchanged and precommits ``<nil>``.
-
-A precommit for ``<nil>`` means "I didn’t see a PoLC for this round, but
-I did get +2/3 prevotes and waited a bit".
-
-The Precommit step ends: - After +2/3 precommits for ``<nil>``. --> goto
-``Propose(H,R+1)`` - After ``timeoutPrecommit`` after receiving any +2/3
-precommits. --> goto ``Propose(H,R+1)`` - After `common exit
-conditions <#common-exit-conditions>`__
-
-common exit conditions
-^^^^^^^^^^^^^^^^^^^^^^
-
--  After +2/3 precommits for a particular block. --> goto ``Commit(H)``
--  After any +2/3 prevotes received at ``(H,R+x)``. --> goto
-   ``Prevote(H,R+x)``
--  After any +2/3 precommits received at ``(H,R+x)``. --> goto
-   ``Precommit(H,R+x)``
-
-Commit Step (height:H)
-~~~~~~~~~~~~~~~~~~~~~~
-
--  Set ``CommitTime = now()``
--  Wait until block is received. --> goto ``NewHeight(H+1)``
-
-NewHeight Step (height:H)
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  Move ``Precommits`` to ``LastCommit`` and increment height.
--  Set ``StartTime = CommitTime+timeoutCommit``
--  Wait until ``StartTime`` to receive straggler commits. --> goto
-   ``Propose(H,0)``
-
-Proofs
-------
-
-Proof of Safety
-~~~~~~~~~~~~~~~
-
-Assume that at most -1/3 of the voting power of validators is byzantine.
-If a validator commits block ``B`` at round ``R``, it's because it saw
-+2/3 of precommits at round ``R``. This implies that 1/3+ of honest
-nodes are still locked at round ``R' > R``. These locked validators will
-remain locked until they see a PoLC at ``R' > R``, but this won't happen
-because 1/3+ are locked and honest, so at most -2/3 are available to
-vote for anything other than ``B``.
-
-Proof of Liveness
-~~~~~~~~~~~~~~~~~
-
-If 1/3+ honest validators are locked on two different blocks from
-different rounds, a proposers' ``PoLC-Round`` will eventually cause
-nodes locked from the earlier round to unlock. Eventually, the
-designated proposer will be one that is aware of a PoLC at the later
-round. Also, ``timeoutProposalR`` increments with round ``R``, while the
-size of a proposal are capped, so eventually the network is able to
-"fully gossip" the whole proposal (e.g. the block & PoLC).
-
-Proof of Fork Accountability
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Define the JSet (justification-vote-set) at height ``H`` of a validator
-``V1`` to be all the votes signed by the validator at ``H`` along with
-justification PoLC prevotes for each lock change. For example, if ``V1``
-signed the following precommits: ``Precommit(B1 @ round 0)``,
-``Precommit(<nil> @ round 1)``, ``Precommit(B2 @ round 4)`` (note that
-no precommits were signed for rounds 2 and 3, and that's ok),
-``Precommit(B1 @ round 0)`` must be justified by a PoLC at round 0, and
-``Precommit(B2 @ round 4)`` must be justified by a PoLC at round 4; but
-the precommit for ``<nil>`` at round 1 is not a lock-change by
-definition so the JSet for ``V1`` need not include any prevotes at round
-1, 2, or 3 (unless ``V1`` happened to have prevoted for those rounds).
-
-Further, define the JSet at height ``H`` of a set of validators ``VSet``
-to be the union of the JSets for each validator in ``VSet``. For a given
-commit by honest validators at round ``R`` for block ``B`` we can
-construct a JSet to justify the commit for ``B`` at ``R``. We say that a
-JSet *justifies* a commit at ``(H,R)`` if all the committers (validators
-in the commit-set) are each justified in the JSet with no duplicitous
-vote signatures (by the committers).
-
--  **Lemma**: When a fork is detected by the existence of two
-   conflicting `commits <./validators.html#commiting-a-block>`__,
-   the union of the JSets for both commits (if they can be compiled)
-   must include double-signing by at least 1/3+ of the validator set.
-   **Proof**: The commit cannot be at the same round, because that would
-   immediately imply double-signing by 1/3+. Take the union of the JSets
-   of both commits. If there is no double-signing by at least 1/3+ of
-   the validator set in the union, then no honest validator could have
-   precommitted any different block after the first commit. Yet, +2/3
-   did. Reductio ad absurdum.
-
-As a corollary, when there is a fork, an external process can determine
-the blame by requiring each validator to justify all of its round votes.
-Either we will find 1/3+ who cannot justify at least one of their votes,
-and/or, we will find 1/3+ who had double-signed.
-
-Alternative algorithm
-~~~~~~~~~~~~~~~~~~~~~
-
-Alternatively, we can take the JSet of a commit to be the "full commit".
-That is, if light clients and validators do not consider a block to be
-committed unless the JSet of the commit is also known, then we get the
-desirable property that if there ever is a fork (e.g. there are two
-conflicting "full commits"), then 1/3+ of the validators are immediately
-punishable for double-signing.
-
-There are many ways to ensure that the gossip network efficiently share
-the JSet of a commit. One solution is to add a new message type that
-tells peers that this node has (or does not have) a +2/3 majority for B
-(or ) at (H,R), and a bitarray of which votes contributed towards that
-majority. Peers can react by responding with appropriate votes.
-
-We will implement such an algorithm for the next iteration of the
-Tendermint consensus protocol.
-
-Other potential improvements include adding more data in votes such as
-the last known PoLC round that caused a lock change, and the last voted
-round/step (or, we may require that validators not skip any votes). This
-may make JSet verification/gossip logic easier to implement.
-
-Censorship Attacks
-~~~~~~~~~~~~~~~~~~
-
-Due to the definition of a block
-`commit <validators.html#commiting-a-block>`__, any 1/3+
-coalition of validators can halt the blockchain by not broadcasting
-their votes. Such a coalition can also censor particular transactions by
-rejecting blocks that include these transactions, though this would
-result in a significant proportion of block proposals to be rejected,
-which would slow down the rate of block commits of the blockchain,
-reducing its utility and value. The malicious coalition might also
-broadcast votes in a trickle so as to grind blockchain block commits to
-a near halt, or engage in any combination of these attacks.
-
-If a global active adversary were also involved, it can partition the
-network in such a way that it may appear that the wrong subset of
-validators were responsible for the slowdown. This is not just a
-limitation of Tendermint, but rather a limitation of all consensus
-protocols whose network is potentially controlled by an active
-adversary.
-
-Overcoming Forks and Censorship Attacks
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-For these types of attacks, a subset of the validators through external
-means should coordinate to sign a reorg-proposal that chooses a fork
-(and any evidence thereof) and the initial subset of validators with
-their signatures. Validators who sign such a reorg-proposal forego its
-collateral on all other forks. Clients should verify the signatures on
-the reorg-proposal, verify any evidence, and make a judgement or prompt
-the end-user for a decision. For example, a phone wallet app may prompt
-the user with a security warning, while a refrigerator may accept any
-reorg-proposal signed by +1/2 of the original validators.
-
-No non-synchronous Byzantine fault-tolerant algorithm can come to
-consensus when 1/3+ of validators are dishonest, yet a fork assumes that
-1/3+ of validators have already been dishonest by double-signing or
-lock-changing without justification. So, signing the reorg-proposal is a
-coordination problem that cannot be solved by any non-synchronous
-protocol (i.e. automatically, and without making assumptions about the
-reliability of the underlying network). It must be provided by means
-external to the weakly-synchronous Tendermint consensus algorithm. For
-now, we leave the problem of reorg-proposal coordination to human
-coordination via internet media. Validators must take care to ensure
-that there are no significant network partitions, to avoid situations
-where two conflicting reorg-proposals are signed.
-
-Assuming that the external coordination medium and protocol is robust,
-it follows that forks are less of a concern than `censorship
-attacks <#censorship-attacks>`__.

docs/specification/corruption.rst

@@ -1,70 +0,0 @@
-Corruption
-==========
-
-Important step
---------------
-
-Make sure you have a backup of the Tendermint data directory.
-
-Possible causes
----------------
-
-Remember that most corruption is caused by hardware issues:
-
-- RAID controllers with faulty / worn out battery backup, and an unexpected power loss
-- Hard disk drives with write-back cache enabled, and an unexpected power loss
-- Cheap SSDs with insufficient power-loss protection, and an unexpected power-loss
-- Defective RAM
-- Defective or overheating CPU(s)
-
-Other causes can be:
-
-- Database systems configured with fsync=off and an OS crash or power loss
-- Filesystems configured to use write barriers plus a storage layer that ignores write barriers. LVM is a particular culprit.
-- Tendermint bugs
-- Operating system bugs
-- Admin error
-  - directly modifying Tendermint data-directory contents
-
-(Source: https://wiki.postgresql.org/wiki/Corruption)
-
-WAL Corruption
---------------
-
-If consensus WAL is corrupted at the lastest height and you are trying to start
-Tendermint, replay will fail with panic.
-
-Recovering from data corruption can be hard and time-consuming. Here are two approaches you can take:
-
-1) Delete the WAL file and restart Tendermint. It will attempt to sync with other peers.
-2) Try to repair the WAL file manually:
-
-  1. Create a backup of the corrupted WAL file:
-
-  .. code:: bash
-
-      cp "$TMHOME/data/cs.wal/wal" > /tmp/corrupted_wal_backup
-
-  2. Use ./scripts/wal2json to create a human-readable version
-
-  .. code:: bash
-
-      ./scripts/wal2json/wal2json "$TMHOME/data/cs.wal/wal" > /tmp/corrupted_wal
-
-  3. Search for a "CORRUPTED MESSAGE" line.
-  4. By looking at the previous message and the message after the corrupted one
-       and looking at the logs, try to rebuild the message. If the consequent
-       messages are marked as corrupted too (this may happen if length header
-       got corrupted or some writes did not make it to the WAL ~ truncation),
-       then remove all the lines starting from the corrupted one and restart
-       Tendermint.
-
-  .. code:: bash
-
-      $EDITOR /tmp/corrupted_wal
-
-  5. After editing, convert this file back into binary form by running:
-
-  .. code:: bash
-
-      ./scripts/json2wal/json2wal /tmp/corrupted_wal > "$TMHOME/data/cs.wal/wal"

docs/specification/genesis.rst

@@ -1,71 +0,0 @@
-Genesis
-=======
-
-The genesis.json file in ``$TMHOME/config`` defines the initial TendermintCore
-state upon genesis of the blockchain (`see
-definition <https://github.com/tendermint/tendermint/blob/master/types/genesis.go>`__).
-
-Fields
-~~~~~~
-
--  ``genesis_time``: Official time of blockchain start.
--  ``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.
--  ``validators``:
--  ``pub_key``: The first element specifies the pub\_key type. 1 ==
-   Ed25519. The second element are the pubkey bytes.
--  ``power``: The validator's voting power.
--  ``name``: Name of the validator (optional).
--  ``app_hash``: The expected application hash (as returned by the
-   ``ResponseInfo`` ABCI message) upon genesis. If the app's hash does not
-   match, Tendermint will panic.
--  ``app_state``: The application state (e.g. initial distribution of tokens).
-
-Sample genesis.json
-~~~~~~~~~~~~~~~~~~~
-
-.. code:: json
-
-    {
-      "genesis_time": "2016-02-05T06:02:31.526Z",
-      "chain_id": "chain-tTH4mi",
-      "validators": [
-        {
-          "pub_key": [
-            1,
-            "9BC5112CB9614D91CE423FA8744885126CD9D08D9FC9D1F42E552D662BAA411E"
-          ],
-          "power": 1,
-          "name": "mach1"
-        },
-        {
-          "pub_key": [
-            1,
-            "F46A5543D51F31660D9F59653B4F96061A740FF7433E0DC1ECBC30BE8494DE06"
-          ],
-          "power": 1,
-          "name": "mach2"
-        },
-        {
-          "pub_key": [
-            1,
-            "0E7B423C1635FD07C0FC3603B736D5D27953C1C6CA865BB9392CD79DE1A682BB"
-          ],
-          "power": 1,
-          "name": "mach3"
-        },
-        {
-          "pub_key": [
-            1,
-            "4F49237B9A32EB50682EDD83C48CE9CDB1D02A7CFDADCFF6EC8C1FAADB358879"
-          ],
-          "power": 1,
-          "name": "mach4"
-        }
-      ],
-      "app_hash": "15005165891224E721CB664D15CB972240F5703F",
-      "app_state": {
-        {"account": "Bob", "coins": 5000}
-      }
-    }

docs/specification/light-client-protocol.rst

@@ -1,33 +0,0 @@
-Light Client Protocol
-=====================
-
-Light clients are an important part of the complete blockchain system
-for most applications. Tendermint provides unique speed and security
-properties for light client applications.
-
-See our `lite package
-<https://godoc.org/github.com/tendermint/tendermint/lite>`__.
-
-Overview
---------
-
-The objective of the light client protocol is to get a
-`commit <./validators.html#committing-a-block>`__ for a recent
-`block hash <./block-structure.html#block-hash>`__ where the commit
-includes a majority of signatures from the last known validator set.
-From there, all the application state is verifiable with `merkle
-proofs <./merkle.html#iavl-tree>`__.
-
-Properties
-----------
-
--  You get the full collateralized security benefits of Tendermint; No
-   need to wait for confirmations.
--  You get the full speed benefits of Tendermint; transactions commit
-   instantly.
--  You can get the most recent version of the application state
-   non-interactively (without committing anything to the blockchain).
-   For example, this means that you can get the most recent value of a
-   name from the name-registry without worrying about fork censorship
-   attacks, without posting a commit and waiting for confirmations. It's
-   fast, secure, and free!

docs/specification/merkle.rst

@@ -1,88 +0,0 @@
-Merkle
-======
-
-For an overview of Merkle trees, see
-`wikipedia <https://en.wikipedia.org/wiki/Merkle_tree>`__.
-
-There are two types of Merkle trees used in Tendermint.
-
--  **IAVL+ Tree**: An immutable self-balancing binary
-   tree for persistent application state
--  **Simple Tree**: A simple compact binary tree for
-   a static list of items
-
-IAVL+ Tree
-----------
-
-The purpose of this data structure is to provide persistent storage for
-key-value pairs (e.g. account state, name-registrar data, and
-per-contract data) such that a deterministic merkle root hash can be
-computed. The tree is balanced using a variant of the `AVL
-algorithm <http://en.wikipedia.org/wiki/AVL_tree>`__ so all operations
-are O(log(n)).
-
-Nodes of this tree are immutable and indexed by its hash. Thus any node
-serves as an immutable snapshot which lets us stage uncommitted
-transactions from the mempool cheaply, and we can instantly roll back to
-the last committed state to process transactions of a newly committed
-block (which may not be the same set of transactions as those from the
-mempool).
-
-In an AVL tree, the heights of the two child subtrees of any node differ
-by at most one. Whenever this condition is violated upon an update, the
-tree is rebalanced by creating O(log(n)) new nodes that point to
-unmodified nodes of the old tree. In the original AVL algorithm, inner
-nodes can also hold key-value pairs. The AVL+ algorithm (note the plus)
-modifies the AVL algorithm to keep all values on leaf nodes, while only
-using branch-nodes to store keys. This simplifies the algorithm while
-minimizing the size of merkle proofs
-
-In Ethereum, the analog is the `Patricia
-trie <http://en.wikipedia.org/wiki/Radix_tree>`__. There are tradeoffs.
-Keys do not need to be hashed prior to insertion in IAVL+ trees, so this
-provides faster iteration in the key space which may benefit some
-applications. The logic is simpler to implement, requiring only two
-types of nodes -- inner nodes and leaf nodes. The IAVL+ tree is a binary
-tree, so merkle proofs are much shorter than the base 16 Patricia trie.
-On the other hand, while IAVL+ trees provide a deterministic merkle root
-hash, it depends on the order of updates. In practice this shouldn't be
-a problem, since you can efficiently encode the tree structure when
-serializing the tree contents.
-
-Simple Tree
------------
-
-For merkelizing smaller static lists, use the Simple Tree. The
-transactions and validation signatures of a block are hashed using this
-simple merkle tree logic.
-
-If the number of items is not a power of two, the tree will not be full
-and some leaf nodes will be at different levels. Simple Tree tries to
-keep both sides of the tree the same size, but the left side may be one
-greater.
-
-::
-
-        Simple Tree with 6 items           Simple Tree with 7 items 
-                                                             
-                   *                                  *             
-                  / \                                / \            
-                /     \                            /     \          
-              /         \                        /         \        
-            /             \                    /             \      
-           *               *                  *               *     
-          / \             / \                / \             / \    
-         /   \           /   \              /   \           /   \   
-        /     \         /     \            /     \         /     \  
-       *       h2      *       h5         *       *       *       h6
-      / \             / \                / \     / \     / \        
-     h0  h1          h3  h4             h0  h1  h2  h3  h4  h5      
-
-Simple Tree with Dictionaries
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Simple Tree is used to merkelize a list of items, so to merkelize a
-(short) dictionary of key-value pairs, encode the dictionary as an
-ordered list of ``KVPair`` structs. The block hash is such a hash
-derived from all the fields of the block ``Header``. The state hash is
-similarly derived.

docs/specification/new-spec/README.md

@@ -1 +0,0 @@
-Spec moved to [docs/spec](https://github.com/tendermint/tendermint/tree/master/docs/spec).

docs/specification/wire-protocol.rst

@@ -1,172 +0,0 @@
-Wire Protocol
-=============
-
-The `Tendermint wire protocol <https://github.com/tendermint/go-wire>`__
-encodes data in `c-style binary <#binary>`__ and `JSON <#json>`__ form.
-
-Supported types
----------------
-
--  Primitive types
--  ``uint8`` (aka ``byte``), ``uint16``, ``uint32``, ``uint64``
--  ``int8``, ``int16``, ``int32``, ``int64``
--  ``uint``, ``int``: variable length (un)signed integers
--  ``string``, ``[]byte``
--  ``time``
--  Derived types
--  structs
--  var-length arrays of a particular type
--  fixed-length arrays of a particular type
--  interfaces: registered union types preceded by a ``type byte``
--  pointers
-
-Binary
-------
-
-**Fixed-length primitive types** are encoded with 1,2,3, or 4 big-endian
-bytes. - ``uint8`` (aka ``byte``), ``uint16``, ``uint32``, ``uint64``:
-takes 1,2,3, and 4 bytes respectively - ``int8``, ``int16``, ``int32``,
-``int64``: takes 1,2,3, and 4 bytes respectively - ``time``: ``int64``
-representation of nanoseconds since epoch
-
-**Variable-length integers** are encoded with a single leading byte
-representing the length of the following big-endian bytes. For signed
-negative integers, the most significant bit of the leading byte is a 1.
-
--  ``uint``: 1-byte length prefixed variable-size (0 ~ 255 bytes)
-   unsigned integers
--  ``int``: 1-byte length prefixed variable-size (0 ~ 127 bytes) signed
-   integers
-
-NOTE: While the number 0 (zero) is encoded with a single byte ``x00``,
-the number 1 (one) takes two bytes to represent: ``x0101``. This isn't
-the most efficient representation, but the rules are easier to remember.
-
-+---------------+----------------+----------------+
-| number        | binary         | binary ``int`` |
-|               | ``uint``       |                |
-+===============+================+================+
-| 0             | ``x00``        | ``x00``        |
-+---------------+----------------+----------------+
-| 1             | ``x0101``      | ``x0101``      |
-+---------------+----------------+----------------+
-| 2             | ``x0102``      | ``x0102``      |
-+---------------+----------------+----------------+
-| 256           | ``x020100``    | ``x020100``    |
-+---------------+----------------+----------------+
-| 2^(127\ *8)-1 | ``x800100...`` | overflow       |
-| \|            |                |                |
-| ``x7FFFFF...` |                |                |
-| `             |                |                |
-| \|            |                |                |
-| ``x7FFFFF...` |                |                |
-| `             |                |                |
-| \| \|         |                |                |
-| 2^(127*\ 8)   |                |                |
-+---------------+----------------+----------------+
-| 2^(255\*8)-1  |
-| \|            |
-| ``xFFFFFF...` |
-| `             |
-| \| overflow   |
-| \| \| -1 \|   |
-| n/a \|        |
-| ``x8101`` \|  |
-| \| -2 \| n/a  |
-| \| ``x8102``  |
-| \| \| -256 \| |
-| n/a \|        |
-| ``x820100``   |
-| \|            |
-+---------------+----------------+----------------+
-
-**Structures** are encoded by encoding the field values in order of
-declaration.
-
-.. code:: go
-
-    type Foo struct {
-        MyString string
-        MyUint32 uint32
-    }
-    var foo = Foo{"626172", math.MaxUint32}
-
-    /* The binary representation of foo:
-     0103626172FFFFFFFF
-     0103:               `int` encoded length of string, here 3
-         626172:         3 bytes of string "bar"
-               FFFFFFFF: 4 bytes of uint32 MaxUint32
-    */
-
-**Variable-length arrays** are encoded with a leading ``int`` denoting
-the length of the array followed by the binary representation of the
-items. **Fixed-length arrays** are similar but aren't preceded by the
-leading ``int``.
-
-.. code:: go
-
-    foos := []Foo{foo, foo}
-
-    /* The binary representation of foos:
-     01020103626172FFFFFFFF0103626172FFFFFFFF
-     0102:                                     `int` encoded length of array, here 2
-         0103626172FFFFFFFF:                   the first `foo`
-                           0103626172FFFFFFFF: the second `foo`
-    */
-
-    foos := [2]Foo{foo, foo} // fixed-length array
-
-    /* The binary representation of foos:
-     0103626172FFFFFFFF0103626172FFFFFFFF
-     0103626172FFFFFFFF:                   the first `foo`
-                       0103626172FFFFFFFF: the second `foo`
-    */
-
-**Interfaces** can represent one of any number of concrete types. The
-concrete types of an interface must first be declared with their
-corresponding ``type byte``. An interface is then encoded with the
-leading ``type byte``, then the binary encoding of the underlying
-concrete type.
-
-NOTE: The byte ``x00`` is reserved for the ``nil`` interface value and
-``nil`` pointer values.
-
-.. code:: go
-
-    type Animal interface{}
-    type Dog uint32
-    type Cat string
-
-    RegisterInterface(
-        struct{ Animal }{},          // Convenience for referencing the 'Animal' interface
-        ConcreteType{Dog(0),  0x01}, // Register the byte 0x01 to denote a Dog
-        ConcreteType{Cat(""), 0x02}, // Register the byte 0x02 to denote a Cat
-    )
-
-    var animal Animal = Dog(02)
-
-    /* The binary representation of animal:
-     010102
-     01:     the type byte for a `Dog`
-       0102: the bytes of Dog(02)
-    */
-
-**Pointers** are encoded with a single leading byte ``x00`` for ``nil``
-pointers, otherwise encoded with a leading byte ``x01`` followed by the
-binary encoding of the value pointed to.
-
-NOTE: It's easy to convert pointer types into interface types, since the
-``type byte`` ``x00`` is always ``nil``.
-
-JSON
-----
-
-The JSON codec is compatible with the ```binary`` <#binary>`__ codec,
-and is fairly intuitive if you're already familiar with golang's JSON
-encoding. Some quirks are noted below:
-
--  variable-length and fixed-length bytes are encoded as uppercase
-   hexadecimal strings
--  interface values are encoded as an array of two items:
-   ``[type_byte, concrete_value]``
--  times are encoded as rfc2822 strings

docs/tendermint-core/block-structure.md

@@ -0,0 +1,206 @@
+# Block Structure
+
+The tendermint consensus engine records all agreements by a
+supermajority of nodes into a blockchain, which is replicated among all
+nodes. This blockchain is accessible via various rpc endpoints, mainly
+`/block?height=` to get the full block, as well as
+`/blockchain?minHeight=_&maxHeight=_` to get a list of headers. But what
+exactly is stored in these blocks?
+
+## Block
+
+A
+[Block](https://godoc.org/github.com/tendermint/tendermint/types#Block)
+contains:
+
+-   a [Header](#header) contains merkle hashes for various chain states
+-   the
+    [Data](https://godoc.org/github.com/tendermint/tendermint/types#Data)
+    is all transactions which are to be processed
+-   the [LastCommit](#commit) > 2/3 signatures for the last block
+
+The signatures returned along with block `H` are those validating block
+`H-1`. This can be a little confusing, but we must also consider that
+the `Header` also contains the `LastCommitHash`. It would be impossible
+for a Header to include the commits that sign it, as it would cause an
+infinite loop here. But when we get block `H`, we find
+`Header.LastCommitHash`, which must match the hash of `LastCommit`.
+
+## Header
+
+The
+[Header](https://godoc.org/github.com/tendermint/tendermint/types#Header)
+contains lots of information (follow link for up-to-date info). Notably,
+it maintains the `Height`, the `LastBlockID` (to make it a chain), and
+hashes of the data, the app state, and the validator set. This is
+important as the only item that is signed by the validators is the
+`Header`, and all other data must be validated against one of the merkle
+hashes in the `Header`.
+
+The `DataHash` can provide a nice check on the
+[Data](https://godoc.org/github.com/tendermint/tendermint/types#Data)
+returned in this same block. If you are subscribed to new blocks, via
+tendermint RPC, in order to display or process the new transactions you
+should at least validate that the `DataHash` is valid. If it is
+important to verify autheniticity, you must wait for the `LastCommit`
+from the next block to make sure the block header (including `DataHash`)
+was properly signed.
+
+The `ValidatorHash` contains a hash of the current
+[Validators](https://godoc.org/github.com/tendermint/tendermint/types#Validator).
+Tracking all changes in the validator set is complex, but a client can
+quickly compare this hash with the [hash of the currently known
+validators](https://godoc.org/github.com/tendermint/tendermint/types#ValidatorSet.Hash)
+to see if there have been changes.
+
+The `AppHash` serves as the basis for validating any merkle proofs that
+come from the ABCI application. It represents the state of the actual
+application, rather that the state of the blockchain itself. This means
+it's necessary in order to perform any business logic, such as verifying
+an account balance.
+
+**Note** After the transactions are committed to a block, they still
+need to be processed in a separate step, which happens between the
+blocks. If you find a given transaction in the block at height `H`, the
+effects of running that transaction will be first visible in the
+`AppHash` from the block header at height `H+1`.
+
+Like the `LastCommit` issue, this is a requirement of the immutability
+of the block chain, as the application only applies transactions *after*
+they are commited to the chain.
+
+## Commit
+
+The
+[Commit](https://godoc.org/github.com/tendermint/tendermint/types#Commit)
+contains a set of
+[Votes](https://godoc.org/github.com/tendermint/tendermint/types#Vote)
+that were made by the validator set to reach consensus on this block.
+This is the key to the security in any PoS system, and actually no data
+that cannot be traced back to a block header with a valid set of Votes
+can be trusted. Thus, getting the Commit data and verifying the votes is
+extremely important.
+
+As mentioned above, in order to find the `precommit votes` for block
+header `H`, we need to query block `H+1`. Then we need to check the
+votes, make sure they really are for that block, and properly formatted.
+Much of this code is implemented in Go in the
+[light-client](https://github.com/tendermint/light-client) package. If
+you look at the code, you will notice that we need to provide the
+`chainID` of the blockchain in order to properly calculate the votes.
+This is to protect anyone from swapping votes between chains to fake (or
+frame) a validator. Also note that this `chainID` is in the
+`genesis.json` from *Tendermint*, not the `genesis.json` from the
+basecoin app ([that is a different
+chainID...](https://github.com/cosmos/cosmos-sdk/issues/32)).
+
+Once we have those votes, and we calculated the proper [sign
+bytes](https://godoc.org/github.com/tendermint/tendermint/types#Vote.WriteSignBytes)
+using the chainID and a [nice helper
+function](https://godoc.org/github.com/tendermint/tendermint/types#SignBytes),
+we can verify them. The light client is responsible for maintaining a
+set of validators that we trust. Each vote only stores the validators
+`Address`, as well as the `Signature`. Assuming we have a local copy of
+the trusted validator set, we can look up the `Public Key` of the
+validator given its `Address`, then verify that the `Signature` matches
+the `SignBytes` and `Public Key`. Then we sum up the total voting power
+of all validators, whose votes fulfilled all these stringent
+requirements. If the total number of voting power for a single block is
+greater than 2/3 of all voting power, then we can finally trust the
+block header, the AppHash, and the proof we got from the ABCI
+application.
+
+### Vote Sign Bytes
+
+The `sign-bytes` of a vote is produced by taking a
+[stable-json](https://github.com/substack/json-stable-stringify)-like
+deterministic JSON [wire](./wire-protocol.html) encoding of the vote
+(excluding the `Signature` field), and wrapping it with
+`{"chain_id":"my_chain","vote":...}`.
+
+For example, a precommit vote might have the following `sign-bytes`:
+
+```
+{"chain_id":"my_chain","vote":{"block_hash":"611801F57B4CE378DF1A3FFF1216656E89209A99","block_parts_header":{"hash":"B46697379DBE0774CC2C3B656083F07CA7E0F9CE","total":123},"height":1234,"round":1,"type":2}}
+```
+
+## Block Hash
+
+The [block
+hash](https://godoc.org/github.com/tendermint/tendermint/types#Block.Hash)
+is the [Simple Tree hash](./merkle.html#simple-tree-with-dictionaries)
+of the fields of the block `Header` encoded as a list of `KVPair`s.
+
+## Transaction
+
+A transaction is any sequence of bytes. It is up to your ABCI
+application to accept or reject transactions.
+
+## BlockID
+
+Many of these data structures refer to the
+[BlockID](https://godoc.org/github.com/tendermint/tendermint/types#BlockID),
+which is the `BlockHash` (hash of the block header, also referred to by
+the next block) along with the `PartSetHeader`. The `PartSetHeader` is
+explained below and is used internally to orchestrate the p2p
+propogation. For clients, it is basically opaque bytes, but they must
+match for all votes.
+
+## PartSetHeader
+
+The
+[PartSetHeader](https://godoc.org/github.com/tendermint/tendermint/types#PartSetHeader)
+contains the total number of pieces in a
+[PartSet](https://godoc.org/github.com/tendermint/tendermint/types#PartSet),
+and the Merkle root hash of those pieces.
+
+## PartSet
+
+PartSet is used to split a byteslice of data into parts (pieces) for
+transmission. By splitting data into smaller parts and computing a
+Merkle root hash on the list, you can verify that a part is legitimately
+part of the complete data, and the part can be forwarded to other peers
+before all the parts are known. In short, it's a fast way to securely
+propagate a large chunk of data (like a block) over a gossip network.
+
+PartSet was inspired by the LibSwift project.
+
+Usage:
+
+```
+data := RandBytes(2 << 20) // Something large
+
+partSet := NewPartSetFromData(data)
+partSet.Total()     // Total number of 4KB parts
+partSet.Count()     // Equal to the Total, since we already have all the parts
+partSet.Hash()      // The Merkle root hash
+partSet.BitArray()  // A BitArray of partSet.Total() 1's
+
+header := partSet.Header() // Send this to the peer
+header.Total        // Total number of parts
+header.Hash         // The merkle root hash
+
+// Now we'll reconstruct the data from the parts
+partSet2 := NewPartSetFromHeader(header)
+partSet2.Total()    // Same total as partSet.Total()
+partSet2.Count()    // Zero, since this PartSet doesn't have any parts yet.
+partSet2.Hash()     // Same hash as in partSet.Hash()
+partSet2.BitArray() // A BitArray of partSet.Total() 0's
+
+// In a gossip network the parts would arrive in arbitrary order, perhaps
+// in response to explicit requests for parts, or optimistically in response
+// to the receiving peer's partSet.BitArray().
+for !partSet2.IsComplete() {
+    part := receivePartFromGossipNetwork()
+    added, err := partSet2.AddPart(part)
+    if err != nil {
+    // A wrong part,
+        // the merkle trail does not hash to partSet2.Hash()
+    } else if !added {
+        // A duplicate part already received
+    }
+}
+
+data2, _ := ioutil.ReadAll(partSet2.GetReader())
+bytes.Equal(data, data2) // true
+```

docs/tendermint-core/configuration.md

@@ -2,8 +2,7 @@
 
 Tendermint Core can be configured via a TOML file in
 `$TMHOME/config/config.toml`. Some of these parameters can be overridden by
-command-line flags. For most users, the options in the `##### main
-base configuration options #####` are intended to be modified while
+command-line flags. For most users, the options in the `##### main base configuration options #####` are intended to be modified while
 config options further below are intended for advance power users.
 
 ## Options
@@ -210,4 +209,10 @@ prometheus = false
 
 # Address to listen for Prometheus collector(s) connections
 prometheus_listen_addr = ":26660"
+
+# Maximum number of simultaneous connections.
+# If you want to accept a more significant number than the default, make sure
+# you increase your OS limits.
+# 0 - unlimited.
+max_open_connections = 3
 ```

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

@@ -0,0 +1,142 @@
+# How to read logs
+
+## Walkabout example
+
+We first create three connections (mempool, consensus and query) to the
+application (running `kvstore` locally in this case).
+
+```
+I[10-04|13:54:27.364] Starting multiAppConn                        module=proxy impl=multiAppConn
+I[10-04|13:54:27.366] Starting localClient                         module=abci-client connection=query impl=localClient
+I[10-04|13:54:27.366] Starting localClient                         module=abci-client connection=mempool impl=localClient
+I[10-04|13:54:27.367] Starting localClient                         module=abci-client connection=consensus impl=localClient
+```
+
+Then Tendermint Core and the application perform a handshake.
+
+```
+I[10-04|13:54:27.367] ABCI Handshake                               module=consensus appHeight=90 appHash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
+I[10-04|13:54:27.368] ABCI Replay Blocks                           module=consensus appHeight=90 storeHeight=90 stateHeight=90
+I[10-04|13:54:27.368] Completed ABCI Handshake - Tendermint and App are synced module=consensus appHeight=90 appHash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
+```
+
+After that, we start a few more things like the event switch, reactors,
+and perform UPNP discover in order to detect the IP address.
+
+```
+I[10-04|13:54:27.374] Starting EventSwitch                         module=types impl=EventSwitch
+I[10-04|13:54:27.375] This node is a validator                     module=consensus
+I[10-04|13:54:27.379] Starting Node                                module=main impl=Node
+I[10-04|13:54:27.381] Local listener                               module=p2p ip=:: port=26656
+I[10-04|13:54:27.382] Getting UPNP external address                module=p2p
+I[10-04|13:54:30.386] Could not perform UPNP discover              module=p2p err="write udp4 0.0.0.0:38238->239.255.255.250:1900: i/o timeout"
+I[10-04|13:54:30.386] Starting DefaultListener                     module=p2p impl=Listener(@10.0.2.15:26656)
+I[10-04|13:54:30.387] Starting P2P Switch                          module=p2p impl="P2P Switch"
+I[10-04|13:54:30.387] Starting MempoolReactor                      module=mempool impl=MempoolReactor
+I[10-04|13:54:30.387] Starting BlockchainReactor                   module=blockchain impl=BlockchainReactor
+I[10-04|13:54:30.387] Starting ConsensusReactor                    module=consensus impl=ConsensusReactor
+I[10-04|13:54:30.387] ConsensusReactor                             module=consensus fastSync=false
+I[10-04|13:54:30.387] Starting ConsensusState                      module=consensus impl=ConsensusState
+I[10-04|13:54:30.387] Starting WAL                                 module=consensus wal=/home/vagrant/.tendermint/data/cs.wal/wal impl=WAL
+I[10-04|13:54:30.388] Starting TimeoutTicker                       module=consensus impl=TimeoutTicker
+```
+
+Notice the second row where Tendermint Core reports that "This node is a
+validator". It also could be just an observer (regular node).
+
+Next we replay all the messages from the WAL.
+
+```
+I[10-04|13:54:30.390] Catchup by replaying consensus messages      module=consensus height=91
+I[10-04|13:54:30.390] Replay: New Step                             module=consensus height=91 round=0 step=RoundStepNewHeight
+I[10-04|13:54:30.390] Replay: Done                                 module=consensus
+```
+
+"Started node" message signals that everything is ready for work.
+
+```
+I[10-04|13:54:30.391] Starting RPC HTTP server on tcp socket 0.0.0.0:26657 module=rpc-server
+I[10-04|13:54:30.392] Started node                                 module=main nodeInfo="NodeInfo{id: DF22D7C92C91082324A1312F092AA1DA197FA598DBBFB6526E, moniker: anonymous, network: test-chain-3MNw2N [remote , listen 10.0.2.15:26656], version: 0.11.0-10f361fc ([wire_version=0.6.2 p2p_version=0.5.0 consensus_version=v1/0.2.2 rpc_version=0.7.0/3 tx_index=on rpc_addr=tcp://0.0.0.0:26657])}"
+```
+
+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).
+
+```
+I[10-04|13:54:30.393] enterNewRound(91/0). Current: 91/0/RoundStepNewHeight module=consensus
+I[10-04|13:54:30.393] enterPropose(91/0). Current: 91/0/RoundStepNewRound module=consensus
+I[10-04|13:54:30.393] enterPropose: Our turn to propose            module=consensus proposer=125B0E3C5512F5C2B0E1109E31885C4511570C42 privValidator="PrivValidator{125B0E3C5512F5C2B0E1109E31885C4511570C42 LH:90, LR:0, LS:3}"
+I[10-04|13:54:30.394] Signed proposal                              module=consensus height=91 round=0 proposal="Proposal{91/0 1:21B79872514F (-1,:0:000000000000) {/10EDEDD7C84E.../}}"
+I[10-04|13:54:30.397] Received complete proposal block             module=consensus height=91 hash=F671D562C7B9242900A286E1882EE64E5556FE9E
+I[10-04|13:54:30.397] enterPrevote(91/0). Current: 91/0/RoundStepPropose module=consensus
+I[10-04|13:54:30.397] enterPrevote: ProposalBlock is valid         module=consensus height=91 round=0
+I[10-04|13:54:30.398] Signed and pushed vote                       module=consensus height=91 round=0 vote="Vote{0:125B0E3C5512 91/00/1(Prevote) F671D562C7B9 {/89047FFC21D8.../}}" err=null
+I[10-04|13:54:30.401] Added to prevote                             module=consensus vote="Vote{0:125B0E3C5512 91/00/1(Prevote) F671D562C7B9 {/89047FFC21D8.../}}" prevotes="VoteSet{H:91 R:0 T:1 +2/3:F671D562C7B9242900A286E1882EE64E5556FE9E:1:21B79872514F BA{1:X} map[]}"
+I[10-04|13:54:30.401] enterPrecommit(91/0). Current: 91/0/RoundStepPrevote module=consensus
+I[10-04|13:54:30.401] enterPrecommit: +2/3 prevoted proposal block. Locking module=consensus hash=F671D562C7B9242900A286E1882EE64E5556FE9E
+I[10-04|13:54:30.402] Signed and pushed vote                       module=consensus height=91 round=0 vote="Vote{0:125B0E3C5512 91/00/2(Precommit) F671D562C7B9 {/80533478E41A.../}}" err=null
+I[10-04|13:54:30.404] Added to precommit                           module=consensus vote="Vote{0:125B0E3C5512 91/00/2(Precommit) F671D562C7B9 {/80533478E41A.../}}" precommits="VoteSet{H:91 R:0 T:2 +2/3:F671D562C7B9242900A286E1882EE64E5556FE9E:1:21B79872514F BA{1:X} map[]}"
+I[10-04|13:54:30.404] enterCommit(91/0). Current: 91/0/RoundStepPrecommit module=consensus
+I[10-04|13:54:30.405] Finalizing commit of block with 0 txs        module=consensus height=91 hash=F671D562C7B9242900A286E1882EE64E5556FE9E root=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
+I[10-04|13:54:30.405] Block{
+  Header{
+    ChainID:        test-chain-3MNw2N
+    Height:         91
+    Time:           2017-10-04 13:54:30.393 +0000 UTC
+    NumTxs:         0
+    LastBlockID:    F15AB8BEF9A6AAB07E457A6E16BC410546AA4DC6:1:D505DA273544
+    LastCommit:     56FEF2EFDB8B37E9C6E6D635749DF3169D5F005D
+    Data:
+    Validators:     CE25FBFF2E10C0D51AA1A07C064A96931BC8B297
+    App:            E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
+  }#F671D562C7B9242900A286E1882EE64E5556FE9E
+  Data{
+
+  }#
+  Commit{
+    BlockID:    F15AB8BEF9A6AAB07E457A6E16BC410546AA4DC6:1:D505DA273544
+    Precommits: Vote{0:125B0E3C5512 90/00/2(Precommit) F15AB8BEF9A6 {/FE98E2B956F0.../}}
+  }#56FEF2EFDB8B37E9C6E6D635749DF3169D5F005D
+}#F671D562C7B9242900A286E1882EE64E5556FE9E module=consensus
+I[10-04|13:54:30.408] Executed block                               module=state height=91 validTxs=0 invalidTxs=0
+I[10-04|13:54:30.410] Committed state                              module=state height=91 txs=0 hash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD
+I[10-04|13:54:30.410] Recheck txs                                  module=mempool numtxs=0 height=91
+```
+
+## List of modules
+
+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
+  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).
+- `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
+  implementation of the consensus algorithm. Includes two
+  "submodules": `wal` (write-ahead logging) for ensuring data
+  integrity and `replay` to replay blocks and messages on recovery
+  from a crash.
+- `events` Simple event notification system. The list of events can be
+  found
+  [here](https://github.com/tendermint/tendermint/blob/master/types/events.go).
+  You can subscribe to them by calling `subscribe` RPC method. Refer
+  to [RPC docs](./specification/rpc.md) for additional information.
+- `mempool` Mempool module handles all incoming transactions, whenever
+  they are coming from peers or the application.
+- `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-server` RPC server. For implementation details, please read the
+  [README](https://github.com/tendermint/tendermint/blob/master/rpc/lib/README.md).
+- `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
+  work with them.

docs/tendermint-core/light-client-protocol.md

@@ -0,0 +1,30 @@
+# Light Client Protocol
+
+Light clients are an important part of the complete blockchain system
+for most applications. Tendermint provides unique speed and security
+properties for light client applications.
+
+See our [lite
+package](https://godoc.org/github.com/tendermint/tendermint/lite).
+
+## Overview
+
+The objective of the light client protocol is to get a
+[commit](./validators.md#committing-a-block) for a recent [block
+hash](../spec/consensus/consensus.md.md#block-hash) where the commit includes a
+majority of signatures from the last known validator set. From there,
+all the application state is verifiable with [merkle
+proofs](./merkle.md#iavl-tree).
+
+## Properties
+
+-   You get the full collateralized security benefits of Tendermint; No
+    need to wait for confirmations.
+-   You get the full speed benefits of Tendermint; transactions
+    commit instantly.
+-   You can get the most recent version of the application state
+    non-interactively (without committing anything to the blockchain).
+    For example, this means that you can get the most recent value of a
+    name from the name-registry without worrying about fork censorship
+    attacks, without posting a commit and waiting for confirmations.
+    It's fast, secure, and free!

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

@@ -16,7 +16,7 @@ logging level, you can do so by running tendermint with
 Validators are supposed to setup [Sentry Node
 Architecture](https://blog.cosmos.network/tendermint-explained-bringing-bft-based-pos-to-the-public-blockchain-domain-f22e274a0fdb)
 to prevent Denial-of-service attacks. You can read more about it
-[here](https://github.com/tendermint/aib-data/blob/develop/medium/TendermintBFT.md).
+[here](../interviews/tendermint-bft.md).
 
 ### P2P
 
@@ -49,21 +49,25 @@ second TODO is to query the /status RPC endpoint. It provides the
 necessary info: whenever the node is syncing or not, what height it is
 on, etc.
 
-    $ curl http(s)://{ip}:{rpcPort}/status
+```
+curl http(s)://{ip}:{rpcPort}/status
+```
 
 `dump_consensus_state` will give you a detailed overview of the
 consensus state (proposer, lastest validators, peers states). From it,
 you should be able to figure out why, for example, the network had
 halted.
 
-    $ curl http(s)://{ip}:{rpcPort}/dump_consensus_state
+```
+curl http(s)://{ip}:{rpcPort}/dump_consensus_state
+```
 
 There is a reduced version of this endpoint - `consensus_state`, which
 returns just the votes seen at the current height.
 
--   [Github Issues](https://github.com/tendermint/tendermint/issues)
--   [StackOverflow
-    questions](https://stackoverflow.com/questions/tagged/tendermint)
+- [Github Issues](https://github.com/tendermint/tendermint/issues)
+- [StackOverflow
+  questions](https://stackoverflow.com/questions/tagged/tendermint)
 
 ## Monitoring Tendermint
 
@@ -100,6 +104,69 @@ signals we use the default behaviour in Go: [Default behavior of signals
 in Go
 programs](https://golang.org/pkg/os/signal/#hdr-Default_behavior_of_signals_in_Go_programs).
 
+## Corruption
+
+**NOTE:** Make sure you have a backup of the Tendermint data directory.
+
+### Possible causes
+
+Remember that most corruption is caused by hardware issues:
+
+- RAID controllers with faulty / worn out battery backup, and an unexpected power loss
+- Hard disk drives with write-back cache enabled, and an unexpected power loss
+- Cheap SSDs with insufficient power-loss protection, and an unexpected power-loss
+- Defective RAM
+- Defective or overheating CPU(s)
+
+Other causes can be:
+
+- Database systems configured with fsync=off and an OS crash or power loss
+- Filesystems configured to use write barriers plus a storage layer that ignores write barriers. LVM is a particular culprit.
+- Tendermint bugs
+- Operating system bugs
+- Admin error (e.g., directly modifying Tendermint data-directory contents)
+
+(Source: https://wiki.postgresql.org/wiki/Corruption)
+
+### WAL Corruption
+
+If consensus WAL is corrupted at the lastest height and you are trying to start
+Tendermint, replay will fail with panic.
+
+Recovering from data corruption can be hard and time-consuming. Here are two approaches you can take:
+
+1) Delete the WAL file and restart Tendermint. It will attempt to sync with other peers.
+2) Try to repair the WAL file manually:
+
+  1. Create a backup of the corrupted WAL file:
+
+```
+cp "$TMHOME/data/cs.wal/wal" > /tmp/corrupted_wal_backup
+```
+
+  2. Use `./scripts/wal2json` to create a human-readable version
+
+```
+./scripts/wal2json/wal2json "$TMHOME/data/cs.wal/wal" > /tmp/corrupted_wal
+```
+
+  3. Search for a "CORRUPTED MESSAGE" line.
+  4. By looking at the previous message and the message after the corrupted one
+       and looking at the logs, try to rebuild the message. If the consequent
+       messages are marked as corrupted too (this may happen if length header
+       got corrupted or some writes did not make it to the WAL ~ truncation),
+       then remove all the lines starting from the corrupted one and restart
+       Tendermint.
+
+```
+$EDITOR /tmp/corrupted_wal
+```
+  5. After editing, convert this file back into binary form by running:
+
+```
+./scripts/json2wal/json2wal /tmp/corrupted_wal > "$TMHOME/data/cs.wal/wal"
+```
+
 ## Hardware
 
 ### Processor and Memory
@@ -107,18 +174,18 @@ programs](https://golang.org/pkg/os/signal/#hdr-Default_behavior_of_signals_in_G
 While actual specs vary depending on the load and validators count,
 minimal requirements are:
 
--   1GB RAM
--   25GB of disk space
--   1.4 GHz CPU
+- 1GB RAM
+- 25GB of disk space
+- 1.4 GHz CPU
 
 SSD disks are preferable for applications with high transaction
 throughput.
 
 Recommended:
 
--   2GB RAM
--   100GB SSD
--   x64 2.0 GHz 2v CPU
+- 2GB RAM
+- 100GB SSD
+- x64 2.0 GHz 2v CPU
 
 While for now, Tendermint stores all the history and it may require
 significant disk space over time, we are planning to implement state
@@ -145,21 +212,23 @@ 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
 flush throttle timeout and increase other params.
 
-    [p2p]
+```
+[p2p]
 
-    send_rate=20000000 # 2MB/s
-    recv_rate=20000000 # 2MB/s
-    flush_throttle_timeout=10
-    max_packet_msg_payload_size=10240 # 10KB
+send_rate=20000000 # 2MB/s
+recv_rate=20000000 # 2MB/s
+flush_throttle_timeout=10
+max_packet_msg_payload_size=10240 # 10KB
+```
 
--   `mempool.recheck`
+- `mempool.recheck`
 
 After every block, Tendermint rechecks every transaction left in the
 mempool to see if transactions committed in that block affected the
@@ -167,13 +236,13 @@ application state, so some of the transactions left may become invalid.
 If that does not apply to your application, you can disable it by
 setting `mempool.recheck=false`.
 
--   `mempool.broadcast`
+- `mempool.broadcast`
 
 Setting this to false will stop the mempool from relaying transactions
 to other peers until they are included in a block. It means only the
 peer you send the tx to will see it until it is included in a block.
 
--   `consensus.skip_timeout_commit`
+- `consensus.skip_timeout_commit`
 
 We want `skip_timeout_commit=false` when there is economics on the line
 because proposers should wait to hear for more votes. But if you don't
@@ -182,22 +251,17 @@ be kept false by default for public deployments (e.g. [Cosmos
 Hub](https://cosmos.network/intro/hub)) while for enterprise
 applications, setting it to true is not a problem.
 
--   `consensus.peer_gossip_sleep_duration`
+- `consensus.peer_gossip_sleep_duration`
 
 You can try to reduce the time your node sleeps before checking if
 theres something to send its peers.
 
--   `consensus.timeout_commit`
+- `consensus.timeout_commit`
 
 You can also try lowering `timeout_commit` (time we sleep before
 proposing the next block).
 
--   `consensus.max_block_size_txs`
-
-By default, the maximum number of transactions per a block is 10_000.
-Feel free to change it to suit your needs.
-
--   `p2p.addr_book_strict`
+- `p2p.addr_book_strict`
 
 By default, Tendermint checks whenever a peer's address is routable before
 saving it to the address book. The address is considered as routable if the IP

docs/tendermint-core/secure-p2p.md

@@ -1,12 +1,11 @@
-Secure P2P
-==========
+# Secure P2P
 
 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>`__.
+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
+[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
@@ -19,10 +18,9 @@ their respective ephemeral public keys. This happens in the clear.
 They then each compute the shared secret. The shared secret is the
 multiplication of the peer's ephemeral private key by the other peer's
 ephemeral public key. The result is the same for both peers by the magic
-of `elliptic
-curves <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography>`__.
-The shared secret is used as the symmetric key for the encryption
-algorithm.
+of [elliptic
+curves](https://en.wikipedia.org/wiki/Elliptic_curve_cryptography). The
+shared secret is used as the symmetric key for the encryption algorithm.
 
 The two ephemeral public keys are sorted to establish a canonical order.
 Then a 24-byte nonce is generated by concatenating the public keys and
@@ -52,8 +50,7 @@ time it is used. The communications maintain Perfect Forward Secrecy, as
 the persistent key pair was not used for generating secrets - only for
 authenticating.
 
-Caveat
-------
+## Caveat
 
 This system is still vulnerable to a Man-In-The-Middle attack if the
 persistent public key of the remote node is not known in advance. The
@@ -62,17 +59,15 @@ such as the Web-of-Trust or Certificate Authorities. In our case, we can
 use the blockchain itself as a certificate authority to ensure that we
 are connected to at least one validator.
 
-Config
-------
+## Config
 
 Authenticated encryption is enabled by default.
 
-Additional Reading
-------------------
+## Additional Reading
 
--  `Implementation <https://github.com/tendermint/go-p2p/blob/master/secret_connection.go#L49>`__
--  `Original STS paper by Whitfield Diffie, Paul C. van Oorschot and
-   Michael J.
-   Wiener <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.216.6107&rep=rep1&type=pdf>`__
--  `Further work on secret
-   handshakes <https://dominictarr.github.io/secret-handshake-paper/shs.pdf>`__
+-   [Implementation](https://github.com/tendermint/tendermint/blob/64bae01d007b5bee0d0827ab53259ffd5910b4e6/p2p/conn/secret_connection.go#L47)
+-   [Original STS paper by Whitfield Diffie, Paul C. van Oorschot and
+    Michael J.
+    Wiener](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.216.6107&rep=rep1&type=pdf)
+-   [Further work on secret
+    handshakes](https://dominictarr.github.io/secret-handshake-paper/shs.pdf)

docs/tendermint-core/using-tendermint.md

@@ -16,7 +16,9 @@ this by setting the `TMHOME` environment variable.
 
 Initialize the root directory by running:
 
-    tendermint init
+```
+tendermint init
+```
 
 This will create a new private key (`priv_validator.json`), and a
 genesis file (`genesis.json`) containing the associated public key, in
@@ -25,24 +27,97 @@ with one validator.
 
 For more elaborate initialization, see the tesnet command:
 
-    tendermint testnet --help
+```
+tendermint testnet --help
+```
+
+### Genesis
+
+The `genesis.json` file in `$TMHOME/config/` defines the initial
+TendermintCore state upon genesis of the blockchain ([see
+definition](https://github.com/tendermint/tendermint/blob/master/types/genesis.go)).
+
+#### Fields
+
+-   `genesis_time`: Official time of blockchain start.
+-   `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.
+-   `validators`:
+-   `pub_key`: The first element specifies the `pub_key` type. 1
+    == Ed25519. The second element are the pubkey bytes.
+-   `power`: The validator's voting power.
+-   `name`: Name of the validator (optional).
+-   `app_hash`: The expected application hash (as returned by the
+    `ResponseInfo` ABCI message) upon genesis. If the app's hash does
+    not match, Tendermint will panic.
+-   `app_state`: The application state (e.g. initial distribution
+    of tokens).
+
+#### Sample genesis.json
+
+```
+{
+  "genesis_time": "2018-07-09T22:43:06.255718641Z",
+  "chain_id": "chain-IAkWsK",
+  "validators": [
+    {
+      "pub_key": {
+        "type": "tendermint/PubKeyEd25519",
+        "value": "oX8HhKsErMluxI0QWNSR8djQMSupDvHdAYrHwP7n73k="
+      },
+      "power": "1",
+      "name": "node0"
+    },
+    {
+      "pub_key": {
+        "type": "tendermint/PubKeyEd25519",
+        "value": "UZNSJA9zmeFQj36Rs296lY+WFQ4Rt6s7snPpuKypl5I="
+      },
+      "power": "1",
+      "name": "node1"
+    },
+    {
+      "pub_key": {
+        "type": "tendermint/PubKeyEd25519",
+        "value": "i9GrM6/MHB4zjCelMZBUYHNXYIzl4n0RkDCVmmLhS/o="
+      },
+      "power": "1",
+      "name": "node2"
+    },
+    {
+      "pub_key": {
+        "type": "tendermint/PubKeyEd25519",
+        "value": "0qq7954l87trEqbQV9c7d1gurnjTGMxreXc848ZZ5aw="
+      },
+      "power": "1",
+      "name": "node3"
+    }
+  ],
+  "app_hash": ""
+}
+```
 
 ## Run
 
 To run a Tendermint node, use
 
-    tendermint node
+```
+tendermint node
+```
 
 By default, Tendermint will try to connect to an ABCI application on
 [127.0.0.1:26658](127.0.0.1:26658). If you have the `kvstore` ABCI app
 installed, run it in another window. If you don't, kill Tendermint and
 run an in-process version of the `kvstore` app:
 
-    tendermint node --proxy_app=kvstore
+```
+tendermint node --proxy_app=kvstore
+```
 
 After a few seconds you should see blocks start streaming in. Note that
 blocks are produced regularly, even if there are no transactions. See
-*No Empty Blocks*, below, to modify this setting.
+_No Empty Blocks_, below, to modify this setting.
 
 Tendermint supports in-process versions of the `counter`, `kvstore` and
 `nil` apps that ship as examples with `abci-cli`. It's easy to compile
@@ -51,22 +126,30 @@ app is not written in Go, simply run it in another process, and use the
 `--proxy_app` flag to specify the address of the socket it is listening
 on, for instance:
 
-    tendermint node --proxy_app=/var/run/abci.sock
+```
+tendermint node --proxy_app=/var/run/abci.sock
+```
 
 ## Transactions
 
 To send a transaction, use `curl` to make requests to the Tendermint RPC
 server, for example:
 
-    curl http://localhost:26657/broadcast_tx_commit?tx=\"abcd\"
+```
+curl http://localhost:26657/broadcast_tx_commit?tx=\"abcd\"
+```
 
 We can see the chain's status at the `/status` end-point:
 
-    curl http://localhost:26657/status | json_pp
+```
+curl http://localhost:26657/status | json_pp
+```
 
 and the `latest_app_hash` in particular:
 
-    curl http://localhost:26657/status | json_pp | grep latest_app_hash
+```
+curl http://localhost:26657/status | json_pp | grep latest_app_hash
+```
 
 Visit http://localhost:26657> in your browser to see the list of other
 endpoints. Some take no arguments (like `/status`), while others specify
@@ -81,30 +164,40 @@ With `GET`:
 
 To send a UTF8 string byte array, quote the value of the tx pramater:
 
-    curl 'http://localhost:26657/broadcast_tx_commit?tx="hello"'
+```
+curl 'http://localhost:26657/broadcast_tx_commit?tx="hello"'
+```
 
 which sends a 5 byte transaction: "h e l l o" \[68 65 6c 6c 6f\].
 
 Note the URL must be wrapped with single quoes, else bash will ignore
 the double quotes. To avoid the single quotes, escape the double quotes:
 
-    curl http://localhost:26657/broadcast_tx_commit?tx=\"hello\"
+```
+curl http://localhost:26657/broadcast_tx_commit?tx=\"hello\"
+```
 
 Using a special character:
 
-    curl 'http://localhost:26657/broadcast_tx_commit?tx="€5"'
+```
+curl 'http://localhost:26657/broadcast_tx_commit?tx="€5"'
+```
 
 sends a 4 byte transaction: "€5" (UTF8) \[e2 82 ac 35\].
 
 To send as raw hex, omit quotes AND prefix the hex string with `0x`:
 
-    curl http://localhost:26657/broadcast_tx_commit?tx=0x01020304
+```
+curl http://localhost:26657/broadcast_tx_commit?tx=0x01020304
+```
 
 which sends a 4 byte transaction: \[01 02 03 04\].
 
 With `POST` (using `json`), the raw hex must be `base64` encoded:
 
-    curl --data-binary '{"jsonrpc":"2.0","id":"anything","method":"broadcast_tx_commit","params": {"tx": "AQIDBA=="}}' -H 'content-type:text/plain;' http://localhost:26657
+```
+curl --data-binary '{"jsonrpc":"2.0","id":"anything","method":"broadcast_tx_commit","params": {"tx": "AQIDBA=="}}' -H 'content-type:text/plain;' http://localhost:26657
+```
 
 which sends the same 4 byte transaction: \[01 02 03 04\].
 
@@ -118,7 +211,9 @@ afford to lose all blockchain data!
 To reset a blockchain, stop the node, remove the `~/.tendermint/data`
 directory and run
 
-    tendermint unsafe_reset_priv_validator
+```
+tendermint unsafe_reset_priv_validator
+```
 
 This final step is necessary to reset the `priv_validator.json`, which
 otherwise prevents you from making conflicting votes in the consensus
@@ -150,21 +245,27 @@ To configure Tendermint to not produce empty blocks unless there are
 transactions or the app hash changes, run Tendermint with this
 additional flag:
 
-    tendermint node --consensus.create_empty_blocks=false
+```
+tendermint node --consensus.create_empty_blocks=false
+```
 
 or set the configuration via the `config.toml` file:
 
-    [consensus]
-    create_empty_blocks = false
+```
+[consensus]
+create_empty_blocks = false
+```
 
-Remember: because the default is to *create empty blocks*, avoiding
+Remember: because the default is to _create empty blocks_, avoiding
 empty blocks requires the config option to be set to `false`.
 
 The block interval setting allows for a delay (in seconds) between the
 creation of each new empty block. It is set via the `config.toml`:
 
-    [consensus]
-    create_empty_blocks_interval = 5
+```
+[consensus]
+create_empty_blocks_interval = 5
+```
 
 With this setting, empty blocks will be produced every 5s if no block
 has been produced otherwise, regardless of the value of
@@ -181,9 +282,11 @@ eventually included in a block.
 Since there are multiple phases to processing a transaction, we offer
 multiple endpoints to broadcast a transaction:
 
-    /broadcast_tx_async
-    /broadcast_tx_sync
-    /broadcast_tx_commit
+```
+/broadcast_tx_async
+/broadcast_tx_sync
+/broadcast_tx_commit
+```
 
 These correspond to no-processing, processing through the mempool, and
 processing through a block, respectively. That is, `broadcast_tx_async`,
@@ -208,38 +311,42 @@ When `tendermint init` is run, both a `genesis.json` and
 `priv_validator.json` are created in `~/.tendermint/config`. The
 `genesis.json` might look like:
 
+```
+{
+  "validators" : [
     {
-      "validators" : [
-        {
-          "pub_key" : {
-            "value" : "h3hk+QE8c6QLTySp8TcfzclJw/BG79ziGB/pIA+DfPE=",
-            "type" : "tendermint/PubKeyEd25519"
-          },
-          "power" : 10,
-          "name" : ""
-        }
-      ],
-      "app_hash" : "",
-      "chain_id" : "test-chain-rDlYSN",
-      "genesis_time" : "0001-01-01T00:00:00Z"
-    }
-
-And the `priv_validator.json`:
-
-    {
-      "last_step" : 0,
-      "last_round" : "0",
-      "address" : "B788DEDE4F50AD8BC9462DE76741CCAFF87D51E2",
       "pub_key" : {
         "value" : "h3hk+QE8c6QLTySp8TcfzclJw/BG79ziGB/pIA+DfPE=",
         "type" : "tendermint/PubKeyEd25519"
       },
-      "last_height" : "0",
-      "priv_key" : {
-        "value" : "JPivl82x+LfVkp8i3ztoTjY6c6GJ4pBxQexErOCyhwqHeGT5ATxzpAtPJKnxNx/NyUnD8Ebv3OIYH+kgD4N88Q==",
-        "type" : "tendermint/PrivKeyEd25519"
-      }
+      "power" : 10,
+      "name" : ""
     }
+  ],
+  "app_hash" : "",
+  "chain_id" : "test-chain-rDlYSN",
+  "genesis_time" : "0001-01-01T00:00:00Z"
+}
+```
+
+And the `priv_validator.json`:
+
+```
+{
+  "last_step" : 0,
+  "last_round" : "0",
+  "address" : "B788DEDE4F50AD8BC9462DE76741CCAFF87D51E2",
+  "pub_key" : {
+    "value" : "h3hk+QE8c6QLTySp8TcfzclJw/BG79ziGB/pIA+DfPE=",
+    "type" : "tendermint/PubKeyEd25519"
+  },
+  "last_height" : "0",
+  "priv_key" : {
+    "value" : "JPivl82x+LfVkp8i3ztoTjY6c6GJ4pBxQexErOCyhwqHeGT5ATxzpAtPJKnxNx/NyUnD8Ebv3OIYH+kgD4N88Q==",
+    "type" : "tendermint/PrivKeyEd25519"
+  }
+}
+```
 
 The `priv_validator.json` actually contains a private key, and should
 thus be kept absolutely secret; for now we work with the plain text.
@@ -272,6 +379,7 @@ with the consensus protocol.
 ### Peers
 
 #### Seed
+
 A seed node is a node who relays the addresses of other peers which they know
 of. These nodes constantly crawl the network to try to get more peers. The
 addresses which the seed node relays get saved into a local address book. Once
@@ -282,6 +390,7 @@ only need them on the first start. The seed node will immediately disconnect
 from you after sending you some addresses.
 
 #### Persistent Peer
+
 Persistent peers are people you want to be constantly connected with. If you
 disconnect you will try to connect directly back to them as opposed to using
 another address from the address book. On restarts you will always try to
@@ -302,12 +411,16 @@ persistent connections with.
 
 For example,
 
-    tendermint node --p2p.seeds "f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@1.2.3.4:26656,0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@5.6.7.8:26656"
+```
+tendermint node --p2p.seeds "f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@1.2.3.4:26656,0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@5.6.7.8:26656"
+```
 
 Alternatively, you can use the `/dial_seeds` endpoint of the RPC to
 specify seeds for a running node to connect to:
 
-    curl 'localhost:26657/dial_seeds?seeds=\["f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@1.2.3.4:26656","0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@5.6.7.8:26656"\]'
+```
+curl 'localhost:26657/dial_seeds?seeds=\["f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@1.2.3.4:26656","0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@5.6.7.8:26656"\]'
+```
 
 Note, with PeX enabled, you
 should not need seeds after the first start.
@@ -318,8 +431,11 @@ maintain a persistent connection with each, you can use the
 `config.toml` or the `/dial_peers` RPC endpoint to do it without
 stopping Tendermint core instance.
 
-    tendermint node --p2p.persistent_peers "429fcf25974313b95673f58d77eacdd434402665@10.11.12.13:26656,96663a3dd0d7b9d17d4c8211b191af259621c693@10.11.12.14:26656"
-    curl 'localhost:26657/dial_peers?persistent=true&peers=\["429fcf25974313b95673f58d77eacdd434402665@10.11.12.13:26656","96663a3dd0d7b9d17d4c8211b191af259621c693@10.11.12.14:26656"\]'
+```
+tendermint node --p2p.persistent_peers "429fcf25974313b95673f58d77eacdd434402665@10.11.12.13:26656,96663a3dd0d7b9d17d4c8211b191af259621c693@10.11.12.14:26656"
+
+curl 'localhost:26657/dial_peers?persistent=true&peers=\["429fcf25974313b95673f58d77eacdd434402665@10.11.12.13:26656","96663a3dd0d7b9d17d4c8211b191af259621c693@10.11.12.14:26656"\]'
+```
 
 ### Adding a Non-Validator
 
@@ -338,51 +454,57 @@ before starting the network. For instance, we could make a new
 
 We can generate a new `priv_validator.json` with the command:
 
-    tendermint gen_validator
+```
+tendermint gen_validator
+```
 
 Now we can update our genesis file. For instance, if the new
 `priv_validator.json` looks like:
 
+```
+{
+  "address" : "5AF49D2A2D4F5AD4C7C8C4CC2FB020131E9C4902",
+  "pub_key" : {
+    "value" : "l9X9+fjkeBzDfPGbUM7AMIRE6uJN78zN5+lk5OYotek=",
+    "type" : "tendermint/PubKeyEd25519"
+  },
+  "priv_key" : {
+    "value" : "EDJY9W6zlAw+su6ITgTKg2nTZcHAH1NMTW5iwlgmNDuX1f35+OR4HMN88ZtQzsAwhETq4k3vzM3n6WTk5ii16Q==",
+    "type" : "tendermint/PrivKeyEd25519"
+  },
+  "last_step" : 0,
+  "last_round" : "0",
+  "last_height" : "0"
+}
+```
+
+then the new `genesis.json` will be:
+
+```
+{
+  "validators" : [
+    {
+      "pub_key" : {
+        "value" : "h3hk+QE8c6QLTySp8TcfzclJw/BG79ziGB/pIA+DfPE=",
+        "type" : "tendermint/PubKeyEd25519"
+      },
+      "power" : 10,
+      "name" : ""
+    },
     {
-      "address" : "5AF49D2A2D4F5AD4C7C8C4CC2FB020131E9C4902",
       "pub_key" : {
         "value" : "l9X9+fjkeBzDfPGbUM7AMIRE6uJN78zN5+lk5OYotek=",
         "type" : "tendermint/PubKeyEd25519"
       },
-      "priv_key" : {
-        "value" : "EDJY9W6zlAw+su6ITgTKg2nTZcHAH1NMTW5iwlgmNDuX1f35+OR4HMN88ZtQzsAwhETq4k3vzM3n6WTk5ii16Q==",
-        "type" : "tendermint/PrivKeyEd25519"
-      },
-      "last_step" : 0,
-      "last_round" : "0",
-      "last_height" : "0"
-    }
-
-then the new `genesis.json` will be:
-
-    {
-      "validators" : [
-        {
-          "pub_key" : {
-            "value" : "h3hk+QE8c6QLTySp8TcfzclJw/BG79ziGB/pIA+DfPE=",
-            "type" : "tendermint/PubKeyEd25519"
-          },
-          "power" : 10,
-          "name" : ""
-        },
-        {
-          "pub_key" : {
-            "value" : "l9X9+fjkeBzDfPGbUM7AMIRE6uJN78zN5+lk5OYotek=",
-            "type" : "tendermint/PubKeyEd25519"
-          },
-          "power" : 10,
-          "name" : ""
-        }
-      ],
-      "app_hash" : "",
-      "chain_id" : "test-chain-rDlYSN",
-      "genesis_time" : "0001-01-01T00:00:00Z"
+      "power" : 10,
+      "name" : ""
     }
+  ],
+  "app_hash" : "",
+  "chain_id" : "test-chain-rDlYSN",
+  "genesis_time" : "0001-01-01T00:00:00Z"
+}
+```
 
 Update the `genesis.json` in `~/.tendermint/config`. Copy the genesis
 file and the new `priv_validator.json` to the `~/.tendermint/config` on

docs/tendermint-core/validators.md

@@ -1,5 +1,4 @@
-Validators
-==========
+# Validators
 
 Validators are responsible for committing new blocks in the blockchain.
 These validators participate in the consensus protocol by broadcasting
@@ -19,25 +18,22 @@ to post any collateral at all.
 Validators have a cryptographic key-pair and an associated amount of
 "voting power". Voting power need not be the same.
 
-Becoming a Validator
---------------------
+## Becoming a Validator
 
 There are two ways to become validator.
 
-1. They can be pre-established in the `genesis
-   state <./genesis.html>`__
-2. The ABCI app responds to the EndBlock message with changes to the
-   existing validator set.
+1.  They can be pre-established in the [genesis state](../../tendermint-core/using-tendermint.md#genesis)
+2.  The ABCI app responds to the EndBlock message with changes to the
+    existing validator set.
 
-Committing a Block
-------------------
+## Committing a Block
 
 *+2/3 is short for "more than 2/3"*
 
-A block is committed when +2/3 of the validator set sign `precommit
-votes <./block-structure.html#vote>`__ for that block at the same
-``round``. The +2/3 set of precommit votes is
-called a `*commit* <./block-structure.html#commit>`__. While any
-+2/3 set of precommits for the same block at the same height&round can
-serve as validation, the canonical commit is included in the next block
-(see `LastCommit <./block-structure.html>`__).
+A block is committed when +2/3 of the validator set sign [precommit
+votes](../spec/blockchain/blockchain.md#vote) for that block at the same `round`.
+The +2/3 set of precommit votes is called a
+[*commit*](../spec/blockchain/blockchain.md#commit). While any +2/3 set of
+precommits for the same block at the same height&round can serve as
+validation, the canonical commit is included in the next block (see
+[LastCommit](../spec/blockchain/blockchain.md#last-commit)).

docs/tools/benchmarking.md

@@ -0,0 +1,80 @@
+# tm-bench
+
+Tendermint blockchain benchmarking tool:
+
+- https://github.com/tendermint/tools/tree/master/tm-bench
+
+For example, the following:
+
+```
+tm-bench -T 10 -r 1000 localhost:26657
+```
+
+will output:
+
+```
+Stats          Avg       StdDev     Max      Total
+Txs/sec        818       532        1549     9000
+Blocks/sec     0.818     0.386      1        9
+```
+
+## Quick Start
+
+[Install Tendermint](../introduction/install)
+This currently is setup to work on tendermint's develop branch. Please ensure
+you are on that. (If not, update `tendermint` and `tmlibs` in gopkg.toml to use
+  the master branch.)
+
+then run:
+
+```
+tendermint init
+tendermint node --proxy_app=kvstore
+```
+
+```    
+tm-bench localhost:26657
+```
+
+with the last command being in a seperate window.
+
+## Usage
+
+```
+tm-bench [-c 1] [-T 10] [-r 1000] [-s 250] [endpoints]
+
+Examples:
+        tm-bench localhost:26657
+Flags:
+  -T int
+        Exit after the specified amount of time in seconds (default 10)
+  -c int
+        Connections to keep open per endpoint (default 1)
+  -r int
+        Txs per second to send in a connection (default 1000)
+  -s int
+        Size per tx in bytes
+  -v    Verbose output
+```
+
+## How stats are collected
+
+These stats are derived by having each connection send transactions at the
+specified rate (or as close as it can get) for the specified time. After the
+specified time, it iterates over all of the blocks that were created in that
+time. The average and stddev per second are computed based off of that, by
+grouping the data by second.
+
+To send transactions at the specified rate in each connection, we loop
+through the number of transactions. If its too slow, the loop stops at one second.
+If its too fast, we wait until the one second mark ends. The transactions per
+second stat is computed based off of what ends up in the block.
+
+Each of the connections is handled via two separate goroutines.
+
+## Development
+
+```
+make get_vendor_deps
+make test
+```

docs/tools/monitoring.md

@@ -0,0 +1,92 @@
+# tm-monitor
+
+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
+
+## Quick Start
+
+### Docker
+
+Assuming your application is running in another container with the name
+`app`:
+
+```
+docker run -it --rm -v "/tmp:/tendermint" tendermint/tendermint init
+docker run -it --rm -v "/tmp:/tendermint" -p "26657:26657" --name=tm --link=app tendermint/tendermint node --proxy_app=tcp://app:26658
+
+docker run -it --rm -p "26670:26670" --link=tm tendermint/monitor tm:26657
+```
+
+If you don't have an application yet, but still want to try monitor out,
+use `kvstore`:
+
+```
+docker run -it --rm -v "/tmp:/tendermint" tendermint/tendermint init
+docker run -it --rm -v "/tmp:/tendermint" -p "26657:26657" --name=tm tendermint/tendermint node --proxy_app=kvstore
+```
+```
+docker run -it --rm -p "26670:26670" --link=tm tendermint/monitor tm:26657
+```
+
+### Using Binaries
+
+[Install Tendermint](https://github.com/tendermint/tendermint#install)
+
+then run:
+
+```
+tendermint init
+tendermint node --proxy_app=kvstore
+```
+
+```
+tm-monitor localhost:26657
+```
+
+with the last command being in a seperate window.
+
+## Usage
+
+```
+tm-monitor [-v] [-no-ton] [-listen-addr="tcp://0.0.0.0:26670"] [endpoints]
+
+Examples:
+        # monitor single instance
+        tm-monitor localhost:26657
+
+        # monitor a few instances by providing comma-separated list of RPC endpoints
+        tm-monitor host1:26657,host2:26657
+Flags:
+  -listen-addr string
+        HTTP and Websocket server listen address (default "tcp://0.0.0.0:26670")
+  -no-ton
+        Do not show ton (table of nodes)
+  -v    verbose logging
+```
+
+### RPC UI
+
+Run `tm-monitor` and visit http://localhost:26670 You should see the
+list of the available RPC endpoints:
+
+```   
+http://localhost:26670/status
+http://localhost:26670/status/network
+http://localhost:26670/monitor?endpoint=_
+http://localhost:26670/status/node?name=_
+http://localhost:26670/unmonitor?endpoint=_
+```
+
+The API is available as GET requests with URI encoded parameters, or as
+JSONRPC POST requests. The JSONRPC methods are also exposed over
+websocket.
+
+## Development
+
+```
+make get_tools
+make get_vendor_deps
+make test
+```

evidence/reactor.go

@@ -5,10 +5,10 @@ import (
 	"reflect"
 	"time"
 
-	"github.com/tendermint/go-amino"
+	amino "github.com/tendermint/go-amino"
+
 	clist "github.com/tendermint/tendermint/libs/clist"
 	"github.com/tendermint/tendermint/libs/log"
-
 	"github.com/tendermint/tendermint/p2p"
 	"github.com/tendermint/tendermint/types"
 )
@@ -73,7 +73,7 @@ func (evR *EvidenceReactor) RemovePeer(peer p2p.Peer, reason interface{}) {
 // Receive implements Reactor.
 // It adds any received evidence to the evpool.
 func (evR *EvidenceReactor) Receive(chID byte, src p2p.Peer, msgBytes []byte) {
-	msg, err := DecodeMessage(msgBytes)
+	msg, err := decodeMsg(msgBytes)
 	if err != nil {
 		evR.Logger.Error("Error decoding message", "src", src, "chId", chID, "msg", msg, "err", err, "bytes", msgBytes)
 		evR.Switch.StopPeerForError(src, err)
@@ -204,11 +204,9 @@ func RegisterEvidenceMessages(cdc *amino.Codec) {
 		"tendermint/evidence/EvidenceListMessage", nil)
 }
 
-// DecodeMessage decodes a byte-array into a EvidenceMessage.
-func DecodeMessage(bz []byte) (msg EvidenceMessage, err error) {
+func decodeMsg(bz []byte) (msg EvidenceMessage, err error) {
 	if len(bz) > maxMsgSize {
-		return msg, fmt.Errorf("Msg exceeds max size (%d > %d)",
-			len(bz), maxMsgSize)
+		return msg, fmt.Errorf("Msg exceeds max size (%d > %d)", len(bz), maxMsgSize)
 	}
 	err = cdc.UnmarshalBinaryBare(bz, &msg)
 	return

libs/CODEOWNERS

@@ -1,3 +0,0 @@
-*       @melekes @ebuchman
-*.md    @zramsay
-*.rst   @zramsay

libs/Gopkg.toml

@@ -1,69 +0,0 @@
-# Gopkg.toml example
-#
-# Refer to https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
-# for detailed Gopkg.toml documentation.
-#
-# required = ["github.com/user/thing/cmd/thing"]
-# ignored = ["github.com/user/project/pkgX", "bitbucket.org/user/project/pkgA/pkgY"]
-#
-# [[constraint]]
-#   name = "github.com/user/project"
-#   version = "1.0.0"
-#
-# [[constraint]]
-#   name = "github.com/user/project2"
-#   branch = "dev"
-#   source = "github.com/myfork/project2"
-#
-# [[override]]
-#   name = "github.com/x/y"
-#   version = "2.4.0"
-#
-# [prune]
-#   non-go = false
-#   go-tests = true
-#   unused-packages = true
-
-
-[[constraint]]
-  branch = "master"
-  name = "github.com/fortytw2/leaktest"
-
-[[constraint]]
-  name = "github.com/go-kit/kit"
-  version = "0.6.0"
-
-[[constraint]]
-  name = "github.com/go-logfmt/logfmt"
-  version = "0.3.0"
-
-[[constraint]]
-  name = "github.com/gogo/protobuf"
-  version = "1.0.0"
-
-[[constraint]]
-  branch = "master"
-  name = "github.com/jmhodges/levigo"
-
-[[constraint]]
-  name = "github.com/pkg/errors"
-  version = "0.8.0"
-
-[[constraint]]
-  name = "github.com/spf13/cobra"
-  version = "0.0.1"
-
-[[constraint]]
-  name = "github.com/spf13/viper"
-  version = "1.0.0"
-
-[[constraint]]
-  name = "github.com/stretchr/testify"
-  version = "1.2.1"
-
-[[constraint]]
-  name = "github.com/btcsuite/btcutil"
-  branch ="master"
-[prune]
-  go-tests = true
-  unused-packages = true

libs/Makefile

@@ -1,137 +0,0 @@
-GOTOOLS = \
-	github.com/golang/dep/cmd/dep \
-	github.com/golang/protobuf/protoc-gen-go \
-	github.com/square/certstrap
-	# github.com/alecthomas/gometalinter.v2 \
-
-GOTOOLS_CHECK = dep gometalinter.v2 protoc protoc-gen-go
-INCLUDE = -I=. -I=${GOPATH}/src
-
-all: check get_vendor_deps protoc grpc_dbserver build test install metalinter
-
-check: check_tools
-
-########################################
-###  Build
-
-protoc:
-	## If you get the following error,
-	## "error while loading shared libraries: libprotobuf.so.14: cannot open shared object file: No such file or directory"
-	## See https://stackoverflow.com/a/25518702
-	protoc $(INCLUDE) --go_out=plugins=grpc:. common/*.proto
-	@echo "--> adding nolint declarations to protobuf generated files"
-	@awk '/package common/ { print "//nolint: gas"; print; next }1' common/types.pb.go > common/types.pb.go.new
-	@mv common/types.pb.go.new common/types.pb.go
-
-build:
-	# Nothing to build!
-
-install:
-	# Nothing to install!
-
-
-########################################
-### Tools & dependencies
-
-check_tools:
-	@# https://stackoverflow.com/a/25668869
-	@echo "Found tools: $(foreach tool,$(GOTOOLS_CHECK),\
-        $(if $(shell which $(tool)),$(tool),$(error "No $(tool) in PATH")))"
-
-get_tools:
-	@echo "--> Installing tools"
-	go get -u -v $(GOTOOLS)
-	# @gometalinter.v2 --install
-
-get_protoc:
-	@# https://github.com/google/protobuf/releases
-	curl -L https://github.com/google/protobuf/releases/download/v3.4.1/protobuf-cpp-3.4.1.tar.gz | tar xvz && \
-		cd protobuf-3.4.1 && \
-		DIST_LANG=cpp ./configure && \
-		make && \
-		make install && \
-		cd .. && \
-		rm -rf protobuf-3.4.1
-
-update_tools:
-	@echo "--> Updating tools"
-	@go get -u $(GOTOOLS)
-
-get_vendor_deps:
-	@rm -rf vendor/
-	@echo "--> Running dep ensure"
-	@dep ensure
-
-
-########################################
-### Testing
-
-gen_certs: clean_certs
-	## Generating certificates for TLS testing...
-	certstrap init --common-name "tendermint.com" --passphrase ""
-	certstrap request-cert -ip "::" --passphrase ""
-	certstrap sign "::" --CA "tendermint.com" --passphrase ""
-	mv out/::.crt out/::.key db/remotedb
-
-clean_certs:
-	## Cleaning TLS testing certificates...
-	rm -rf out
-	rm -f db/remotedb/::.crt db/remotedb/::.key
-
-test: gen_certs
-	GOCACHE=off go test -tags gcc $(shell go list ./... | grep -v vendor)
-	make clean_certs
-
-test100:
-	@for i in {1..100}; do make test; done
-
-
-########################################
-### Formatting, linting, and vetting
-
-fmt:
-	@go fmt ./...
-
-metalinter:
-	@echo "==> Running linter"
-	gometalinter.v2 --vendor --deadline=600s --disable-all  \
-		--enable=deadcode \
-		--enable=goconst \
-		--enable=goimports \
-		--enable=gosimple \
-		--enable=ineffassign \
-		--enable=megacheck \
-		--enable=misspell \
-		--enable=staticcheck \
-		--enable=safesql \
-		--enable=structcheck \
-		--enable=unconvert \
-		--enable=unused \
-		--enable=varcheck \
-		--enable=vetshadow \
-		./...
-
-		#--enable=maligned \
-		#--enable=gas \
-		#--enable=aligncheck \
-		#--enable=dupl \
-		#--enable=errcheck \
-		#--enable=gocyclo \
-		#--enable=golint \ <== comments on anything exported
-		#--enable=gotype \
-		#--enable=interfacer \
-		#--enable=unparam \
-		#--enable=vet \
-
-metalinter_all:
-	protoc $(INCLUDE) --lint_out=. types/*.proto
-	gometalinter.v2 --vendor --deadline=600s --enable-all --disable=lll ./...
-
-
-# To avoid unintended conflicts with file names, always add to .PHONY
-# unless there is a reason not to.
-# https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html
-.PHONY: check protoc build check_tools get_tools get_protoc update_tools get_vendor_deps test fmt metalinter metalinter_all gen_certs clean_certs
-
-grpc_dbserver:
-	protoc -I db/remotedb/proto/ db/remotedb/proto/defs.proto --go_out=plugins=grpc:db/remotedb/proto

libs/common/array.go

@@ -1,5 +0,0 @@
-package common
-
-func Arr(items ...interface{}) []interface{} {
-	return items
-}

libs/glide.lock

@@ -1,108 +0,0 @@
-hash: 98752078f39da926f655268b3b143f713d64edd379fc9fcb1210d9d8aa7ab4e0
-updated: 2018-02-03T01:28:00.221548057-05:00
-imports:
-- name: github.com/fsnotify/fsnotify
-  version: c2828203cd70a50dcccfb2761f8b1f8ceef9a8e9
-- name: github.com/go-kit/kit
-  version: 4dc7be5d2d12881735283bcab7352178e190fc71
-  subpackages:
-  - log
-  - log/level
-  - log/term
-- name: github.com/go-logfmt/logfmt
-  version: 390ab7935ee28ec6b286364bba9b4dd6410cb3d5
-- name: github.com/go-stack/stack
-  version: 817915b46b97fd7bb80e8ab6b69f01a53ac3eebf
-- name: github.com/gogo/protobuf
-  version: 1adfc126b41513cc696b209667c8656ea7aac67c
-  subpackages:
-  - gogoproto
-  - proto
-  - protoc-gen-gogo/descriptor
-- name: github.com/golang/snappy
-  version: 553a641470496b2327abcac10b36396bd98e45c9
-- name: github.com/hashicorp/hcl
-  version: 23c074d0eceb2b8a5bfdbb271ab780cde70f05a8
-  subpackages:
-  - hcl/ast
-  - hcl/parser
-  - hcl/scanner
-  - hcl/strconv
-  - hcl/token
-  - json/parser
-  - json/scanner
-  - json/token
-- name: github.com/inconshreveable/mousetrap
-  version: 76626ae9c91c4f2a10f34cad8ce83ea42c93bb75
-- name: github.com/jmhodges/levigo
-  version: c42d9e0ca023e2198120196f842701bb4c55d7b9
-- name: github.com/kr/logfmt
-  version: b84e30acd515aadc4b783ad4ff83aff3299bdfe0
-- name: github.com/magiconair/properties
-  version: 49d762b9817ba1c2e9d0c69183c2b4a8b8f1d934
-- name: github.com/mitchellh/mapstructure
-  version: b4575eea38cca1123ec2dc90c26529b5c5acfcff
-- name: github.com/pelletier/go-toml
-  version: acdc4509485b587f5e675510c4f2c63e90ff68a8
-- name: github.com/pkg/errors
-  version: 645ef00459ed84a119197bfb8d8205042c6df63d
-- name: github.com/spf13/afero
-  version: bb8f1927f2a9d3ab41c9340aa034f6b803f4359c
-  subpackages:
-  - mem
-- name: github.com/spf13/cast
-  version: acbeb36b902d72a7a4c18e8f3241075e7ab763e4
-- name: github.com/spf13/cobra
-  version: 7b2c5ac9fc04fc5efafb60700713d4fa609b777b
-- name: github.com/spf13/jwalterweatherman
-  version: 7c0cea34c8ece3fbeb2b27ab9b59511d360fb394
-- name: github.com/spf13/pflag
-  version: 97afa5e7ca8a08a383cb259e06636b5e2cc7897f
-- name: github.com/spf13/viper
-  version: 25b30aa063fc18e48662b86996252eabdcf2f0c7
-- name: github.com/syndtr/goleveldb
-  version: b89cc31ef7977104127d34c1bd31ebd1a9db2199
-  subpackages:
-  - leveldb
-  - leveldb/cache
-  - leveldb/comparer
-  - leveldb/errors
-  - leveldb/filter
-  - leveldb/iterator
-  - leveldb/journal
-  - leveldb/memdb
-  - leveldb/opt
-  - leveldb/storage
-  - leveldb/table
-  - leveldb/util
-- name: golang.org/x/crypto
-  version: edd5e9b0879d13ee6970a50153d85b8fec9f7686
-  subpackages:
-  - ripemd160
-- name: golang.org/x/sys
-  version: 37707fdb30a5b38865cfb95e5aab41707daec7fd
-  subpackages:
-  - unix
-- name: golang.org/x/text
-  version: c01e4764d870b77f8abe5096ee19ad20d80e8075
-  subpackages:
-  - transform
-  - unicode/norm
-- name: gopkg.in/yaml.v2
-  version: d670f9405373e636a5a2765eea47fac0c9bc91a4
-testImports:
-- name: github.com/davecgh/go-spew
-  version: 346938d642f2ec3594ed81d874461961cd0faa76
-  subpackages:
-  - spew
-- name: github.com/fortytw2/leaktest
-  version: 3b724c3d7b8729a35bf4e577f71653aec6e53513
-- name: github.com/pmezard/go-difflib
-  version: d8ed2627bdf02c080bf22230dbb337003b7aba2d
-  subpackages:
-  - difflib
-- name: github.com/stretchr/testify
-  version: 12b6f73e6084dad08a7c6e575284b177ecafbc71
-  subpackages:
-  - assert
-  - require

libs/glide.yaml

@@ -1,38 +0,0 @@
-package: github.com/tendermint/tmlibs
-import:
-- package: github.com/go-kit/kit
-  version: ^0.6.0
-  subpackages:
-  - log
-  - log/level
-  - log/term
-- package: github.com/go-logfmt/logfmt
-  version: ^0.3.0
-- package: github.com/gogo/protobuf
-  version: ^1.0.0
-  subpackages:
-  - gogoproto
-  - proto
-- package: github.com/jmhodges/levigo
-- package: github.com/pkg/errors
-  version: ^0.8.0
-- package: github.com/spf13/cobra
-  version: ^0.0.1
-- package: github.com/spf13/viper
-  version: ^1.0.0
-- package: github.com/syndtr/goleveldb
-  subpackages:
-  - leveldb
-  - leveldb/errors
-  - leveldb/iterator
-  - leveldb/opt
-- package: golang.org/x/crypto
-  subpackages:
-  - ripemd160
-testImport:
-- package: github.com/stretchr/testify
-  version: ^1.2.1
-  subpackages:
-  - assert
-  - require
-- package: github.com/fortytw2/leaktest

libs/merge.sh

@@ -1,54 +0,0 @@
-#! /bin/bash
-set -e
-
-# NOTE: go-alert depends on go-common
-
-REPOS=("autofile" "clist" "db" "events" "flowrate" "logger" "process")
-
-mkdir common
-git mv *.go common
-git mv LICENSE common
-
-git commit -m "move all files to common/ to begin repo merge"
-
-for repo in "${REPOS[@]}"; do 
-	# add and fetch the repo
-	git remote add -f "$repo" "https://github.com/tendermint/go-${repo}"
-
-	# merge master and move into subdir
-	git merge "$repo/master" --no-edit
-
-	if [[ "$repo" != "flowrate" ]]; then
-		mkdir "$repo"
-		git mv *.go "$repo/"
-	fi
-
-	set +e # these might not exist
-        git mv *.md "$repo/"
-	git mv README "$repo/README.md"
-	git mv Makefile "$repo/Makefile"
-        git rm LICENSE
-	set -e
-        
-	# commit
-	git commit -m "merge go-${repo}"
-
-	git remote rm "$repo"
-done
-
-go get github.com/ebuchman/got
-got replace "tendermint/go-common" "tendermint/go-common/common"
-for repo in "${REPOS[@]}"; do 
-
-	if [[ "$repo" != "flowrate" ]]; then
-		got replace "tendermint/go-${repo}" "tendermint/go-common/${repo}"
-	else
-		got replace "tendermint/go-${repo}/flowrate" "tendermint/go-common/flowrate"
-	fi
-done
-
-git add -u 
-git commit -m "update import paths"
-
-# TODO: change any paths in non-Go files
-# TODO: add license