First payouts are out!

Quote from: TeaRex on June 17, 2011, 08:33:39 PM

Question: do you have an idea how long it takes before you start collecting anything?

Multipool has to wait until it collects the rewards from the pools. Since there are many pools with work split approximately evenly between them, it takes that much more time to cross the pools' automatic payout threshold. Although now, with more people, collections should speed up.

Quote from: Sukrim on June 17, 2011, 04:14:37 PM

This would mean you donate 2.5% to BTCguild - why are shares then not immediately confirmed?

I'm making sure that screen scrapping is working adequately. Once I'm satisfied, I will include the confirmation-pending rounds as well. You do get paid for invalid rounds, as long as they've reached the head of the confirmed queue.

Quote from: M4v3R on June 17, 2011, 07:15:07 AM

I'm getting many of these after a while.

The server handles requests fine, but some of the pools are running pretty slow sometimes, and the work queue wasn't getting replenished fast enough, even with multiple request threads. Been tweaking this a bit, and have more ideas for improvements for later.

Quote from: Artefact2 on June 17, 2011, 12:12:23 PM

Also, by contributing to this pool, you are ruining the network's security, as massive pool hopping inevitably leads to everyone hopping to the same pool at the same time, creating one giant überpool that is waay over the 50% "safe limit".

Actually, the equilibrium situation where all miners are perfectly rational (and the pools continue to use shares method) is quite different. It makes sense to jump at 43% point into a round only if everyone else continues to mine at the same rate. If you know everyone would jump at 43% point, you will have to jump earlier to maintain >100% efficiency, but then everyone else would jump earlier as well! In the 100% rational limit, no one would ever join a shares-based pool. Pool mining will become impossible and everyone will go back to solo mining again! In the real world, where only 5% of people are rational, I adjust accordingly.

Quote from: Sukrim on June 17, 2011, 01:54:16 PM

There could be ways around this, such as requesting just a few getworks from different IPs, a small helper program that constantly asks for a few getworks and sends them to the metapool... should be easy to set up and not too hard to find a few "mirrors/nodes" for that. I would happily contribute until all pools finally agree that pool hopping is not a crime but something that is THEIR OWN FAULT!

Also if this pool really gets banned and fought big time instead of solving the issue of pool hopping instead, I hope Multipool just releases the code, so anyone can run it locally in private. Roll Eyes

(Edit: Just like any other pool hopper currently does!)

All great ideas! If ip banning does get out of control, I can release a small proxy script for the miners to use to relay Multipool traffic. And if I do grow tired of being a pool tycoon and the mining pools still haven't implemented fair algorithms, I will release the source code, so that anyone can run their own metapool.

Quote from: Artefact2 on June 17, 2011, 12:38:48 PM

Quote from: organofcorti on June 17, 2011, 12:31:56 PM

even without the pool hopping algo the would provide excellent failover. Maybe it will still be around to provide that when pool hopping is dead.

It looks like it's a nice fail-over, yeah, but in reality it's just another additional point of failure. You're way better running two miners on two different pools locally (with different priorities, of course).

A pretty valid concern. If a person is in search of better uptime, they select the pool with the highest reliability. Multipool would at best only be as good as its own uptime. I would've just released the code outright, but there are already pool mining proxy programs available, and this is just too much fun.