Pages:
Author

Topic: Multipool - the pool mining pool (with source code) - page 19. (Read 48269 times)

legendary
Activity: 2618
Merit: 1007
Don't even bother. If this pool gets big any time, it won't be long until the exploited pools IP-ban the meta pool.

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!)
full member
Activity: 123
Merit: 100
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).
donator
Activity: 2058
Merit: 1007
Poor impulse control.
even without the pool hopping algo it would provide excellent failover. Maybe it will still be around to provide that when pool hopping is dead.
member
Activity: 107
Merit: 10
... unless Multipool itself gets DDoSed.

I am afraid to think about what would happen if I point Multipool at Multipool's listen socket...  Shocked

POOL WITHIN A POOL!! POOLCEPTION!!

sorry couldnt help it
full member
Activity: 123
Merit: 100
Don't even bother. If this pool gets big any time, it won't be long until the exploited pools IP-ban the meta pool.

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".
full member
Activity: 126
Merit: 100
Sounds interesting, I'll give it a try.

I'm getting many of these after a while.

Try to set the flag -q 3, -q 4 , or -q 5 to avoid running out of work. Worked for me on Eligius.
legendary
Activity: 1442
Merit: 1005
Glad someone did this, if anyone else starts a new pool, follow this guy's design so you get stable returns up to 300Ghash/s. Looking forward to meta-multi-pool pools.
hero member
Activity: 607
Merit: 500
I'm getting many of these after a while.
full member
Activity: 154
Merit: 100
quite impressive! 
full member
Activity: 211
Merit: 100
I am afraid to think about what would happen if I point Multipool at Multipool's listen socket...  Shocked
I'd call it SelfDoS.  Grin
hero member
Activity: 607
Merit: 500
You have my 1GH/s. It's not much, but we'll see how it goes Wink.
newbie
Activity: 24
Merit: 0
... unless Multipool itself gets DDoSed.

I am afraid to think about what would happen if I point Multipool at Multipool's listen socket...  Shocked
full member
Activity: 211
Merit: 100
If any mining pools go offline or experience delays due to overloading/DoS, Multipool will switch automatically to alternative pools.

... unless Multipool itself gets DDoSed.
newbie
Activity: 24
Merit: 0
"Listener for "gpu1 (multi)": 16/06/2011 19:30:00, Problems communicating with bitcoin RPC"
Edit 2: Back up now, seems like I just caught you in the middle of a reboot or something Smiley

That's the failover system in action! Pools have been going on and off line all the time for the past week. Right now, for example, both slush and deepbit are down. For now, I have decreased the leniency for pool errors to decrease downtime durations (it is still more profitable though to mine in a pool with high connection errors and high expected utility, rather than one with no errors and low utility), but will continue to tweak the criteria and will implement round-robin fail-overs for zero downtime.
hero member
Activity: 742
Merit: 500
Sending ~190 MH/s your way for a while to test. If I like what I see, I'll send the other 2.8 GH/s your way too  Grin

Edit: wow, that didn't take long...
"Listener for "gpu1 (multi)": 16/06/2011 19:30:00, Problems communicating with bitcoin RPC"


Edit 2: Back up now, seems like I just caught you in the middle of a reboot or something Smiley
newbie
Activity: 24
Merit: 0
Yes! See a sample page here: http://multipool.hpc.tw/user/15iiHfHA3kaEjeBSNKphQoQWuiUHR7Decs I've started a fresh database today, so it will take about 12 hours for current rounds to go from pending to earned to collected status. Also could you tell me if the page cuts off half way through - I'm trying to whip the webserver into shape - I have a suspicion  the FIN packets arrive before the PSH packets when connecting over large distances - but I'm not sure whether this is actually a problem.

Edit:
Fixed truncated stats pages problem.
sr. member
Activity: 322
Merit: 251
Awesome, do you have any sample hashes of users/completed blocks we can see via the lookup @ multipool.hpc.tw:80? I'm anxious to try out this pool tonight!
newbie
Activity: 24
Merit: 0
I am pleased to announce Multipool - the pool mining pool.

EDIT: Multipool is down for the meantime due to VPS problems. Use source code at github to run your own multipool locally!

---

Connect your miners to multipool.hpc.tw:8337. Use your bitcoin address as username and anything as password. The pool will request work from other mining pools and transparently forward it to you. If any mining pools go offline or experience delays due to overloading/DoS, Multipool will switch automatically to alternative pools. Multipool keeps track of how many shares each user contributes to each pool in each round. When the pools send bitcoin rewards to Multipool, each user's balance is increased in proportion to their contribution in the rounds that are paid for.

Multipool will pay out user balances once a day as long as the balance is above 0.25BTC, or one week after the last share submitted as long as the balance is above 0.10BTC. Users can keep track of their shares, earnings, and payouts by going to multipool.hpc.tw/user/***bitcoin-address***. These stats pages displays the shares received by Multipool, the earnings confirmed by the pools, the bitcoin rewards actually collected by Multipool, and the bitcoin rewards paid out to users. The shares counts are those for confirmed rounds only - pending rounds are not summed. Multipool can only pay rewards it has actually collected; therefore it takes more time to receive the rewards - they have to be confirmed by the pools (some have 120 block confirmation intervals), paid out by the pools, confirmed by Multipool (10 block confirmation), and paid out by Multipool.

Multipool implements pool-hopping-strategy to achieve greatest mining efficiency for Multipool users. The stats page displays the expected utility for each pool for each round based on the Multipool prediction algorithms, and the actual efficiency (in comparison to solo mining) after the necessary stats data becomes available. The stats page also displays the overall user efficiency, based on all the pools combined.

Multipool charges 5% fee on any earnings above 100% efficiency. Multipool also pays pool fees, including optional ones. So for example, if Multipool earns 1.60 BTC in a round in a pool with 2.5% fee by forwarding shares with an expected solo utility of 1.00 BTC (a round with 160% efficiency), Multipool will pay a 0.04 BTC fee to the pool, collect 1.56 BTC reward, keep 0.028 BTC fee for itself, and distribute 1.532 BTC to the users.

I expect pool-hopping may be controversial, but it has become necessary to make this issue public to better secure the bitcoin mining community. There are known ways to implement a provably secure and fair pool payment algorithm. On the other hand, there are many other ways that are not secure, despite claims to the contrary. The pool operators and users that deny any perceived insecurities within their chosen system (and critique the alternatives as being "unfair"), and their lackluster attempts to patch up the holes are an unending source of hilarity. Yet reality is not that what we believe in, even if we believe that believing in something makes it real. Pool hopping is very possible and very much effective, as any user of Multipool will find out. While hopping is not very rampant in the wild, it is happening (as the public pool stats will show to the right person), and denying it or implementing patchwork defenses without trying to understand the root of the problem will not make it go away. And this isn't even a problem that cannot be solved - the solutions are right there, available for anyone to use. Even though I am hurting my own pool-hopping operation by publicly advocating algorithms that will make it impossible, it is my hope that using Multipool to draw attention to the issue will finally put enough pressure on pool operators to resolve the problem on their end, rather than sweep it out of sight. Doing so will be more fair for all the other bitcoin miners who currently neither have the choice of a secure and fair pool (with one exception), nor have the knowledge necessary to implement pool hopping on their own.

I've had lots of fun putting this pool together. The task of mining many pools is proportionally more difficult than implementing just a single mining pool. There is a lot of screen scrapping going on and I cannot guarantee error-free operation, though I've taken precautions to the best of my ability to ensure accurate operations. Likewise, I cannot guarantee all payments if pool operators decide to start banning accounts. However, only the uncollected amounts in the pool accounts are at risk at any point, and if the pool operators do decide to go on banning sprees rather than solving the problem outright, I will have lots more fun implementing avoidance measures.
Pages:
Jump to: