I've run some poclbm testing with BTC Guild and fixed a few errors in how the pool was responding (poclbm wasn't liking BTC Guild).

Everything seems to be working fine now, but I could only run limited testing since my only GPU machine is a Windows box with a 6970.  That thing turns into an electric heater very quickly and my feet are right next to the exhaust.

The stratum beta pool had a few restarts to fix compatibility issues with the poclbm miner, which now offers NATIVE stratum support!

If you use poclbm, you should download the most recent version here: https://bitcointalk.org/index.php?topic=1334.0

You can connect to the BTC Guild stratum server by using:   stratum://[worker_name]:123@stratum.btcguild.com:9332

This address (stratum.btcguild.com:9332) will remain as the Stratum pool DNS/port going forward.

An empty (coinbase-only block) StratumMP work payload is 399 bytes.  An empty GBT work payload based on your example is 737 bytes.

StratumMP work payloads increase 67 bytes per power of 2 transactions.  GBT work payloads increase by the size of the transactions being included in a block (roughly 250 bytes for a normal tx with 1 input, 1 payout address, and 1 change address).

For StratumMP, a block containing 257-512 transactions would require an extra 603 bytes, for a total of 1002 bytes.  GBT would require approximately 128,000 bytes.
Using a more common example, lets say each block has 100 transactions on average.  StratumMP would be 868 bytes per work payload.  The GBT equivalent would be approximately 26,000 bytes.

Similarly, work submission payloads are quite different.  GBT would require 501 bytes per share submission in your example.  StratumMP requires only 109.

None of the above factors in the added overhead of wrapping GBT into HTTP Requests.


The biggest hurdle on implementing StratumMP is changing from constant HTTP connections and inefficient longpolling, to a static TCP connection.  Beyond that change, StratumMP is a simpler protocol to work with and implement.  GBT is more full featured, but your arguments imply that most mining software wouldn't bother implementing the full feature set to begin with.

It's a revised protocol for miners to communicate with pools.  It changes the miner->pool relationship from pull based (miner constantly requests work) to push based (pool sends miner work at regular intervals).  Part of the protocol change allows miners to generate work locally, so regardless of speed (1 MH/s -> 1 GH/s -> 1 TH/s -> 1 PH/s -> 1 EH/s > even more), the overhead in miner<->pool communication does not change.  It uses less bandwidth than current protocols while being able to accommodate massive mining farms/new technology advancements over the next century.

It's currently done using a proxy that the miner runs on a machine in their network, and they point miners at the proxy, which communicates with the pool via stratum, and translates it to the old getwork protocol they're used to.  Native miner support is coming this week for poclbm & guiminer, and a cgminer fork with native support might be out in another week.

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

Probably because BTC Guild and Slush are running beta testing on Stratum based pools.  Neither of us have currently setup merged mining in the new pool software, meaning the NMC chain lost ~450-500 GH/s this last week.

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.

When the stratum server is merged with main stats, you will resume accruing namecoins, though actual merged mining will probably not be happening on the new server for a few weeks.  Your charts will also resume working.



This will probably begin when the reward drops to 25 BTC.  It will likely be a once-per-2 week credit where the total transaction fees collected for the last difficulty are split proportionally.

I'm expecting to move the Stratum server from 'beta' status in the next week, and integrate it with the main pool.  You will not need to change any settings on your proxy when this occurs.

These days I'd say the target rejection rate is 0.25% or less for main chain.  Merged mining results may have more stales on the NMC side, but BTC-side rejects should be in that range.

The first payment for Stratum Beta pool has been calculated and recorded.  Adding the information to your current rewards so you can have the balance available for withdrawal.  I changed the method of recording from a negative payout (pretty ugly and screws up your Earnings History), to a special line on Earnings History (similar to how balances from the old proportional pool carried over).

It should be appearing on your accounts within the next few minutes.

I've fixed a bug on the stats for the Stratum Beta pool.  The speed averaging for workers was running incorrectly.  Rather than using a 10 minute window, it was using a window that extended to the start of testing.  If it found a gap of more than 10 minutes in your stats, it would reset the counter.

The bug has been fixed, and it will now properly use a 10-minute average regardless of how long you've been using it.  This should fix the strange speeds some users were seeing.

The first stratum beta "payout" will be in about 3 hours (~12:30 PM PDT).  It will be added to your main account balance, which will then be available for manual withdrawal, or caught up in the next automatic payout.

That's roughly when the last restarts happened.  Let me know if you have any more of the 'not providing work fast enough' errors, I won't be doing any restarts for at least another 12 hours.

Is the proxy running on the same machine you're mining with?  What type of CPU do you have?  You should not see 'work is not provided fast enough' with the proxy unless the server is being restarted.

This problem is being solved by the Stratum protocol (and possibly by getblocktemplate).

Standard getwork protocol will not scale with ASIC chips.  Higher difficulty will only reduce the upstream traffic, not the downstream.

With Stratum, pools provide miner with a packet of work that is equivalent to 4.2 billion getworks (or more), while taking less bandwidth to transfer than a single getwork.

That sounds like something else is wrong.  Speed estimates on fast miners should be very accurate.  Sent you a PM asking for username so I can take a closer look.

During testing, you will make MORE on Stratum, as long as you have a backup pool setup on your miners (you could have your backup be the normal BTC Guild pool).

Stratum is for all miners.  It is more efficient in every way than the current mining protocols.

I'm paying more during beta (0% fee) just because there is the chance at big downtime during testing, so you should always have a backup pool specified.  So far there has been no downtime, and about 6 restarts in the past 3 days (restarts normally last less than a second).

No problem .  Never a bad thing to have cross pollination in the pool threads as long as it's constructive.  Just to add:  The benefit of higher difficulty is not JUST for the pool, it also reduces the upstream bandwidth used by your miners, since they will be submitting fewer shares.  Diff=2, a very small jump, cuts your upstream bandwidth in half when using Stratum-based pools.

Yes, the proxy will think it's one high speed rig.  That doesn't actually matter though.  Whether you're running 50 100 MH/s miners or 1 5 GH/s miner, a higher difficulty will result in the same number of shares returned [minus a very small (< 0.1%) overhead in the mining software].

If you are the only user on your proxy, the only downside to a higher difficulty applied to all your rigs is the speed estimate percentages (individual workers) will have higher variance.  Your net speed estimate (all rigs combined) will not have much variance.