[ANN] Stratum mining protocol - ASIC ready

[Joshwaa]

Thanks for this Slush! Any updates for native stratum miners yet. I saw that you were talking to a few.

[marcus_of_augustus]

The protocol has been designed for Electrum client and it is fully compatible. "Stratum mining" is just the Stratum service used for bitcoin mining instead of providing user's balance...

Interesting. So theoretically you could set it up so an Electrum client could be pointed at the Stratum 'mining' proxy and get it's requests forwarded to an Electrum server or more specifically a group of servers with failover etc handled by the proxy in same way it handles mining traffic? ... not saying this is necessarily a good idea just curious if it could be done.

[slush]

Yes, exactly, the protocol is the same. Mining server just provide other services with different methods.

Teoretically is possible to have electrum client with build-in miner, which handles both blockchain requests and mining on the same connection.

[marcus_of_augustus]

Yes, exactly, the protocol is the same. Mining server just provide other services with different methods.

Teoretically is possible to have electrum client with build-in miner, which handles both blockchain requests and mining on the same connection.

Cool, nice work.

[slush]

Yesterday I had a speech about Stratum on London conference. I think that it has been accepted by audience nicely. I was pretty surprised that nobody asked me for the difference between Stratum and getblocktemplate; I had many arguments in my sleeves :-).

Unfortunately I forgot to say many things which originally prepared for the presentation :-), especially the benefits for miners. It has been my first public talk, so hopefully I'll improve my skills for next time.

[slush]

I added local discovery responder into the proxy. This feature allow miners to discover mining proxies running on local network and connect to them instead of connecting to the pool directly. I discussed this with miner developers and some of them are going to support this feature.

There's an example how to implement local discovery in miners: https://github.com/slush0/stratum-mining-proxy/blob/master/example_multicast.py

Thanks to this feature, whole mining operation including tens of machines on local network can communicate to the pool over single TCP socket. It's another huge improvement over current getwork protocol, where every mining rig has N concurrent connections (and sometimes N >> number of cores).

I'm going to document this officially soon.

[slush]

Thanks for this Slush! Any updates for native stratum miners yet. I saw that you were talking to a few.

I've asked m0mchil today and he's a bit late with the release because of some another improvements in poclbm.

I know about guy working on patch for cgminer (yay, this is really exciting!)

And I'll start on guiminer patch once I finish some necessary work on my own Stratum pool, probably during this week.

[Joshwaa]

Thanks for this Slush! Any updates for native stratum miners yet. I saw that you were talking to a few.

I've asked m0mchil today and he's a bit late with the release because of some another improvements in poclbm.

I know about guy working on patch for cgminer (yay, this is really exciting!)

And I'll start on guiminer patch once I finish some necessary work on my own Stratum pool, probably during this week.

Any Ideas about BFGMiner, Pheonix, or  Diablo? Those are the three I currently use.

[Luke-Jr]

Any Ideas about BFGMiner, Pheonix, or  Diablo? Those are the three I currently use.

I don't plan to implement StratumMP for BFGMiner, though I might merge a pullreq if someone else writes it. BFGMiner 2.8.0 already supports the open standard getblocktemplate (GBT) protocol, which does everything StratumMP does, plus more, and was developed openly by the community. Encourage your pools to support that instead.

From what I hear, Phoenix is also dead/unmaintained at this point, and Diablo-D3 insists getwork is fine. Additionally, as StratumMP is significantly more difficult to implement in existing miners compared to GBT, so I would expect it to be a while in any case.

[slush]

I'll probably implement Stratum into Phoenix myself, but I still don't know if they'll accept such patch. In the worst case I'll temporary fork it (they don't improve miner so much anyway).

BFGMiner won't never support Stratum, because it's Luke's fork of cgminer and he's on holy war against Stratum.

There'll be native support in cgminer soon and I hope these guys will be more constructive in accepting that patch.

But you can still use Stratum proxy, it's really easy to setup and you don't need to wait to anything.

Any Ideas about BFGMiner, Pheonix, or  Diablo? Those are the three I currently use.

[slush]

Additionally, as StratumMP is significantly more difficult to implement in existing miners compared to GBT, so I would expect it to be a while in any case.

Any proof of your words?

[eleuthria]

Any Ideas about BFGMiner, Pheonix, or  Diablo? Those are the three I currently use.

I don't plan to implement StratumMP for BFGMiner, though I might merge a pullreq if someone else writes it. BFGMiner 2.8.0 already supports the open standard getblocktemplate (GBT) protocol, which does everything StratumMP does, plus more, and was developed openly by the community. Encourage your pools to support that instead.

From what I hear, Phoenix is also dead/unmaintained at this point, and Diablo-D3 insists getwork is fine. Additionally, as StratumMP is significantly more difficult to implement in existing miners compared to GBT, so I would expect it to be a while in any case.

You know Luke, you might get a lot more support if you could show any example of how GBT is so much easier to implement than Stratum.  Especially something like Slush did:  A page which shows the full communication between a miner and the pool for:  Authorization, Work Pushing, how the work is iterated locally to avoid constantly talking to the pool server, how work is submitted, and how it is responded to.

All you have right now is a BIP page with a dozen tables showing "how much better" GBT is.  Yet we have nothing to see how on earth it compares to StratumMP.  I have no desire to load eloipool and attempt to reverse engineer your poorly commented python code.  The sheer idea that GBT is easier to implement than Stratum shows that you're not a neutral party.  GBT has significantly more information it CAN transmit, and miners would have to be able to interpret all of it, otherwise we're left with a half-supported protocol.

Slush provided a full example of miner->pool->miner communications, a working pool server with heavy comments, and a working proxy with heavy comments.  You've given us a wiki page without examples, and it sure as hell appears to require significantly more work to implement than Stratum based on what's on that page.

[Luke-Jr]

Additionally, as StratumMP is significantly more difficult to implement in existing miners compared to GBT, so I would expect it to be a while in ny case.

Any proof of your words?

A getwork implementation can trivially be converted to GBT merely by changing the data sent/accepted. Don't need to rewrite the whole protocol layer.

You know Luke, you might get a lot more support if you could show any example of how GBT is so much easier to implement than Stratum.  Especially something like Slush did:  A page which shows the full communication between a miner and the pool for:  Authorization, Work Pushing, how the work is iterated locally to avoid constantly talking to the pool server, how work is submitted, and how it is responded to.

I agree the documentation could be improved a bit - hopefully someone will do a quick writeup similar to slush's sometime soon. libblkmaker does include a simple example source file to demonstrate it, though.

All you have right now is a BIP page with a dozen tables showing "how much better" GBT is.  Yet we have nothing to see how on earth it compares to StratumMP.  I have no desire to load eloipool and attempt to reverse engineer your poorly commented python code.

The BIP provides full technical details, not "how much better"; there is no need to reverse-engineer anything to implement it.

The sheer idea that GBT is easier to implement than Stratum shows that you're not a neutral party.  GBT has significantly more information it CAN transmit, and miners would have to be able to interpret all of it, otherwise we're left with a half-supported protocol.

GBT was designed in such a way that it is okay if it is only "half-supported". Miner don't have to be able to interpret all of it, nor does anyone expect them to.

Slush provided a full example of miner->pool->miner communications, a working pool server with heavy comments, and a working proxy with heavy comments.

Too bad Slush didn't put that effort into documenting and implementing GBT, instead of creating useless division.

[eleuthria]

snip

Translation:  It's better because I said so.
Rebuttal:  Nuh-uh!

[Detritus]

luke-jr: Can you give me a reason why it was felt necessary to remove getmemorypool, instead of having it exist alongside GBT?
The existing solution breaks many of the pool packages out there. Backwards compatibility is normally a concern for developers.

[zerokwel]

you know something. I was hoping to get a better response to explain how GBT is better apart from it just is.

I 100% understand how Stratum works and how its a good idea.

I will now be supporting stratum.

[slush]

Guys, please keep this on-topic and don't let this thread turn to flamewar. Maybe we should create another topic "Stratum vs. GBT", but I want to keep here only Stratum-related information and announcements. Thank you.

[Luke-Jr]

luke-jr: Can you give me a reason why it was felt necessary to remove getmemorypool, instead of having it exist alongside GBT?
The existing solution breaks many of the pool packages out there. Backwards compatibility is normally a concern for developers.

This is off-topic here, so I answered on the other thread.

you know something. I was hoping to get a better response to explain how GBT is better apart from it just is.

The question wasn't "how GBT is better", it was "how GBT is easier to implement", which I answered. "How GBT is better" should be answered more or less in the GBT thread.

[Joshwaa]

Thanks luke-jr for you input. I encourage my pool operator to do what works and what I can see is better, at this time that is STRATUM!

Slush I was wondering because I run Bamt. Which is now BFGminer and Pheonix. All good though I will figure a way. Like you said I can keep running the proxy (which seems to be working fine). Either that or give in to peer pressure and run CGMiner.  Once again thank you for all the work Slush and Eleuthria.

[slush]

There's new official release of poclbm with native Stratum support. Can anybody try it on Stratum-powered pools and confirm that it's stable? Unfortunately I don't have any GPU around .