Next Parity version sets number to null for pending blocks

[dvdplm]

The ethereum RPC spec explicitly states that pending blocks should contain null for some members of the response object, notably the number member.

Until recently Parity did not respond according to the spec and after the change to adhere to spec (scheduled to be released in v1.11, currently in beta) this project breaks, as the code to store new jobs expects the number member to be a uint. See this issue on Parity for details.

What is the reason open-ethereum-pool need the number of a pending block? Superficially it seems like the code here does not necessarily need this value to function, but perhaps there's a good reason for it?

[dvdplm]

@sammy007 ping

[mvilera]

@dvdplm i think @sammy007 stopped supporting/reading this issue tracker long time ago, probably this issue will have to be fixed by the user base

[hillbillie]

Nice smile

[dvdplm]

@mvilera I see, thank you for the heads-up.

[mvilera]

@dvdplm you're welcome, about the topic, have you done any changes at the code base to fix this issue? or do you recommend any approach?

[dvdplm]

have you done any changes at the code base to fix this issue? or do you recommend any approach?

I have not made any changes. I think the first thing I'd try is to see what happens if instead of exiting early in case of a parse error, we'd just let it continue anyway: perhaps knowing the number is not necessary? The spec says it should be null for pending blocks, so there shouldn't be a fundamental reason why it is needed. That's what I'd try!

[sammy007]

I am working on it.

[sammy007]

The develop branch now works with v1.11. And no longer works with Geth.

[dvdplm]

@sammy007 that's good news, and bad news. Do you mind opening an issue on geth for this?

[sammy007]

About what? I can't support two nodes with different rpc calls, geth is barely usable, parity is still usable, this pool no longer support geth.

[dvdplm]

this pool no longer support geth

Alright, your project, your decision. (It might be appreciated by the geth people to at least know about this, that way they can make an informed decision to change or not as they please).

cc @karalabe

[sammy007]

Geth people should just use master branch or revert changes. The change is in develop branch, for your information (because parity breaking changes are still not "stable").

Everyone who is running this pool must understand how it works and must know how to code simple stuff, apply patches, revert changes. This pool is widely used for shitcoin forks and all whining comes from those who are running pools for shitcoin forks so far. I care not about forks and forks are actually a main reason why this pool is no longer actively supported. I personally prefer parity over geth just because it is faster and many admins told me that it's pointless to continue using geth. My time is limited and I can't waste it to support two incompatible rpc interfaces just to make pool admins who are running it mostly for shitcoins happy.

[dvdplm]

The change is in develop branch, for your information (because parity breaking changes are still not "stable").

That makes total sense. 👍🏿
Thank you for your work on this! :)

[ghost]

That is because they butchered the API. The response, "No longer supported"