This now makes bit array functions which take in a second bit array, thread
safe. Previously there was a warning on bitarray.Update to be lock the
second parameter externally if thread safety wasrequired.
This was not done within the codebase, so it was fine to change here.
Closes#2080
* p2p: Propose PeerTransport ADR
* adr: Set status to in review
* adr: Add high-level decision
* adr: Extend on the idea of guards
* adr: Rework guards into transport specific filters
* adr: Rename to nodeAddr
* adr: Incorporate review
* .github: Split the issue template into two seperate templates
Now we have different bug report and feature request templates.
* Forgot to add the name, and about fields
This now uses one hkdf on the X25519 shared secret to create
a key for the sender and receiver.
The hkdf call is now just called upon the computed shared
secret, since the shared secret is a function of the pubkeys.
The nonces now start at 0, as we are using chacha as a stream
cipher, and the sender and receiver now have different keys.
Generate keys with HKDF instead of hash functions, which provides better security properties.
Add xchacha20poly1305 to secret connection. (Due to rebasing, this code has been removed)
hkdfchachapoly was a construction we came up with. There is no longer any
reason to use it. We should instead just use xchacha for the remaining use
cases we have. (Symmetrically encrypting the keys in the sdk keys package)
* crypto: Add benchmarking code for signature schemes
This does a slight refactor for the key generation code. It now calls a
seperate unexported method to allow generation from a reader. I think this
will actually reduce time in generation, due to no longer initializing an
extra slice. This was needed in order to enable benchmarking.
This uses an internal package for the benchmarking code, so that this can
be standardized without being exported in the public API. The benchmarking
code is derived from agl/ed25519's benchmarking code, and has copied the
license over.
Closes#1984
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.
Dev Ojha
Alexander Simmerl
ValarDragon
Zaki Manian
Zach
Ethan Buchman
Anton Kaliaev
srmo
Jae Kwon