This is turning into slush's word vs your word now then. slush says nothing happened when the DNS was changed (though he's not really in a position to say that definitively, I'm guessing he just checked to see if btcg was still up) and you say the traffic did hit you.

Which is right?

Sorry, this is nonsense. slush said in his post he has a 5 minute timeout on his zone and this is easily verifiable:

$ dig mining.bitcoin.cz

; <<>> DiG 9.7.3 <<>> mining.bitcoin.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59770
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4

;; QUESTION SECTION:
;mining.bitcoin.cz.             IN      A

;; ANSWER SECTION:
mining.bitcoin.cz.      300     IN      A       178.79.183.97


See that 300? 300 seconds, 5 minutes.

No DNS server (unless deliberately misconfigured) will hold onto that value for more than 5 minutes.

It is conceivable that if a client is going through a long chain of DNS servers each with their own cache, that you will see old data for slightly more than 5 minutes, but I would guess this is rare. And it certainly wouldn't be 24 hours.

It is also conceivable that the botnet attacking software could have done one lookup when it started then kept the value until told to do otherwise, but then it would require babying by the operator to keep up with his previous DNS changes when trying to evade them. I doubt this is the case.

Everything slush said about DNS was correct. Yes, I am a sysadmin.

I suppose mostly that's psychological. A user likes to see that the pool knows their approximate hashrate, its the fastest way to confirm that their setup is working properly and their shares are being accounted for. My users tend to use the hashrate estimate as their go-to stat - if its more than 20% out (acceptable variance given the way we work it out), they know something is wrong and can investigate further.

If a user has to go more than 10 minutes without submitting a single share it would be very difficult for us to work out this figure to any acceptable estimate, over a reasonably short timeframe.

The more you raise the difficulty miners solve at, the less granular you can be sure of their hashrate. Low hashrate miners may not even get to submit a share in between longpolls in extreme instances. I dare say you could safely raise it to 2 or 4 without too much trouble though.

Probably the reason most don't do it is pushpool is set to 1 by default and few pool ops are skilled enough to change this without causing all manner of side effects. Personally, my load and network usage are well within acceptable parameters so raising it would just cause loss of share granularity for no real gain.

Where?

I go to your site, and all I see is an email address. There's an 'About' that looks like it should be a link or button but doesn't seem to do anything. That's really about as anonymous as you could be.
I don't get to see any of your personal details before I press what looks like the only link on your site, to start providing mine? No thanks.

Basically all of it. The website is doing virtually nothing compared to the poolserver. In the last 12 hours (time of my log rotation) I've had 43,000 hits to the website.. Most of them are API hits which are pretty small (couple of hundred bytes). I don't bother running detailed stats on it at the moment though.

In the same timeframe I've had 1,400,000 hits to the poolserver.
A getwork request is about 600 bytes, and a submit work is about 40 bytes.

Can only tell you what I've observed - rfcpool is using about 3Mbit outbound, 2Mbit inbound, to do 50GH/s.

You actually going to read any of my posts? The answer is above.

360. The target is 2-3 minutes (no I'm not sure what this means either, but anyone running the sc2 client can plainly see the difficulty change every 360 blocks).

Yeah great gift. 99% of all generations were invalid for the first hours anyway. I think the difficulty was started too low.

Was a bit of a freak incident. The genesis block was generated 24 hours earlier and the first retarget thought that the first 360 blocks, including starting from the genesis block, took longer than it actually did.

Max adjustment upwards is 13%. Retarget occurs every 360 blocks. Difficulty started at 8 but the first retarget was actually down, to 6.03 if I remember rightly (due to the genesis block being generated quite far into the past).

Untrue, the first difficulty adjustment was from 8 to 6.

Pool's back, sorry about the lack of notice on that one.

haploid23, it must just be pool luck - there's no hidden payments or surprises going on We had a couple of short rounds, but also a long one.. Swings and roundabouts, it'll even out over time

In other news, short pool outage I'm afraid, hopefully be back in about 20 minutes.

Migration ran smoothly if a little slowly, had to retry the form submit a couple of times, but my balances have shown up now. Thanks guys.

Miners are switched off at the moment - UK electricity prices don't really favour this BTC/difficulty ratio :/

er very strange, that sounds like either authentication details server details are wrong. You are using pool.rfcpool.com port 8332?

And you've made a worker after making an account, and have specified that workername (in the format username_workername) in your miner? (password doesn't matter, anything is accepted). Just don't try to mine with your username alone, you have to make a worker.

If it's none of that, I'd suggest connectivity issues but if you can see the website it's unlikely to be that either..

Please explain this

Thanks m3ta

Dynamic forum signature now available, link to the image can be found in My Account (see mine for a sample).