Merge remote-tracking branch 'origin/develop' into rigel/fee-distribution

docs/spec/ibc/appendices.md

@@ -8,7 +8,7 @@ The specification has focused on semantics and functionality of the IBC protocol
 
 In defining a standard binary encoding for all the "universal" components, we wish to make use of a standardized library, with efficient serialization and support in multiple languages. We considered two main formats: Ethereum's RLP[[6](./references.md#6)] and Google's Protobuf[[7](./references.md#7)]. We decided for protobuf, as it is more widely supported, is more expressive for different data types, and supports code generation for very efficient (de)serialization codecs. It does have a learning curve and more setup to generate the code from the type specifications, but the ibc data types should not change often and this code generation setup only needs to happen once per language (and can be exposed in a common repo), so this is not a strong counter-argument. Efficiency, expressiveness, and wider support rule in its favor. It is also widely used in gRPC and in many microservice architectures.
 
-The tendermint-specific data structures are encoded with go-wire[[8](./references.md#8)], the native binary encoding used inside of tendermint. Most blockchains define their own formats, and until some universal format for headers and signatures among blockchains emerge, it seems very premature to enforce any encoding here. These are defined as arbitrary byte slices in the protocol, to be parsed in an consensus engine-dependent manner.
+The tendermint-specific data structures are encoded with go-amino[[8](./references.md#8)], the native binary encoding used inside of tendermint. Most blockchains define their own formats, and until some universal format for headers and signatures among blockchains emerge, it seems very premature to enforce any encoding here. These are defined as arbitrary byte slices in the protocol, to be parsed in an consensus engine-dependent manner.
 
 For the following appendixes, the data structure specifications will be in proto3[[9](./references.md#9)] format.
 
@@ -61,7 +61,7 @@ The IBC protocol does not handle these kinds of errors. They must be handled ind
 
 **TODO: clean this all up**
 
-This is a mess now, we need to figure out what formats we use, define go-wire, etc. or just point to the source???? Will do more later, need help here from the tendermint core team.
+This is a mess now, we need to figure out what formats we use, define go-amino, etc. or just point to the source???? Will do more later, need help here from the tendermint core team.
 
 In order to prove a merkle root, we must fully define the headers, signatures, and validator information returned from the Tendermint consensus engine, as well as the rules by which to verify a header. We also define here the messages used for creating and removing connections to other blockchains as well as how to handle forks.
 

docs/spec/ibc/channels-and-packets.md

@@ -28,7 +28,7 @@ Every transaction on the same chain already has a well-defined causality relatio
 
 For example, an application may wish to allow a single tokenized asset to be transferred between and held on multiple blockchains while preserving fungibility and conservation of supply. The application can mint asset vouchers on chain `B` when a particular IBC packet is committed to chain `B`, and require outgoing sends of that packet on chain `A` to escrow an equal amount of the asset on chain `A` until the vouchers are later redeemed back to chain `A` with an IBC packet in the reverse direction. This ordering guarantee along with correct application logic can ensure that total supply is preserved across both chains and that any vouchers minted on chain `B` can later be redeemed back to chain `A`.
 
-This section provides definitions for packets and channels, a high-level specification of the queue interface, and a list of the necessary proofs. To implement wire-compatible IBC, chain `A` and chain `B` must also use a common encoding format. An example binary encoding format can be found in [Appendix C](appendices.md#appendix-c-merkle-proof-formats).
+This section provides definitions for packets and channels, a high-level specification of the queue interface, and a list of the necessary proofs. To implement amino-compatible IBC, chain `A` and chain `B` must also use a common encoding format. An example binary encoding format can be found in [Appendix C](appendices.md#appendix-c-merkle-proof-formats).
 
 ### 3.2 Definitions
 

docs/spec/ibc/conclusion.md

@@ -6,4 +6,4 @@ We have demonstrated a secure, performant, and flexible protocol for cross-block
 
 This document defines solely a message queue protocol - not the application-level semantics which must sit on top of it to enable asset transfer between two chains. We will shortly release a separate paper on Cosmos IBC that defines the application logic used for direct value transfer as well as routing over the Cosmos hub. That paper builds upon the IBC protocol defined here and provides a first example of how to reason about application logic and global invariants in the context of IBC.
 
-There is a reference implementation of the Cosmos IBC protocol as part of the Cosmos SDK, written in Golang and released under the Apache license. To facilitate implementations in other langauages which are wire-compatible with the Cosmos implementation, the following appendices define exact message and binary encoding formats.
+There is a reference implementation of the Cosmos IBC protocol as part of the Cosmos SDK, written in Golang and released under the Apache license. To facilitate implementations in other langauages which are amino-compatible with the Cosmos implementation, the following appendices define exact message and binary encoding formats.

docs/spec/ibc/references.md

@@ -24,7 +24,7 @@
 [https://developers.google.com/protocol-buffers/](https://developers.google.com/protocol-buffers/)
 
 ##### 8:
-[https://github.com/tendermint/go-wire](https://github.com/tendermint/go-wire)
+[https://github.com/tendermint/go-amino](https://github.com/tendermint/go-amino)
 
 ##### 9:
 [https://developers.google.com/protocol-buffers/docs/proto3](https://developers.google.com/protocol-buffers/docs/proto3)

docs/spec/staking/transactions.md

@@ -100,7 +100,7 @@ type TxDelegate struct {
 
 delegate(tx TxDelegate):
     pool = getPool()
-    if validator.Status == Revoked return
+    if validator.Status == Jailed return
 
     delegation = getDelegatorBond(DelegatorAddr, ValidatorAddr)
     if delegation == nil then delegation = NewDelegation(DelegatorAddr, ValidatorAddr)
@@ -141,7 +141,7 @@ startUnbonding(tx TxStartUnbonding):
 	revokeCandidacy = false
 	if bond.Shares.IsZero() {
 
-		if bond.DelegatorAddr == validator.Operator && validator.Revoked == false
+		if bond.DelegatorAddr == validator.Operator && validator.Jailed == false
 			revokeCandidacy = true
 
 		removeDelegation( bond)
@@ -157,7 +157,7 @@ startUnbonding(tx TxStartUnbonding):
     setUnbondingDelegation(unbondingDelegation)
 
 	if revokeCandidacy
-		validator.Revoked = true
+		validator.Jailed = true
 
 	validator = updateValidator(validator)
 
@@ -279,9 +279,9 @@ updateBondedValidators(newValidator Validator) (updatedVal Validator)
         else
 			validator = getValidator(operatorAddr)
 
-		// if not previously a validator (and unrevoked),
+		// if not previously a validator (and unjailed),
 		// kick the cliff validator / bond this new validator
-		if validator.Status() != Bonded && !validator.Revoked {
+		if validator.Status() != Bonded && !validator.Jailed {
 			kickCliffValidator = true
 
 			validator = bondValidator(ctx, store, validator)