Yes, disk issue, I'm solving disk replacement with server support.

Um, processing of rewards should be fine (except NMC reward for #8644, which I need to recalculate manually, but I'm too tired to do it now).

But are you sure your miners are connected to correct machine? api.bitcoin.cz/api2.bitcoin.cz (currently the api2 has better performance)

Edit: Btw yes, payouts are paused for now, I'm waiting for some blocks to mature to consolidate wallets from old servers to new one. Payouts will be enabled in few hours. I'm sorry that I forgot to announce this.

I'm working on it.

Edit: Originally I though it was another DDoS attack, because server was insanely overloaded (load like 320) and almost not responding. But then I realized some info about hardware failure in system logs, which point me to the fact that it was some hardware issue. I'm in touch with server support and we're finding some solution. However pool is now running and if this happen next time, downtime will be minimal, because I already know what to watch. It's kinda funny that I was almost a year resisting to order real server for pool exactly for the reason of possible hardware failure - and it happen first day of running the pool on bare metal. Life is full or lucky and unlucky "rounds" :-). I'm sorry for troubles, but I'm solving it with very high priority.

OK, also api2.bitcoin.cz moved to new location. DNS is already propagated, so I restarted old backends few times, which usually force miners to reconnect and use correct DNS, however I still see connection attempts to old machines. Please restart your miners, old infrastructure will be turned down in few hours...

Btw this is pool support thread, you should really move somewhere else and not spam here :-).

It's absolutely up to your choice. I need load balancing on more URLs for playing with that hashrate. For example now api.bitcoin.cz is on new server and I'm fine-tuning server settings thanks to this, while api2.bitcoin.cz is still in London.

However in few hours both URL will be on the same machine again, so there's not a big difference.

You're right, I added small notice about caching.

Workers hashrates are calculating from shares in current round, however total hashrate of user is calculated from submits in last 10 blocks. So it's more exact, but have latency.

I'm switching off pool for few minutes, going to database migration.

Edit: Everything went as expected, downtime was less than 5 minutes.

But those are daily charts (one candle per day) instead of intraday charts which bridge is using now. However if you need daily data for your own need, SierraChart probably can export data to some text format (I'm not on PC with SC so I cannot look at it).

Edit: "This data can be Daily or Intraday data" oh ok, so Sierra can import intraday data from CSV. You need CSV as output from bridge for your custom processing of this data?

Btw I blocked few IPs on webserver. 40rq/s because of some Windows toolbar crap? Are you serious?

So if you can mine but cannot access site, fix your mining tools and tell me your IP.

Reward from current round #8628 will be calculated wrongly. I'll fix it manually later.

Current status:
* Website moved
* api.bitcoin.cz moved
* api2.bitcoin.cz still in London
* database still in London

If you see some performance problems on api.bitcoin.cz, tell me.

To be continued...

1) You need patched Bitcoin client (sources are somewhere on namecoin git repository)
2) Install Namecoin
3) Setup merged-mine-proxy (part of namecoin git repository)
4) Point your miners against MM proxy
5) profit

Not necessary. Settin up solo merged mining isn't so hard (although it is definitely harder than just setup solo mining or even pool mining).

No, it's up. Refresh your DNS...

Damn, so that magic "bug" is solved. Many users were complaining for pool performance and "magical network issues" (mainly GUIminers, now I understand why!). And it was because they were using bad URL and mining thru webserver. I setup this transparent proxy 6 months ago right because GUIminer's hardcoded old URL, but then I completely forgot to it. And I was unable to link people's mining issues with webserver load, LOL.

This has been asked (and responded) many times. There is also wiki page on bitcoin.it explaining this :-) (however it isn't working for me now so I cannot send a link).


Of course there there *is* a mechanism to prevent this and no (properly coded) pool will accept share originated from another service. Pool is recalculating your submitted share and validating if it's correct.

Hehe, yes, it's going to be a little crazy.

What's your miner? Is it doing better on api.bitcoin.cz? Actually mining over webserver could be a reason for additional latency, because webserver was pretty overloaded (all those mining widgets polling webserver every minute are making me mad). And because webserver was doing only a proxy for your requests, I didn't see this latency in backend log.

Newest GUI miner (2008-08-24): https://bitcointalk.org/?topic=3878.0

Then you have correct GUI miner, so it should use api.bitcoin.cz correctly. Website is still mining.bitcoin.cz, of course.

No, please use newer version instead (you're using almost half a year old miner!):

GUIMiner version 20110614 changelog:
- Slush's pool moved from mining.bitcoin.cz to api.bitcoin.cz

It also fixes many other issues, so I definitely recommend you to upgrade.

Edit: Btw mining port is 8332, as described on pool homepage.

45min is pretty normal, it's still only 4.5x more than expected. I has been waiting for some new blocks while I was debugging long polling for pool and the longest distance between blocks was over 1.5 hour.