Well, I knew we were both working on something, and our limited conversation a few months back made me think we were attacking it in two very different ways, with my proposal being significantly better.  Now that you've released yours, I see they're almost identical.

I am withdrawing the protocol I've proposed and amending previous posts shortly.  Since our designs were so similar, I'll be updating my custom pool code to utilize the syntax you've defined.  We don't need a VHS vs Betamax competition for protocols which accomplish the same thing in almost the same way.  All pools and miners benefit from this new protocol, and the faster more pools show support to adopt it the better.

Please just adopt the two commands I posted about previously:  A redirect command for a poolserver to send miners elsewhere, and a server restart notification [with timer] so a pool can attempt a graceful restart rather than suddenly dropping connections.

Aside from that, lets get this stuff natively supported by mining software!

+1


In the proxy source you can see methods client.reconnect(host) and client.add_peers(list). First one may be used for redirecting miners elsewhere, peer list is more for backup locations, when server crashes unexpectedly.


What's the use case for this? If I want to restart the server I can do it without such command as it doesn't require any action from the miner side.

Maybe I can add "wait" option to existing client.reconnect() instead?

This is  a very nice idea

Not sure this is really any different/better than the BIP 22/23 standards which have been in open development for months...
as for the comments on it in the Stratum mining protocol doc:

• the fundamental BIP 22 operation is fairly easy to implement, just making use of the more advanced functionality (which StratumMP doesn't even support yet) is more complex
• GBT does not require or depend on HTTP; it is intentionally designed to be JSON-RPC over any transport
• GBT does not require a complete dump of the server's memory pool
• checking shares shouldn't be any different AFAIK?

Perhaps it would have been a good idea for you and slush to participate in forming the standards instead of privately working on duplicate protocols? :/

BIP 22/23 is only complex if you make use of the extensions that don't exist for StratumMP at all. If you don't, it's in fact just as simple (perhaps simpler).

Block building is the same no matter what protocol conveys the data... if you're not happy with the current level of documentation, it makes more sense to improve it rather than just start from scratch.

gmp-proxy has been functional on open source Eloipool-based pools for months.

To be honest, I don't understand how gmp-proxy works, so I'm unable to find out what the payload itself is. Cryptic variable names and not-a-single comment in the source code don't help the readability much.

However you're still talking about payload, but it is just small fragment of the problem. I'm not sure how many connected users your pool has, but maybe keeping 10k+ connections from weird cpu miners will change your opinion. With the Stratum protocol, load is completely driven by the server, so I can handle these 10k connections with a single CPU core.

You're right.

This is excellent. Very nice work!

Today I publicly asked developers of cgminer and phoenix if they're willing to support Stratum protocol. I already have confirmation from poclbm and Guiminer that they'll support it (m0mchil will implement it proactively for poclbm and Kiv will accept my patch which bundles proxy into the GUIminer).

doubles, just telling anyone's support is valuable feedback at this time. Any vote counts, because there's still a long way to roll native support of this protocol into major miners. During this period we'll have painfull times while running both pools at the same time .