A small website update today:

• Update livestats every 60 sec, both round data and top 50. If you already have the page up then refresh it to get the new one with more frequent updates.
• Link to our friends at bitcurex.com
• Display hashrate in Thps instead of Ghps at the top of the webpages
• Show only number of minutes in the block list for blocks that took less than an hour

The hashrates are still a rolling average, but they are now calculated every minute instead of every 5 minutes. This should make things a bit snappier. Downside is that the hashrate displays may be even more out of whack for the slowest miners.


Yeah, allowing connections on one of those ports should be doable. That's what you have access to through a firewall?


Yep. If we double the shift size it would take 10 hours. It would also take 10 hours of idling before your pay for blocks would be down to zero. Upside is reduced variance for non-24/7 mining, such as like now when your miners were down.

BitcoinPool is being brutally pool hopped. Deepbit which delays stats is also being pool hopped but the pool is so big that the effect of the pool hopping is not that great. Both of those pools have anti-hopper measures that are mostly ineffective. BitcoinPool's anti-hopper system is more likely to hurt innocent miners than actual pool hoppers who know what they are doing.

Those pools should just switch over to a fair reward system. It's pretty simple, most pools have done it.

See how much the hoppable pools are being abused at the bottom of this page: http://organofcorti.blogspot.no/2012/09/23rd-september-weekly-pool-statistics.html

Those are failed reward systems with failed anti-hopper measures. Noone should copy their methods. It would be a really bad idea for BitArena to go with a broken reward system, so let's just forget the systems that have been proven not to work.

You would get lower variance for the 4 hours a day machine. That means more even payments for the work it does, instead of low pay one day and high pay another day. So that might be a plus. But it will also take some hours longer to get paid after it did the 4 hours of work. I don't know if that makes a difference for you.


Hi and welcome to the pool! Nvidia isn't the best for mining. But yeah, bitcoin is pretty awesome, so it can be fun to mine a bit even if the equipment isn't the most efficient.


The two restarts caused a few rejects, but I think most were because of the "ddos bug".

The second restart a short while ago was to get in a new version that automatically puts all requests from cgminer and bfgminer with lower version number than 2.7 on the slow queue. The "slow queue" is contained to 1 cpu core on the server. This should prevent those using old outdated miners from causing problems for users with more recent miners like you have. I'm hoping we'll see much less rejected work in the next round.

1 pro, 1 contra and 1 neutral. Not a lot of interest for this. Perhaps the last increase to N=2x diff was enough?


The bug is fixed but there are still users with buggy miners and my protection against that isn't very successful. When a miner starts attacking the pool with thousands of requests per second the protection doesn't kick in quickly enough. It's actually not an easy problem to solve without blocking out large proxies and other large mining operations. It's hard to tell them apart from a buggy miner if you only have a second to do it.

I'm now thinking about putting buggy versions of cgminer and bfgminer automatically on the slow response list together with cpu miners. Placing them there all the time, not only when they misbehave. I have asked people to upgrade a long time ago both here and on twitter. I think this solution is more fair than letting the buggy miners cause slow response for other users. cgminer 2.7.6 is out and working great. Just upgrade. You don't still use internet explorer 6 do you?

The first few block changes after I put in the new version were awful. Thousands upon thousands of useless requests for several seconds. Then we had something like 10 block changes that were perfectly smooth. And before I wrote this we again had a couple block changes where the pool was effectively DDoSed by its own miners. It's kind of funny when you think about it.

New mining backend is up with rollntime for everyone (again). We even got a block a moment after I started it. Must be a good sign.

If you are running on port 9000 you can move back to 8332 now. Thanks a lot for the help with testing! I will shut down 9000 soon, just giving people a chance to change their setup. Testing on 9000 will probably be back when I have a version with variable difficulty.

By the way, I also noticed there's a new cgminer 2.7.6 out. If you are on cgminer it should be worth a quick upgrade.

This isn't about whether you as a pool make a profit, it's about your miners getting ripped off.


No, you pay a lot to pool hoppers and very little to 24/7 miners who support your pool.

Take a look at the bottom of this webpage: http://organofcorti.blogspot.no/2012/09/23rd-september-weekly-pool-statistics.html

The two bottom charts show the pool hopping going on at 5 pools with vulnerable reward systems, "proportional" and "scored proportional". See how the hashrate is much higher for the short blocks than the long ones that take a lot of work. This is pool hoppers ripping off the 24/7 miners on these pools.

There's no excuse for these pools to still be running these reward systems and letting their miners get ripped off. Please don't start another pool like that.

Stratum isn't HTTP so it may be more trouble than it's worth to get it running on the same port with HTTP stuff. GBT and getwork is much easier to run through a webserver.

I have some other things I must do first, and soon ASICs will arrive. Do those FPGAs still make sense in an ASIC world?

Yeah, it's on my list, but there's quite a few more important things above it.


Two huge blocks on the same day isn't fun

I got a suggestion from PsychoticBoy to change the N in PPLNS from 2x difficulty to 4x difficulty. That would be to double the size of the shifts. Please speak up if you have an opinion on it.

Currently 10 shifts take about 5 hours. Doubling shift size would mean 10 shifts take 10 hours at the current pool hashrate. This would mean it takes longer before a proof of work is fully paid, but also that the variance for a proof of work goes down. 24/7 miners shouldn't notice much, but those who don't mine 24/7 should experience reduced variance.

In other news the testing on port 9000 helped uncover a bottleneck that has now been fixed. A big thanks to all who are mining there to help with testing. The test is still running. I'll try and finish up what will hopefully be the next production version of the mining backend, let it run on the test port for a bit, then bring it over on the regular port.

I am quite sure you are getting rollable work or you would not have efficiency over 1000%.

I believe Eligius sets expire to 120 seconds on roll-ntime? The BitMinter server uses longer expiration times. Try keeping the tcpdump running until you hit a block change (long poll) and your client grabs new work from the server.

I restarted once to add more logging to find out what's going wrong. There would be some stales then, but 593 seems very high.I think this was about 14:38 UTC. Are you still getting many rejects now?

Hmm, it may be that I fumbled a bit and took a moment to get the new version running. And with rollntime the clients may just keep working. When finally the server comes back they send in lots of work that will be rejected. I'll make sure if I restart again I do it very quickly.


Cool

What you are probably not noticing is that every once in a while a request or two is taking way too long to process, sometimes more than a second. It appears the same bug is still there, it just happens very seldom because the hashrate on the test port is much lower.

I'll look at what it might be, and perhaps add more diagnostics. May have to restart again to get a new version up. Sadly that will cause some rejected work. But no, it shouldn't be 500+ rejects, it should just be a couple.

Try case insensitive grep. There's no way you'd get over 1000% efficiency if it wasn't rolling ntime.


Cool, thanks very much for your support of the pool. Looking forward to your comeback.

The client includes "rollntime" in its X-Mining-Extensions header to signal that it has rollntime support.

The server then includes an X-Roll-NTime header to give rollable work.

Efficiency 1190%, so you do get rollable work or it wouldn't be that high.

Someone who knows miner.php can perhaps help with why it doesn't show any data?

Ah, you didn't get rollable work? It can happen if your hashrate is low or your efficiency is very low.

Thanks to all who are participating in the test. We even had a BTC block on the test port.

It seems mostly stable, but it did log one request taking 678ms. So there seems to be a problem, it's just very rare that it gets triggered. That's a difficult bug to find.

I'll leave the test running, perhaps just shutting it down momentarily to get it updated. Hopefully I can pinpoint the problem.


I'm not sure what this is. Where is it grabbing data from?

Yep, but I have been working on it. I have made some improvements but I wasn't able to reproduce the slow response we sometimes saw, even when spamming my test server with requests. So I'm not sure if the issue is still there.

I have the new version up for testing on port 9000. Anyone running a setup with backup pools please help test this by putting http://mint.bitminter.com:9000 as first pool and keeping the regular 8332 on second place. In case there is a problem with the test version or I shut it down, your miner will move over to the regular one.

If running on port 9000 your hashrate in livestats will drop, but you can see on the workers page of the website that you are still getting accepted proofs of work and will be paid for the work. Just load that page, wait 10 seconds, then refresh. Numbers will have updated.

So if you have a working setup with backup pools please help test this. I'd like to have some confidence that it's stable before setting it up on port 8332.

Thank you, glad you like it.

Version 1.3.0 of the client was just released and there is no new beta yet. If you try to load the beta right now it will just be the normal 1.3.0 version.

Perfect timing on the GPUMAX run by Fefox, but Entropy snatched up the victory. With 3 blocks in this short race he has done some excellent minting.

Congratulations, Entropy! 5 BTC is in your account. Please get in touch to get your Bitcurex card.