Hi,

The x8s pool (http://btc.x8s.de) now exists for a couple of weeks and we've reached a nice hashrate during this time. Although we're still a small pool, I think we don't have to hide

Short Info:

• multiple servers for better stability
• Worker monitoring (email alerts)
• Hashrate graphs
• Proportional Share with 1% Fee
• Longpoll
• Twitter updates for "Block found" and "Payment ready"
• SSL
• API (json)
• Achievement System is in early alpha stage
• Userbar
• IRC Channel
• 8 decimals for payout

          

ati and nvidia are not of equal standards... Nvidia is good at floating point while ati is good at integer calculation. Since Sha256 is using integer calculation, nvidia cards suck at mining. So, there might be the one or other hint at getting more out of your card, but you'll never get on par with an ati card :|

Probably not. with or without that opencl sdk, a CPU will perform not as good as a GPU.

Even if you could put 4 on them in one rig... nvidia cards suck for mining
( https://en.bitcoin.it/wiki/Mining_hardware_comparison - there's only the tesla 2050 ... but it seems like the only difference between the 2050 and the 2070 is the amount of memory..)

Still: if your GPU makes 1000 hashes/sec it doesn't matter if there are 4 miners with 250 each (probably less cause of overhead) or 1 Miner with 1000. Each Hash has a Chance of winning, Not related to Number of miners

The bitcoin Mining Proxy (and More or less my loadbalancer) can handle that. Still, if a Client would support that, it would be even better...

More or less (for score based: sure.. for the others... maybe, maybe not )... I'm still in the testing phase, having a look at this pool and that pool... plus I'm testing out a own pushpoold
I'll agree that it probably isn't the best way earning wise. But I'm happy to have a central place where i can steer the miners to a specific pool and not having to log in to every miner and kill/restart them (most of the miners are cpu workers anyway...)


Maintaining state with a stateless protocol is somehow... urgs Still not sure how that can be solved (without restrictions like 'every miner has to have a unique username')
Prefetching sound's like an interesting idea, not sure if (or how much) it makes much sense with the more or less short living data packets? (But since I was thinking about playing around with a queuing backend like it's (probably) used for bitp.it I'll definatly have a look in it)

I've built something like a loadbalancer, you have a list of Pools with Adresses, Ports, Usernames & Passwords, and every X Minutes the next one on that list is picked.
The Miners are pointed to the loadbalancer, the loadbalancer then connects to the pools. It's a little bit based on the "bitcoin-mining-proxy" I found on github. (Since it's a PHP script, you need a webserver for that...)

It's far from beeing perfect though... It supports longpolling, but it can't track to what server a response should be send... So if you got a working unit from server A it might happen that in the meantime the loadbalancer switched to server B... so the result is sent to B, and B discards it as invalid...

Nevertheless I'm quite happy with it running 6 miners on 5 different pools =)

there's also estimated difficulty...
"Estimated   433236 in 62 blks"

Heya,

I'm also thinking about building a pool with pushpool. Here are some questions from my side (maybe not all so much pushpool related):

About the shares table:
* our_result - If pushpool accepts the hash from the miner, this is Y... else N
* reason - If pushpool doesn't accept the hash, this is the reason (so.. mostly 'stale' I guess)
* upstream_result - If pushpool accepted the hash, it gets forwarded to bitcoind, if it's not accepted it's N, if it's a success it's Y (and a new block is born?)...

I've got a couple of "our_result=Y; upstream_result=N" what does that mean? (Is it related to rpc.target.rewrite?)

About pool speed:
How can I calculate the speed from that? Sometimes I'm sending a hash every 2 seconds, sometimes it takes minutes?


Thanks