ia authored Oct 20, 2017 and Arkadiy Paronyan committed Oct 20, 2017

* Add ECIP1017 setting to Morden config

* Convert spaces to tabs

* Update Morden bootnodes to match Geth

Marek Kotewicz authored Oct 20, 2017 and Arkadiy Paronyan committed Oct 20, 2017

* use tempdir instead of devtools in kvdb-rocksdb

* use tempdir instead of devtools in migration

* use tempdir instead of devtools in ethcore-network

* fixed wrong merge

Tweaked snapshot sync threshold

Integrate UI 2

* Refresh cached tokens based on registry info & random balances

* Don't display errored token images

Fredrik Harrysson authored Oct 19, 2017 and Arkadiy Paronyan committed Oct 19, 2017

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

Refactors journaldb as a separate crate

Fix RPC compilation warnings.

* oneshot channels instead of custom promises

* Future instead of handle_dispatch

* Even less copying

* Those explicit waits were a mistake, thanks, @tomusdrw

* No more unsafe polling

* Test for the new `is_done()` method

* Mark Futures as `#[must_use]`

* Solve most compilation warnings

* `try_ready!` is more ideomatic

* Turn spaces into tabs

* Documentation and visibility improvements

* Minor code style improvements

* Make Futures run on an explisit reactor

* Another round of code style issues

* Simplify ConfirmationReceiver type

* Flatten ConfirmationOutcome into a plain Result type

* Get rid of a separate `pending` set, it was a stupid idea

* Clarify `add_request` docs

* No need to reduce the scope of the mutex here

# Conflicts:
#	js/src/views/Signer/components/SignRequest/signRequest.js