Just a question: whitelist for manually added dynhosts on your website are updated once a day. But when? If IP updates twice a day or something like that or just changes after you did your update ... - the miners have still access? Maybe every whitelist entry have a TTL longer than a day? That would fix the problem. I noticed that today, one dynhost could not connect for some hours, dynhost was on your whitelist but ip was different (real and that from your last update).
Hello, dns resolving will be faster than that, maybe once per hour or even faster. Additionally, there will be special IP which you will call everytime you change IP on your side. Using this notification will be almost instant. Whitelist is currently not enabled as site is not under ddos, but it is important to prepare everything to next ddos attempt. |
|
|
|
can't connect again. Now it just says "Failed to connect".
Should work now. |
|
|
|
slush, I've used that image from your website, and if you are not okay with me using it I will remove it from the widget. :-)
I found this image somewhere on this forum, it is public domain, so don't worry  . |
|
|
|
Is the pool down? I just a "backend is not connected" error message with a "call to bitcoind failed ... connection refused" My gf also mines here and she says her's is fine, so I pointed my miners at BTCGuild and I don't get any errors. It's just slush's pool for me.
Hi, there was problem with one backend server. It is fixed now, I'm sorry for troubles. |
|
|
|
Can we get wallet lock option when you have the time? I think many miners would want to see this.
Yes, actually I started to code it today, but then spent some time on that server configuration. |
|
|
|
Still happening. Are you still under attack?
Yes, but it has minimal impact to the pool, I see 2000 requests/second, which is expected. Also all my miners are working well. Real problem is only higher packetloss (actually 14%), so miner can freeze for a moment while waiting for response from lost packet. But it depends on miner implementation, for example phoenix (which I'm using) is robust in this situation. I'm actually configuring new beast machine which will act as pool firewall. It will be ready tomorrow, so people connecting to api.bitcoin.cz should be safe then. |
|
|
|
How do I fix this?
Looks like hardware error. But correct me if I'm wrong... |
|
|
|
Hey Slush,
After you got everything back to normal yesterday, all my miners were working perfectly. Things continued to work fine up to the 1.0Thash/s point. Once the load went over that I started getting the following console messages again (and lots of them).
warning: job finished miner is idle
Problems communicating with bitcoin RPC
We're under another attack right now, which is creating some packet loss. Actually it isn't ddos, network flood is coming from infiumhost.com. I'm already in touch with those guys. |
|
|
|
|
I see that this happen time to time. I think it is simply delay on websocket interface. I have no idea how many connection that websocket interface has, but I believe it can be in thousands.
|
|
|
|
|
I already asked Kiv to modify this in GUI miner and announce 'bugfix' release. Hope it will be available soon, I understand that modifying ini files isn't what common user of GUI miner want...
|
|
|
|
Everything seems working again (without changing anything on my mining machines).
Do you think it's really necessary to switch to a new adress like api.bitcoin.cz. I would prefer not to, as you never should change a running system.
Unfortunately it is necessary because I need to split site/mining traffic to improve firewall rules. As is mentioned above, it is possible to configure guiminer with new address pretty easily, but I'll ask Kiv to change pool's url for next guiminer release... |
|
|
|
|
Btw pool is in good condition now, feel free to connect. I'd like to say 'thank you' for all your support, although answering every email and PM was impossible.
|
|
|
|
API are reporting wrong miner status. flagged as "active" even if it is not for a long period of time.
Maybe it is unusable, but not *wrong*. It works as was described before; worker is 'active' when last share was submitted in less than hour. I wanted to keep that just for compatibility with deepbit format, but I think 'last share' is better to follow. |
|
|
|
While you are right that it is increasing overall getwork request load, we don't really know for sure that it is pointing to the same location. If there were no difference between them then slush would not have needed to add a new host name. The resolved IP is most likely a load balancer which could be routing traffic selectively based on what the requested host name is in the HTTP GET request. This is the same concept that allows you to host multiple websites with the same server & IP address. We need slush to weigh in on this.
Actually mining.bitcoin.cz and api.bitcoin.cz is the same machine. But firstly we need to split traffic website/mining between two domains, then I can move one domain to another machine. I hope it will be possible tomorrow. |
|
|
|
open a command prompt window and navigate to the directory where the executable is stored. Then type sierrachartfeed-0.2.exe -w
this doesn't seem to be working in win7. It definitely works in win7. What problem do you see? |
|
|
|
I used both api.bitcoin.nz and the other one but none worked. I'm not sure if i got my IP correct or not tho. I googled IP address and the website "whatismyIPaddress" showed me mine. Anyway not sure why i can't get my miners to connect to Slush still.
Well, it's .cz, not .nz Btw, again, ips from profile pages are not yet active. |
|
|
|
|
Hi guys, I just updated website to allow registering IP addresses and hostnames, but this list isn't alive yet - I'm just collecting your IPs. So please fill in what IP you're using.
You can fill any domain name, even dynamic one. It's why there is 'resolved IP' column; pool will refresh IP time to time (not sure how often, depends on number of IPs), so IP list should be up to date.
For those without static IP (and even without dynamic dns), I'll introduce new API URL (which will be using API token which is already presented), which will detect IP of remote host and automatically update firewall settings. So short script on your side detecting IP change or even support in miners (GUI miner for windows?) would easily solve the problem.
Stay tuned, I'm going to knock up that firewall part, full whitelisting will be enabled soon!
|
|
|
|
Hi Slush,
I'm getting a lot of warning about miner being idle and I think it only started happening after you restarted balancer. Is there a way to fix this or we'll just have to wait until ddos is over?
Hi, second ddos wave started few moments before I restarted balances, but it wasn't related. Currently pool is under ddos, which leads to packet loss, which explain your idling miner. But it is keeping that attack much better than earlier today and I'm still trying to improve it a little. |
|
|
|
|
I'm having lot of fun with another attack, but looks like IP whitelist really works. There is significant packet loss, but mining is still up. Without whitelist it would be already down completely, like earlier today. There is important ongoing change in pool architecture, so:
Please point your miners against api.bitcoin.cz
If you already changed miners to mining2.bitcoin.cz, you don't need change anything. I'll need to split website and mining backend to separate machines, so mining cannot use same IP as website anymore. Website will be still on mining.bitcoin.cz, miners on api.bitcoin.cz .
I'll send email to all registered users with all necessary changes with all that summary about IP whitelisting and necessary changes in miner configuration. I believe that this changes and updates will make pool more robust in future attacks.
|
|
|
|
|
I need to restart balancer, we will be back up in minute!
|
|
|
|
|
Show Posts
