This adds a new makefile command, which is used in CI linting, `make check_dep`.
This ensures the toml is in sync with the lock, and that were not pinning to a
branch in any repository.
This also adapts `make get_vendor_deps` to check the lock, in addition to
populating the vendor directory. This removes the need for `make ensure_deps`.
This makes `make get_vendor_deps` consistent between tendermint and the sdk.
Refs #1861
We don't use the fee field and its likely just confusing.
We can add backwards compatible priority (instead of fee) later.
Note priority is better than fee because it lets the app do the math on how to rank order transactions, rather than forcing that into tendermint (ie. if we return fee, priority would be fee/gas)
The privkey.Generate method here was a custom-made method for deriving
a private key from another private key. This function is currently
not used anywhere in our codebase, and has not been reviewed enough
that it would be secure to use. This removes that method. We should
adopt the official ed25519 HD derivation once that has been standardized,
in order to fulfill this need.
closes#2000
* #1920 try to fix race condition on proposal height for published txs
- related to create_empty_blocks=false
- published height for accepted tx can be wrong (too low)
- use the actual mempool height + 1 for the proposal
- expose Height() on mempool
* #1920 add initial test for mempool.Height()
- not sure how to test the lock
- can the mutex reference be of type Locker?
-- this way, we can use a "mock" of the mutex to test triggering
* #1920 use the ConsensusState height in favor of mempool
- gets rid of indirections
- doesn't need any "+1" magic
* #1920 cosmetic
- if we use cs.Height, it's enough to evaluate right before propose
* #1920 cleanup TODO and non-needed code
* #1920 add changelog entry
* crypto/secp256k1: Add godocs, remove indirection in privkeys
The following was previously done for creating secp256k1 private keys:
First obtain privkey bytes. Then create a private key in the
underlying library, with scalar exponent equal to privKeyBytes.
(The method called was secp256k1.PrivKeyFromBytes,
fb90c334df/btcec/privkey.go (L21))
Then the private key was serialized using the underlying library, which just
returns back the bytes that comprised the scalar exponent, but padded to be
exactly 32 bytes.
fb90c334df/btcec/privkey.go (L70)
Thus the entire indirection of calling the underlying library can be avoided
by just ensuring that we pass in a 32 byte value. A test case has even be written
to show this more clearly in review.
* crypto/secp256k1: Address PR comments
Squash this commit
* crypto: Remove note about re-registering amino paths when unnecessary.
This commit should be squashed.
This commit updates the godocs for the package, and adds an optimization
to the privkey.Pubkey() method.
The optimization is that in golang, the private key (due to interface
compatibility reasons) has a copy of the public key stored inside of it.
Therefore if this copy has already been computed, there is no need to
recompute it.