Using `hbbft` in other software that is based on frameworks like [tokio](https://tokio.rs), being `Send` is often a requirement on shared data structures.
* Add support for RNG instantiation in proptests.
* Use `proptest` module strategy to create the rng for `net_dynamic_honey_badger`.
* Use seed generation instead of RNG instantiation in tests.
* Remove fixed RNG in `generate_map`.
* `VirtualNet` now supports setting the random generator through the builder.
* Add missing `time_limit` field to `::std::fmt::Debug` trait implementation on `NetBuilder`.
* Pass an instantiated random number generator through `NewNodeInfo` as a convenience.
* Make the random number generator of `DynamicHoneyBadgerBuilder` configurable, at the cost of now requiring mutability to call `build_first_node()`.
* Ensure RNGs are derive from passed in seed in `net_dynamic_hb` tests.
* Correct inappropriate use of `random::Random` instead of `Rng::gen` to generate dependent values in `binary_agreement`.
The original implementation used `rand::random()`, which will always use the `thread_rng`, ignoring the fact that an RNG has actually been passed in.
* Do not use `OsRng` but passed in RNG instead.
* Use reference/non-reference passing of rngs more in line with the `rand` crates conventions.
* Document `rng` field on `DynamicHoneyBadger`.
* Make `SyncKeyGen` work with the extend (`encrypt_with_rng`) API of `threshold_crypto`.
* Use passed-in random number generator in `HoneyBadger`.
* Create `SubRng` crate in new `util` module to replace `create_rng()`.
* Use an RNG seeded from the configure RNG when reinitializing `DynamicHoneyBadger`.
* Use the correct branch of `threshold_crypto` with support for passing RNGs.
* spam protection part 1: remote epoch tracking in HoneyBadger
* moved handling of EpochStarted out of EpochState
* allowed EpochStarted from observers
* removed an unnecessary function call
* updated formatting to beta
* removed an unnecessary variable
* Remove unnecessary recursive method calls.
* Add `handle_message` (without the trait).
* Fix a bug where `handle_message_content` would create an `EpochState`
with the wrong number.
* Move `CoinState` and `Agreement` definitions from `agreement/mod.rs`
to `.../agreement.rs`.
* Move `DynamicHoneyBadger` definition from `dynamic_honey_badger/mod.rs`
to `.../dynamic_honey_badger.rs`.
`QueueingHoneyBadger` now waits after an output, and only makes its
proposal for the next epoch when:
* there are pending transactions in the queue,
* there are pending key generation or vote messages, or
* _f + 1_ other validators have already made their proposal.
This rule should work well for small networks: With 1 - 3 nodes, it will
produce a new batch whenever at least one of them has transactions to
contribute. In larger networks, it prevents an adversary controlling _f_
nodes from producing lots of empty epochs.
An exception is made for a currently joining validator: We will commit
up to _(N + 1)² + 1_ key generation messages for them, which is the
maximum number a correct node will send.
c0gent
Marc Brinkmann
Erich Gubler
Vladimir Komendantskiy
Andreas Fackler
Nick Sanders