* Add new account bech32 prefixes with godocs
* Restructure spacing of existing account code
* Update account godocs
* More account godoc updates + new tm pub/addr helpers
* Update validator type to use new account types/bech32 prefixes
* Fix account documentation errors
* Update Bech32 prefix for consensus nodes
* Update Bech32 spec doc
* Fix account type tests
* Add missing account consensus functions, clear up godocs, and fix tests
* Add to TestRandBech32PubkeyConsistency check
* Update initialization of validator public keys
* Update query signing info command
* Implement new ConsAddress type with associated unit tests
* [WIP] Update stake and slashing parameters
* Update all calls to MustBech32ifyValPub
* [WIP] Validator operator API updates
* [WIP] Fix and update unit tests
* Fix gov logs (helping to debug failing tests)
* Fix gov tally
* Fix all broken x/ unit tests
* Update gaia app genesis address logic
* Fix linting errors
* Fix broken LCD tests
* Fix broken CLI tests
* Implement command to get validator address and pubkey from key name
* Add support for getting validator key information via REST endpoint
* Update PENDING log
* Update docs
* Revert GaiaGenTx.PubKey bech32 prefix
* Fix broken docs and cli tests
* Update genesis to use correct Bech32 (cons) prefix for pubkeys
* Update docs and unit tests to reflect new cosmos account bech32 prefix
* minor formatting
* CI: Make CI not update the lock file
We want CI to be running the lock in the repo, not generating a new one.
Linting now ensures that the lock file is up to date.
* Switch to Chris' comment
* Update pending to indicate this new command
The intent of this is to allow for simulating things like slashing for not
voting on a governance proposal. To test this, you would queue all the validator votes
in future blocks, and keep track of which ones you didn't slash. Then you could add queue a
"check governance slashing operation" after the voting period is over.
Note each defer occurs a 30ish ns overhead here, which is significant
for IAVL iteration. We were previously using around 3-4 defers. (2 in
next, one in Valid, one in Key, one in Value) This slows down the entire
application quite significantly, as we require fast iteration.