Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Whisper problem: PoW too low to compete with other messages (and potential source of error) #7144

Closed
zot opened this issue Nov 26, 2017 · 2 comments
Assignees
Labels
F2-bug 🐞 The client fails to follow expected behavior. M4-core ⛓ Core client code / Rust. P5-sometimesoon 🌲 Issue is worth doing soon.
Milestone

Comments

@zot
Copy link

zot commented Nov 26, 2017

I'm running parity 1.8.3 on Linux, testing with both an installed release and a release built from source on a dev network. My Dapp is using web3.js 1.0.0-beta.18.

When I post a whisper message, I always get the error: "PoW too low to compete with other messages". I'm using using priority 10000 and ttl 100 (I've tested with many variations).

I added some debug logs and got an inconsistent result which I think may be linked to the problem.

Whisper::post() will return Err(whisper_error("PoW too low to compete with other messages")) if relay() returns false. Relay is bound to PoolHandle::relay() in whisper.rs, line 51 but relay seems to be behaving oddly, based on some debug logs I put in. Here is the change I made:

fn relay(&self, message: Message) -> bool {
	let mut res = false;
	let mut message = Some(message);
	debug!(target: "whisper", "RELAYING...");
	self.net.with_proto_context(whisper_net::PROTOCOL_ID, &mut move |ctx| {
		if let Some(message) = message.take() {
			res = self.handle.post_message(message, ctx);
			debug!(target: "whisper", "POSTED MESSAGE, RES: {}", res);
		} else {
			debug!(target: "whisper", "NO MESSAGE POSTED");
        	}
	});
	debug!(target: "whisper", "FINISHED RELAYING, RES: {}", res);
	res
}

This produces the following log messages:

2017-11-26 13:53:01 DEBUG whisper RELAYING...
2017-11-26 13:53:01 DEBUG whisper POSTED MESSAGE, RES: true
2017-11-26 13:53:01 DEBUG whisper FINISHED RELAYING, RES: false

The with_proto_context block() sets res to true but outside of the block, res is still false. This returns false to Whisper::post() and, I believe, results in the (wrongly reported) error.

@5chdn 5chdn added M4-core ⛓ Core client code / Rust. Z1-question 🙋‍♀️ Issue is a question. Closer should answer. labels Nov 27, 2017
@5chdn 5chdn added this to the 1.9 milestone Nov 27, 2017
yrashk added a commit to poanetwork/parity-ethereum that referenced this issue Jan 2, 2018
The error is "PoW too low to compete with other messages"

This has been previously reported in openethereum#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.
@yrashk
Copy link
Contributor

yrashk commented Jan 2, 2018

@zot I think your assessment is spot on. The reason relay compiles is because bool implements Copy and that's what happens within the move semantics. The value just gets copied.

@tomusdrw tomusdrw added F2-bug 🐞 The client fails to follow expected behavior. and removed Z1-question 🙋‍♀️ Issue is a question. Closer should answer. labels Jan 2, 2018
@tomusdrw tomusdrw self-assigned this Jan 2, 2018
@debris debris closed this as completed Jan 2, 2018
@5chdn 5chdn added the P5-sometimesoon 🌲 Issue is worth doing soon. label Jan 2, 2018
@rphmeier
Copy link
Contributor

rphmeier commented Jan 2, 2018

Really it's just an RPC error if the messages actually did get posted to the network. But nice catch and fix regardless!

debris pushed a commit that referenced this issue Jan 3, 2018
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.
debris pushed a commit that referenced this issue Jan 3, 2018
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.
5chdn pushed a commit that referenced this issue Jan 9, 2018
* 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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
F2-bug 🐞 The client fails to follow expected behavior. M4-core ⛓ Core client code / Rust. P5-sometimesoon 🌲 Issue is worth doing soon.
Projects
None yet
Development

No branches or pull requests

6 participants