* Merge pull request #7368 from paritytech/td-future-blocks
Wait for future blocks in AuRa
* Fix tracing failed calls.
* Problem: sending any Whisper message fails
The error is "PoW too low to compete with other messages"
This has been previously reported in #7144
Solution: prevent the move semantics
The source of the error is in PoolHandle.relay
implementation for NetPoolHandle.
Because of the move semantics, `res` variable is in fact
copied (as it implements Copy) into the closure and for
that reason, the returned result is always `false.
* Merge pull request #7433 from paritytech/td-strict-config
Strict config parsing
* Problem: AuRa's unsafeties around step duration (#7282)
Firstly, `Step.duration_remaining` casts it to u32, unnecesarily
limiting it to 2^32. While theoretically this is "good enough" (at 3
seconds steps it provides room for a little over 400 years), it is
still a lossy way to calculate the remaining time until the next step.
Secondly, step duration might be zero, triggering division by zero
in `Step.calibrate`
Solution: rework the code around the fact that duration is
typically in single digits and never grows, hence, it can be represented
by a much narrower range (u16) and this highlights the fact that
multiplying u64 by u16 will only result in an overflow in even further
future, at which point we should panic informatively (if anybody's
still around)
Similarly, panic when it is detected that incrementing the step
counter wrapped around on the overflow of usize.
As for the division by zero, prevent it by making zero an invalid
value for step duration. This will make AuRa log the constraint
mismatch and panic (after all, what purpose would zero step duration
serve? it makes no sense within the definition of the protocol,
as finality can only be achieved as per the specification
if messages are received within the step duration, which would violate
the speed of light and other physical laws in this case).
* Merge pull request #7437 from paritytech/a5-chains-expanse
Remove expanse chain
* Expanse Byzantium update w/ correct metropolis difficulty increment divisor (#7463)
* Byzantium Update for Expanse
Here the changes go. Hope I didnt miss anything.
* expip2 changes - update duration limit
* Fix missing EXPIP-2 fields
* Format numbers as hex
* Fix compilation errors
* Group expanse chain spec fields together
* Set metropolisDifficultyIncrementDivisor for Expanse
* Revert #7437
* Add Expanse block 900_000 hash checkpoint
* Advance AuRa step as far as we can and prevent invalid blocks. (#7451)
* Advance AuRa step as far as we can.
* Wait for future blocks.
* fixed panic when io is not available for export block, closes#7486 (#7495)
* Update Parity Mainnet Bootnodes (#7476)
* Update Parity Mainnet Bootnodes
* Replace the Azure HDD bootnodes with the new ones :)
* Use https connection (#7503)
Use https when connecting to etherscan.io API for price-info
* Expose default gas price percentile configuration in CLI (#7497)
* Expose gas price percentile.
* Fix light eth_call.
* fix gas_price in light client
* kvdb-rocksdb: update to RocksDB 5.8.8
* kvdb-rocksdb: tune RocksDB options
* Switch to level-style compaction
* Increase default block size (16K), and use bigger blocks for HDDs (64K)
* Increase default file size base (64MB SSDs, 256MB HDDs)
* Create a single block cache shared across all column families
* Tune compaction settings using RocksDB helper functions, taking into account
memory budget spread across all columns
* Configure backgrounds jobs based on the number of CPUs
* Set some default recommended settings
* ethcore: remove unused config blockchain.db_cache_size
* parity: increase default value for db_cache_size
* kvdb-rocksdb: enable compression on all levels
* kvdb-rocksdb: set global db_write_bufer_size
* kvdb-rocksdb: reduce db_write_bufer_size to force earlier flushing
* kvdb-rocksdb: use master branch for rust-rocksdb dependency
* Reduce max block timestamp drift to 15 seconds (#7240)
* reduce max block timestamp drift to 15 seconds
* add test for block timestamp validation within allowed drift
* Update kovan HF block number.
* Tweaked snapshot sync threshold
* Change keypath derivation logic (#6815)
While the standard defined by Trezor as the default derivation path here
https://blog.trezor.io/trezor-integration-with-myetherwallet-3e217a652e08
says that it should be `m/44'/60'/0`, in practice they don't have an
implementation of a wallet for Ethereum themselves and refer customers
to MEW.
MEW has a custom implementation of the path derivation logic that allows them to
generate multiple addresses by essentially adding `/0`, `/1` etc to the path.
In my initial implementation of Trezor I didn't take this into
consideration unfortunately and just used the keypath that Trezor
themselves recommended. However, given that it's seemingly standard
practice to append `/0` for a "sub-address" (and this is what we've done
for Ledger as well) it seems like a mistake on my part to not take that
into consideration.
Unfortunately, anyone who has used their Trezor device with Parity
previously would now see a different address when they connect the
Trezor device the next time. The only way they would have to access the
old address is to use an old version, or by going through MEW and
selecting the Ledger keypath.
Also see #6811
