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.

* Add Changelog for 1.7.11

* Add Changelog for 1.8.5

* Markdownify issue links

Added checking tx-type using transactions permission contract for miners

standalone dir crate, replaces #7383

SecretStore: secretstore_signRawHash method

SecretStore: return error 404 when there's no key shares for given key on all nodes

SecretStore: Kovan integration initial version

* Updating mainnet bootnodes.

* Add additional parity-beta bootnodes.

* Restore old parity bootnodes and update foudation bootnodes

Tomasz Drwięga authored Dec 27, 2017 and Arkadiy Paronyan committed Dec 27, 2017

* Fix default CORS settings.

* Add info regarding special options.

Fix version

* created the dir crate in util
* moved code from ethstore/src/dir/paths.rs to dir crate
* rename dir module in ethstore to accounts_dir to distinguish it
  from the dir crate
* changes after @tomusdrw on #6952

* call augmented, wasm-tests updated

* fix all call tests

* fix comments

* parity-version module split from util

removed unused util deps and features

trigger buildbot again

only kvdb links rocksdb

snappy linker issues

* rm snappy

* fixed old version imports

Get rid of clippy remainings.

Avoid using ok_or with allocated argument

Tomasz Drwięga authored Dec 22, 2017 and Svyatoslav Nikolsky committed Dec 22, 2017

* Configurable accounts refresh time.

* Fix tests.

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).