bitHopper: Python Pool Hopper Proxy

[organofcorti]

Anyone else notice the total shares last night on Mt Red changing to 10000000 for a hour or so? Looks like they're getting ready to fake stats without trapping hoppers.

[1714256221]

1714256221

[c00w]

1) 10^10 shares means there api was down....
Not faking shares. I should probably have a flag for that but well.

[muyoso]

I am wondering if its possible to code so that if you are mining at a pool that is say 500Ghash/s total speed and they are at 300k shares or something that you don't immediately jump to a pool that has a speed of 50Ghash/s that just found a block.  Wouldn't it be more profitable to finish the 43% with the fast pool and then jump?  Or is the risk of not catching that super fast block on the small pool too great?

[bb]

I am wondering if its possible to code so that if you are mining at a pool that is say 500Ghash/s total speed and they are at 300k shares or something that you don't immediately jump to a pool that has a speed of 50Ghash/s that just found a block.  Wouldn't it be more profitable to finish the 43% with the fast pool and then jump?  Or is the risk of not catching that super fast block on the small pool too great?

I'm sorry, but also reading your comments on the bitp.it thread, I am not sure you understand the mathematics behind hopping. Forget your concept of "luck". This is just basic probability theory.

[muyoso]

Oh jeez, what happened to Ozco.in?  They are down to 7.2Ghash/s right now.

Edit: looks like they are slowly coming back up.

[bb]

2) switching from eligius to x8s?
Well both your backup pools lagged out. So it switched to the pool with the lowest number of shares which wasn't lagged out. Once the backup pools came back up then it switched back. That is how it is supposed to work.

3) issues serving index.html and running from the wrong directory?
Yeah. Thats an issue. I'll fix it.

ad 2: Ok, I didn't get that. Thanks for clearing that up.

ad 3: I saw it's already in. Thanks! :-)

[muyoso]

I am wondering if its possible to code so that if you are mining at a pool that is say 500Ghash/s total speed and they are at 300k shares or something that you don't immediately jump to a pool that has a speed of 50Ghash/s that just found a block.  Wouldn't it be more profitable to finish the 43% with the fast pool and then jump?  Or is the risk of not catching that super fast block on the small pool too great?

I'm sorry, but also reading your comments on the bitp.it thread, I am not sure you understand the mathematics behind hopping. Forget your concept of "luck". This is just basic probability theory.

Maybe I am entirely misunderstanding the math.  I haven't the knowledge to do a detailed analysis of how getting a massive (in the case of bitp.it 3x) boost in hash rate effects the number and rate of finding blocks.  Perhaps there is no correlation.  If I had to guess, I would think that people who mine in a single pool that is being hopped ARE negatively effected, but not to the extent that most believe due to more blocks being found with a massive increase in hash rate.  

Maybe I am totally off base. . .

Care to comment on the comment you were responding to initially though about different pool speeds and jumping? 

[organofcorti]

BTC-Poolwatch is now perfect for hopping:

http://forum.bitcoin.org/index.php?topic=10543.msg387825#msg387825

[organofcorti]

I am wondering if its possible to code so that if you are mining at a pool that is say 500Ghash/s total speed and they are at 300k shares or something that you don't immediately jump to a pool that has a speed of 50Ghash/s that just found a block.  Wouldn't it be more profitable to finish the 43% with the fast pool and then jump?  Or is the risk of not catching that super fast block on the small pool too great?

I'm sorry, but also reading your comments on the bitp.it thread, I am not sure you understand the mathematics behind hopping. Forget your concept of "luck". This is just basic probability theory.

Maybe I am entirely misunderstanding the math.  I haven't the knowledge to do a detailed analysis of how getting a massive (in the case of bitp.it 3x) boost in hash rate effects the number and rate of finding blocks.  Perhaps there is no correlation.  If I had to guess, I would think that people who mine in a single pool that is being hopped ARE negatively effected, but not to the extent that most believe due to more blocks being found with a massive increase in hash rate.  

Maybe I am totally off base. . .

Care to comment on the comment you were responding to initially though about different pool speeds and jumping? 

I really didn't have the math for this when I started, so I wiki'd up on the Poisson process and read the following papers:

http://mining.bitcoin.cz/media/download/poolcheating.pdf

http://www.bitcoinservice.co.uk/files/111


After about a month of reading, learning and experimenting I think I have a fair idea of what's going on, although I still make conceptual mistakes. The papers I've linked to will probably do a better job of teaching you about hopping than I can, so read them if you have the time and inclination - you won't waste time travelling down roads already travelled.

Cheers!

[bb]

I am wondering if its possible to code so that if you are mining at a pool that is say 500Ghash/s total speed and they are at 300k shares or something that you don't immediately jump to a pool that has a speed of 50Ghash/s that just found a block.  Wouldn't it be more profitable to finish the 43% with the fast pool and then jump?  Or is the risk of not catching that super fast block on the small pool too great?

I'm sorry, but also reading your comments on the bitp.it thread, I am not sure you understand the mathematics behind hopping. Forget your concept of "luck". This is just basic probability theory.

Maybe I am entirely misunderstanding the math.  I haven't the knowledge to do a detailed analysis of how getting a massive (in the case of bitp.it 3x) boost in hash rate effects the number and rate of finding blocks.  Perhaps there is no correlation.  If I had to guess, I would think that people who mine in a single pool that is being hopped ARE negatively effected, but not to the extent that most believe due to more blocks being found with a massive increase in hash rate.  

Maybe I am totally off base. . .

The boost in hash rate is proportional to the number of people jumping to the pool. What this also means though is that there are more shares calculated by hoppers. So when a block is found, more bitcoins go to hoppers.

The essence of pool hopping is that statistically the first shares of a round are worth more than the last ones. Now the more pool hoppers come in to take a larger portion of early shares, the worse it is for single pool miners.

If this doesn't make enough sense, I can explain some more tomorrow. :-)

Care to comment on the comment you were responding to initially though about different pool speeds and jumping? 

?

[dikidera]

@Dikidera, everyone on a forum gets pounded on every now and the -  if you're as 4-channy as you seem you know that. We've all posted things on the spur of the moment we're not proud of, and we've all has people annoy us and there is always the temptation to keep the flame burning. But there is never an excuse for using all caps. So let's just pretend page 39 edit 39 and 40 didn't happen and start again.

I'm sure you could spend time 4-channing us, but this is a really good proxy once you understand how it works and why.

1. Pool hopping currently works well only on proportional pools and only when you have access to non-delayed total shares. Neither btcguild or deepbit provide usable total share stats.
2. bitHopper provides a user stats page you can access on your browser on 127.0.0.1 which shows efficiency. You'll be able to see it work and see how far ahead you are by using it.
3. Since I've been using bitHopper I've had 140% to 200% efficiency on pools we use, for a total of 160%. Multipool's efficiency is around 120%.
4. Challenges coming up: loss of usable pools stats.

If you do have real coding skills (which is what I assume you're referring to when you recommend we don't anger you, and not that you've had an accident with a radioactive substance and go green and ragey when you get cranky) then help the project! We could do with someone helping with html scraping.

Why is there a problem with delayed stats? Pool hopping is just that. You request work, send a share, switch, send a share, switch and so on....this is not how i imagine pool hopping to be.

[muyoso]

Why is there a problem with delayed stats? Pool hopping is just that. You request work, send a share, switch, send a share, switch and so on....this is not how i imagine pool hopping to be.

What would be the use of doing that?  Do you know how inefficient that would be?  Request work from pool 1, send a share,  disconnect from pool 1, connect to pool 2, request work, send a share, etc, etc, etc. . .

If that was what pool hopping was, why wouldn't you just open up multiple workers, one per pool and let them mine away sharing your GPU?

Just to make it clear, your concept of pool hopping is not remotely correct.

[Clipse]

@Dikidera, everyone on a forum gets pounded on every now and the -  if you're as 4-channy as you seem you know that. We've all posted things on the spur of the moment we're not proud of, and we've all has people annoy us and there is always the temptation to keep the flame burning. But there is never an excuse for using all caps. So let's just pretend page 39 edit 39 and 40 didn't happen and start again.

I'm sure you could spend time 4-channing us, but this is a really good proxy once you understand how it works and why.

1. Pool hopping currently works well only on proportional pools and only when you have access to non-delayed total shares. Neither btcguild or deepbit provide usable total share stats.
2. bitHopper provides a user stats page you can access on your browser on 127.0.0.1 which shows efficiency. You'll be able to see it work and see how far ahead you are by using it.
3. Since I've been using bitHopper I've had 140% to 200% efficiency on pools we use, for a total of 160%. Multipool's efficiency is around 120%.
4. Challenges coming up: loss of usable pools stats.

If you do have real coding skills (which is what I assume you're referring to when you recommend we don't anger you, and not that you've had an accident with a radioactive substance and go green and ragey when you get cranky) then help the project! We could do with someone helping with html scraping.

Why is there a problem with delayed stats? Pool hopping is just that. You request work, send a share, switch, send a share, switch and so on....this is not how i imagine pool hopping to be.

Sup Pinky, where is the Brain ?

[dikidera]

@Dikidera, everyone on a forum gets pounded on every now and the -  if you're as 4-channy as you seem you know that. We've all posted things on the spur of the moment we're not proud of, and we've all has people annoy us and there is always the temptation to keep the flame burning. But there is never an excuse for using all caps. So let's just pretend page 39 edit 39 and 40 didn't happen and start again.

I'm sure you could spend time 4-channing us, but this is a really good proxy once you understand how it works and why.

1. Pool hopping currently works well only on proportional pools and only when you have access to non-delayed total shares. Neither btcguild or deepbit provide usable total share stats.
2. bitHopper provides a user stats page you can access on your browser on 127.0.0.1 which shows efficiency. You'll be able to see it work and see how far ahead you are by using it.
3. Since I've been using bitHopper I've had 140% to 200% efficiency on pools we use, for a total of 160%. Multipool's efficiency is around 120%.
4. Challenges coming up: loss of usable pools stats.

If you do have real coding skills (which is what I assume you're referring to when you recommend we don't anger you, and not that you've had an accident with a radioactive substance and go green and ragey when you get cranky) then help the project! We could do with someone helping with html scraping.

Why is there a problem with delayed stats? Pool hopping is just that. You request work, send a share, switch, send a share, switch and so on....this is not how i imagine pool hopping to be.

Sup Pinky, where is the Brain ?

Did i give you permission to speak slave?

[muyoso]

Pretty sure bitcoins.lc is delaying stats by 30 minutes.  By the time I switch over they usually already have 180k shares.  Is it still profitable to mine there when you miss the first 200k shares?  I see no real reason why it wouldn't be . . .

Edit:  Looks like it really effects payouts for smaller rounds.  I should be getting per round payouts in the .077 range for rounds under 700k shares if I was to jump in immediately, but I am seeing payouts in the .03 range instead.  Also missed a block entirely because it was less than 30 mins.  

Still more profitable than mining at Arsbitcoin with those same number of shares, but payouts are drastically reduced.

[nob]

Anyone got some namecoin pools working?

Bitparking for backup purposes is no problem, but other namecoin pools seems to have no API too.

Theres Poolmunity with an API, but i didn't got it working.

The Problem with namecoins is, that the'll be unprofitable in 2 Days, so it's maybe not worth putting some serious work in it.

[organofcorti]

@Dikidera, everyone on a forum gets pounded on every now and the -  if you're as 4-channy as you seem you know that. We've all posted things on the spur of the moment we're not proud of, and we've all has people annoy us and there is always the temptation to keep the flame burning. But there is never an excuse for using all caps. So let's just pretend page 39 edit 39 and 40 didn't happen and start again.

I'm sure you could spend time 4-channing us, but this is a really good proxy once you understand how it works and why.

1. Pool hopping currently works well only on proportional pools and only when you have access to non-delayed total shares. Neither btcguild or deepbit provide usable total share stats.
2. bitHopper provides a user stats page you can access on your browser on 127.0.0.1 which shows efficiency. You'll be able to see it work and see how far ahead you are by using it.
3. Since I've been using bitHopper I've had 140% to 200% efficiency on pools we use, for a total of 160%. Multipool's efficiency is around 120%.
4. Challenges coming up: loss of usable pools stats.

If you do have real coding skills (which is what I assume you're referring to when you recommend we don't anger you, and not that you've had an accident with a radioactive substance and go green and ragey when you get cranky) then help the project! We could do with someone helping with html scraping.

Why is there a problem with delayed stats? Pool hopping is just that. You request work, send a share, switch, send a share, switch and so on....this is not how i imagine pool hopping to be.

Good question, Dikidera. A lot of people confuse pool-hopping with randomly jumping from pool to pool to spread our your shares and minimise variance. But that is what it definitely is not. A few very clever people showed early this year (late last year? whatever) that in a proportional pool, you can increase your average coinage per share by never staying in the pool after the total shares have reached 0.43*<difficulty> Then you hop to another proportional pool with total shares under 0.43*<difficulty> or to a PPS pool.

Another point is that it turns out that earlier in a round a share has more worth than later in a round. This means it's also better to hop from a proportional pool at, for example, 0.3*<difficulty> to a proportional pool at 0.1*difficulty.

This is unintuitive, but if you have the time to go over the math, it's fascinating. I've posted these links before, but they're worth posting again:

http://mining.bitcoin.cz/media/download/poolcheating.pdf

http://www.bitcoinservice.co.uk/files/111


If you aren't interested in the math just try it your self for a week or so and look at the results.

Did i give you permission to speak slave?

Come on! Srsly? You can't tell when people are trying to get a rise out of you? My mum always told me, "ignore them and they'll stop bothering you". It didn't work, but whatever.

[ryouiki]

latest Mod fully supports NameCoin pools
added BitParking and NameBit

http://cl.ly/0t1q0B1E2d040f0F1L3n/screen2011_07_22_18_10_31_1.jpg

if you feel lucky, now you can donate NMC to me

[nob]

great, i'm testing it atm


Currently bithopper is only mining on tripple and not on the Namecoin pools.
The Problem for hopping Namecoins and Bitcoins is, that the Namecoin Profitabilty depends on the Exchange Price NMC/BTC. ATM Namecoin Mining is about 50% more Effective than mining Bitcoins, i tryed using 0.25 Penalty for the NMC Pools but it doesn`t work.

Maybe the easiest sollution is enabling the NMC pools and disabling the BTC pools, but bithopper is still submitting to the BTC Backuppools instead of the (mor profitale) NMC Pools.
So i had to disable the Backup Pools and use bitparking for backup and namebit for hopping.

//Edit:

ok was confused its working.

Early shares on BTC pools are more provitable, then shares on NMC Pools.
Namebit had a new block and BitHopper switched from MTRed to NameBit


I modified NMC Pool Penalty to adjust the NMC/BTC Value for me

Thanks

//Edit2:
Final thoughts.

On 50% [~15L Shares) BitHopper swtched from BitParking to Arsbitcoin.
But Namecoins are more effective, than Bitcoins. For Switching Pools you need the NMC/Bitcoin Profitably, so you only switch to a BTC Pool from a NMC pool when the NMC Pools has a "total efficentcy" of nmc_difficulty*.431 * NMC/Bitcoin Ratio (atm 1.39) > http://dot-bit.org/tools/nextDifficulty.php (or just use a price from namecoinexchange hey have an API http://dot-bit.org/forum/viewtopic.php?p=964#p964 )
But that's just to much work, for just 2 Days of Namecoinmining.

I'll disable the namecoin pools again.

[organofcorti]

@c00w: if I update to a new version, how do I keep my stats to that point?