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.
