andrealanfranchi / ethereumstratum-2.0.0 Goto Github PK

First off, thanks so much for your work on this. Apologies, I am not sure the best way to discuss these thoughts (individual issues or one big issue, so lets start here so that I don't annoy you with a bunch of small issues):

• What is the point of hex encoding? Doesn't gzip handle the size of the messages? I feel like the concept of hex everything but extranonce is awkward. I also feel like the convolutions around formatting the hex numbers is overkill as well.

• Why is port hex encoded? For simplicity and readability, let's not.

• What should happen when decoding a gzipped message fails on either client or server?

• "Why should a pool advertise the node's version? It's a matter of transparency. Miners should know whether or not the pool has upgraded to latest patches/releases for node's software." -- I think this is not valuable for this specification. The pool can respond with whatever value it wants to because this cannot be enforced. It may also lead to security issues if the pool exposes its client information.

• "Session Handling - Session Subscription" -- Because it is an ID and that is of type integer, shouldn't the example show a "params": integer instead of a string?

• "Session Handling - Response to Subscription" -- Same issue, but with "result" member.

• "A server receiving a subscription request with params being a string holding the session id." -- Same integer issue

• Why would the client send the hashrate to the server? How could that be trusted and what real benefit would it have for the server?

As for security reasons (buffer overflow) I suggest to limit the size per message to a fixed number of bytes in the spec.
Eg: 768 or 1024 - as this should enough - even for error messages.

It would be good if there was a list of known pools using EthereumStratum-2.0.0.

As far as I know, there are three different implementations of stratum out there in the wild for ethereum, but none seems to be using this protocol.

I like the mining.set approach. The difficulty was changed to boundary hash, right?

However I think the epoch seed is useless there. We don't want to perform the epoch seed to epoch number search.

Instead the block number should be included in the mining.notify package.