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.
Topic: [ANN] Stratum mining protocol - ASIC ready - page 33. (Read 146229 times)
snip
Translation: It's better because I said so.
Rebuttal: Nuh-uh!
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?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. 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Teoretically is possible to have electrum client with build-in miner, which handles both blockchain requests and mining on the same connection.
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.
Thanks for this Slush! Any updates for native stratum miners yet. I saw that you were talking to a few.
Tried it. Like it. Using it.
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...
Sounds interesting. Is it any way, except name, related to the Stratum (electrum) client-server protocol used for bitcoin transaction forwarding?
After a day of playing and running through the Stratum mining proxy I must say I am really HAPPY with it. I can now manage 5 GPUs (1700 MH/s) total over 8 kbit/sec (yes, 1000 chars per second) poor local slow-ping GPRS limited connection link (tunelled via SSH with compression) without any problems and minimal stales! Something I was not able to accomplish previously with http requests (a lot of them).
Kudos to Slush! I think you should really more advertise this method.
Kudos to Slush! I think you should really more advertise this method.
Yes, I think that protocol itself is stable. I'll just add some additional methods for managing connections, like client.reconnect() or so, but it's not directly related to protocol core and you can implement it "as is".
I'm just not sure how you can implement persistent connections with PHP. Maybe running "official" python proxy and implement your software to talk to it locally would be smarter (and easier) choice.
I'm just not sure how you can implement persistent connections with PHP. Maybe running "official" python proxy and implement your software to talk to it locally would be smarter (and easier) choice.
Yes, I had pondered this too after I wrote my previous post. It might indeed not be worth it to implement it in PHP. I have written PHP processes that sit and run outside of a webserver (daemons, if you will). Within PHP too you can do all the regular socket operations so persistent network connections would be okay, there is just the question of whether it's worth duplicating the effort - probably not
Since I run a proxy for talking with different pools and having it manage the failover to those different pools so my miners can just keep plugging away I was thinking about how best to set up multiple stratum connections, i.e. one for each of the pools that will implement it.
As you mention, it might be best to simply run N instances of the python proxy and just plug that info into the PHP web-based proxy that I use right now. Would certainly mean less effort to implement. K.I.S.S. as they say.
Jump to: