This is only shown, when you refresh in that moment a block is solved and a new one starts. Must be a "maximum" number belonging to a lib or something. If you add a new worker, and don't use it, the maximum number at "Last Activity" is 15367 too ;-)

There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

How about charge 5% auto to anyone who uses , um lets see 100-1000000+ Ip's

I think this would be a good offset to da botmastaz, they prolly don't care much and with all the extra traffic and load I think they should prolly pay a fee.. and I don't think they would mind too much

can split fee 2.5% to urself and 2.5% to miners who use less than 100 IPs

everyone is happy!

rejoice! huzzah!

Good Idea, but if each bot-member has his own ip, the criterion should be the the number of workers per user

I've been thinking about something for some time, and perhaps I should ask others that know better than me.

If the pool set up a VPN for dedicated miners (perhaps filter it somehow so it's not used to stream hulu or whatever), could that improve the stale share count etc? Is it viable in any way with existing hardware or would the increased cpu/memory/bandwidth load require a separate server (and with that, rising running costs etc)?

I actually had a white list IP thing in place back when the pool first started, meant to somewhat mitigate DDoS attacks, but it didn't really work out for some reason. I think instead of charging by the IP, maybe increasing by lack of efficiency would be a better solution. If someone is requesting 10 getworks and only returning 2 of them, that's kind of a problem... whereas if you have 100 miners and request 200 getworks and return 180 of them, that's much more acceptable.

I'm still evaluating different options - I may try Eloipool, since it would be the easiest to work with with regards to DGM as implemented on EMC.

And for those of you following the BIP16/17 debate, against my better judgement I upgraded the bitcoind's to the latest mainline git, and for the past several days, it's been basically destroying all the transaction fees, so they went poof. This is why I was and still am totally NOT in support of BIP 16 because of the timeline involved. It's a perfect example of why a less than 4 week timeline for a change of this magnitude is not viable. Fortunately, Luke alerted me to the problem today and I reverted to an earlier rev.

If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.

And for those of you following the BIP16/17 debate, against my better judgement I upgraded the bitcoind's to the latest mainline git, and for the past several days, it's been basically destroying all the transaction fees, so they went poof. This is why I was and still am totally NOT in support of BIP 16 because of the timeline involved. It's a perfect example of why a less than 4 week timeline for a change of this magnitude is not viable. Fortunately, Luke alerted me to the problem today and I reverted to an earlier rev.

Gavin has pledged to personally reimburse all lost transaction fees and quickly fix the problem (he may or may not have done this already).

Unfortunately I don't think that's going to apply to EMC, since I had disabled the P2SH announce on block creation due to the fact that there was no guarantee of support at any given time from blocks created on EMC. I don't think there's any way for Gavin to deduce which blocks were affected from EMC... but I could be wrong about that. The whole situation gives me a headache.

If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.

Stick with your instincts inaba. I don't know shet about running a pool, but I bet it's similar to running rigs, don't make any major changes until it is obvious there are solid advantages an things are stable. Same with the pool, 100% up time is what it's all about, stable, stable, stable.

Let the rest of these clowns work out the bugs.

Do what you're comfortable with, you're not making enough off this to make it stressful. This is supposed to be a fun and lucrative hobby for you.

I actually had a white list IP thing in place back when the pool first started, meant to somewhat mitigate DDoS attacks, but it didn't really work out for some reason. I think instead of charging by the IP, maybe increasing by lack of efficiency would be a better solution. If someone is requesting 10 getworks and only returning 2 of them, that's kind of a problem... whereas if you have 100 miners and request 200 getworks and return 180 of them, that's much more acceptable.