It's testing time again!

GBT and getwork testing on port 9000. Stratum testing on port 3334.

Stratum in production will go on port 3333 with 5050 as an option if 3333 is a problem for you.

There's an X-Stratum HTTP header in all responses on port 9000. Looks like cgminer has a --fix-protocol option that makes it not switch to Stratum. But it seems to use getwork in that case. Any way to force GBT? Until the pool supports the more advanced GBT features, I think it makes sense to tell the miner where the Stratum port is.

What's new on testports:

• Stratum: brand new
• GBT: add workaround for bug in cgminer prior to 2.9.4
• var diff: max diff 16

Already 5 Stratum connections active. If you are mining with a Stratum or GBT capable bfgminer/cgminer/poclbm then please join in and help test this.

For Stratum connect to: stratum+tcp://mint.bitminter.com:3334
For GBT or getwork: http://mint.bitminter.com:9000
(you may need to force your miner to use GBT or getwork, whichever you want to try)

Thanks

So current miners try GBT first, and if it has a Stratum HTTP header they switch to Stratum. If GBT fails completely they switch to getwork, which could also have a Stratum header, but that is never looked at if GBT is supported.

If you implement both GBT and Stratum, the server will decide the default by including a Stratum HTTP header in GBT responses or not.

Is the X-Stratum HTTP header documented somewhere?

What should be the contents?

How should it be interpreted by miners? As "stratum is there, if you want it" or "stratum is there, switch to that"

Generally I would like to support all 3 options and let the user choose.

I was wondering if by putting a Stratum header on getwork responses but not on GBT responses I have made a choice for the user.

Sure, I'll add one of those ports. What's special about them anyway?


Hmm. So cgminer tries GBT first, and if it sees no Stratum header it stays on GBT?

Block 210000 and up gave 25 BTC + transaction fees. If any pools paid out 50 BTC for those blocks that would be an error. Or a lot of transaction fees.

Your miner doesn't actually report the hashrate to the pool server. Pool servers try to guess your hashrate based on how many proofs of work ("shares") you send in. When you are lucky and find many, the pool will show a higher than actual hashrate, and the opposite when you are unlucky. So the hashrates shown on pool web servers are just guesstimates.

I guess your actual hashrate is 1900 Mh/s and the inaccurate website hashrate just showed 2100 for a short time while you were being lucky and finding many proofs of work? Or what hashrate does the miner software on your computer show?

Yeah, it's only for testing. GBT will soon be on the regular port. Port 9000 may be unstable, and hashrate on that port won't show on the website. But you do get paid, and the hashrate will show in shifts, it just won't show as current hashrate.

It's a bit of a hack. In the future I will add proper support for multiple servers and they will show properly in the stats.


Good to know, I'll just add the header on getwork responses then.

Yeah, it will be GBT and getwork on the regular port and Stratum on a different one. But the GBT/getwork responses will have an HTTP header informing the miner where to find the Stratum port.

The "not providing work fast enough" message comes pretty quickly after long poll - may not be a big deal.

Yes, we have GBT testing on port 9000 now and Stratum testing will begin soon.

If I put GBT on main port now then users with cgminer with GBT support but earlier version than 2.9.4 will get 100% rejects. I need to add a workaround for this bug before enabling GBT on the main port, otherwise it could be pretty painful for some users.

I hope to move GBT and Stratum to main port within a week's time, if not before. Maybe before the weekend is over, if testing goes well.

Yep, new version coming in a bit.

It uses x-mining-hashrate only for the initial difficulty. After it has measured the worker's hashrate it uses that as a basis for difficulty. Using only x-mining-hashrate basically means letting the user select the difficulty - I'm not sure that's a good idea.

I have a pool-wide setting for max difficulty though. I can set this to what is appropriate for 1 minirig now, and later adjust up to what is appropriate for 1 SC minirig. So 10 minirigs running on the same worker account will get the same difficulty as 1 minirig.

Is that then still an issue?


I didn't implement the target request option yet. I don't know if I would use it for anything but the first minute either. Letting a user with 10+ TH/s set the difficulty makes me a bit uneasy.

I have some little things still to do on Stratum support. I hope to enable Stratum on the testport within a couple days.

If everything runs perfectly I could perhaps enable Stratum and GBT with var diff on the main pool before the weekend is over. But perhaps delay var diff on getwork a bit longer until hashpower.com supports it.

Also I think ztexminer doesn't support var diff. And perhaps never will?

"Expected per block" on website corrected to take the reward halving into account.

I also added MPoolMonitor under "tools" -> "third party apps" on the website.

Yep. If you click on the height numbers at bitminter.com/blocks you will see how much income there is from each block, and how much is paid out to miners (same number twice).

And you are right, this is now more important. Have a look at my answer to this question: http://bitcoin.stackexchange.com/questions/5515/how-much-is-a-mining-pool-share-worth-on-average
I ran some numbers there, and transaction fees and namecoins are now starting to matter. Put together they give about 3.4% extra income. So if you mine at a pool with 3% fees which doesn't pay transaction fees and namecoins, that's more like a 6.4% fee, which seems a bit steep.


No, BitMinter looks at the exact income from a block and shares that out to the miners, so it will never be wrong.

But...


Yeah, sorry, I forgot this expected income per block shown on the account details page on the website, that number is based on each block giving 50 BTC. Will fix in a moment.

As I write this there are only 7 blocks left with 50 new coins in them. After that it's down to 25. Let's get block 209999! Fire up some extra miners.


Thank you, sir, much appreciated!


With Stratum there has been some changes to how difficulty works. Earlier it could create a few rejects, but in the future hopefully it won't anymore.

GBT, however, should not. So you should not be seeing any rejects at all apart from at the block change (long poll) times.

Did you happen to catch the message about why the work was rejected?

I am also running 2.9.5 testing GBT.  Not many rejects: A:54005  R:46. And I haven't seen any rejects that didn't happen at a block change.

Seems like we need a bit more testing. Anyone else seeing something like that?

While I think reducing block size would help a bit and I had a couple other ideas for reducing orphans, I believe Sturle's idea in combination with propagating blocks outside the bitcoin peer-to-peer network could make orphans nearly extinct. So I think that is the best way forward, for all pools.

I'll see what I can do. Stratum testing will hopefully begin soon. After that I have a few pressing matters of which the orphan problem is one. Priorities, priorities ..

Thanks for the support, guys, and thanks for running the numbers, philipma1957.

Yeah, as long as someone is buying litecoins. I may add support for it later, but ASIC is most important right now.

It's not throttling. BitMinter client always pushes the GPU as hard as it can. I always planned to add a feature for running it at X percent of capacity, but had no time, so it always runs full speed.

You can try overclocking to get a higher hashrate, it may not be worth the extra electricity though.