Quote from: Sukrim on June 25, 2011, 08:44:04 PM

How hard is it to add new pools to this setup? There are multitudes of tiny proportional pools shooting up like mushrooms, waiting to be picked!

If you could abstract the info for pools in a config file, we might even be able to fill these out for you, so you just have to enter that information...

Only problem might be, that these pools then might feel like being DDOSed, if we have a certain hashpower already within multipool (which I think we do).

The pool code is largely modular - I do have a pools.conf file Wink

- and in addition there is some pool-specific code sprinkled around mostly for specific load balancing. It is indeed easy to write a regex. It is more difficult to write a routine that can handle minor formatting changes in the webpages, unexpected data (each pool handles invalid blocks slightly differently, and they are rare enough to make it difficult to see an example), nonsensical data (the json api of some pools occasionally returns values that I can pretty surely say are incorrect), and potentially malicious data. Moreover, the routine must fail graciously if it does fail to parse. Case in point:

Quote from: superweb on June 25, 2011, 08:56:18 AM

Btw the multipool's website is down for me, while the mining looks working fine.

The cause of this particular problem was that apparently bitcoind can on random occasions timeout on rpc requests, even though it's running locally (what is it so busy doing - resorting its database, or maybe thinking up of ways to use up even more memory?). A getdifficulty request during the generation of a webpage doesn't return a number, and the division of the user's round shares by the difficulty to get the efficiency value results in a division by zero and crashes the website thread. So now not only do I have to mistrust and recheck the data the pools send out, I cannot even trust and have to sanity-check my own bitcoind.

I am currently testing more pools and will put them up once I'm satisfied enough. If I were doing it alone, I wouldn't need so many checks - as long as the miners are running, nothing bad can happen. But with actual users, someone is certain to complain the moment a round is marked with "zero" earnings, or if the database were to become corrupted and had to be rolled back, or things like that, so I must give due diligence.

I would like some advice on what to do with all the small proportional pools, which do spawn like mushrooms. The problem is that they and Multipool are of comparable size. Therefore, while small pools can be extremely profitable, there are also high risks of (in this order):

overloading and crashing the pool
being banned for DoSing/hopping
the pool collapsing and shutting down, without rewarding the shares
the pool being a scam

My opinion is not to mine pools below 100GHash/s size, which does limit the options somewhat.

Quote from: shamen on June 25, 2011, 02:16:23 PM

Quote from: Multipool

On the other hand, I occasionally see shares that are clearly within a block, have valid merkles and nonces, have a valid hash, and are not duplicates, but that nevertheless get rejected by the target pool, even as many other shares of similar age get accepted around the same time. Why does this happen? Couldn't really tell without knowing the internal workings of the other pools.

Related?
http://forum.bitcoin.org/index.php?topic=18567.msg277371#msg277371
http://forum.bitcoin.org/index.php?topic=14483.0

Yes, if there were indeed a bug with X-Roll-NTime which caused duplicate work submissions, the results would be exactly the same as what I'm seeing. I don't have the stats off-hand, but I remember this happening with at least several pools, not just one. If that's the case, then it's up to the pool operators to fix it - Multipool cannot duplicate-check shares that it has never received in the first place.