bitHopper: Python Pool Hopper Proxy

[Sukrim]

Bitclockers.com Webpage: 3,407,040 shares
Bitclockers.com API:

Code:

{"hashrate":233367.6,"activeworkers":641,"roundshares":100322,"roundstales":35389,"lastroundshares":102881,"currentblock":109,"currentblockstart":"2011-08-12 06:15:02"}

The hashrate and the currentblockstart field seem to be ok - we could run sanity checks there. OR we just scrub their web page, which might hurt them more + force them to lie to their users more openly.

Edit: can we have the statspage login data at least in the config file instead of in the command line?! Bash history and stuff...

Edit2:
About bitcoinpool.com, we might need a mine_trickle role. Basic outline:

1) Mine until 43.5% of difficulty is reached + time how long it took to reach it.
2) Deduct from this the time it takes you to find 2-3 shares (about a minute for a normal GPU) or just some plain 5 minutes (or nothing, as they expect 50% anyways)
3) After this time, mine on the mine_trickle pool again until 1 valid share has been found. Then issue a LP to your miners and continue with whatever you were doing.

If you look at their stats page, there are ~50 hoppers out of ~400 users who would benefit from this.
The impact isn't that huge anyways, as the real money comes from short rounds - but I still find it very repulsive if pool operators just arbitrarily set rules to get money from miners instead of fixing the real issue.

[1713261975]

1713261975

[1713261975]

1713261975

[1713261975]

1713261975

[Keninishna]

lol looks like rfc pool is done, this is from the website.

rfcpool has been shut down because the owner is a fucking idiot - that
should sum it up in brief.


If you were a miner, your money is all accounted for, and you will be paid as
soon as the most recent block matures. If you did not have a wallet address
in your account then email chris@rfcpool.com and after slinging your abuse
at me, tell me the username/email on account/wallet combination and you will
get paid.

So what happened? Well in short, running a pool and dealing with
people's money is a metric fucktonne harder than I ever imagined it would
be, and a series of fuckups relating to handling all said money has left me
about 150BTC out of pocket, so I'm pulling the plug before the situation
gets any worse.

- an early invalid cost us 30BTC
- the decision to go PPS was crazy and cost us 20BTC
- accidentally paying out double for a block reset in an attempt to turn PPS
  off again cost 100BTC

Good luck to all other pool ops.



---

And a note from Rennex: we've been sustaining losses from PPS and the
invalid block along the way, but this latest mess happened at almost
the worst possible moment - Chris was just about to leave on a trip, so
there was no time to start cleaning it up.

But things aren't all FUBAR, we'll take some time to examine the damage
and correct the errors. Some people may have been paid too much because
of auto payouts, and others' accounts got credited too much. We can fix
the latter and deal with the former - and if miners feel that they want
to return excess payouts once we determine the real balances, there will
be a way to do that too.

But for now, we'll cool off and examine the situation, and see if we
want to continue in the near future. Check back in a while

You can also contact us on IRC: #rfcpool on FreeNode.

Oh and if you don't know which pool to choose for now, I hear that
Ozcoin isn't half bad

[Technocrat]

New namecoin pool:

Code:

[nmcbit]
name: nmcbit.com
namecoin: Yep
mine_address: nmcbit.com:8332
api_address: http://nmcbit.com/statistics
api_method: re
api_key: Valid\s+shares\s+for\s+current\s+round:</th><td>([,0-9]+)</td>
api_strip: ','
url: http://nmcbit.com/dashboard

[organofcorti]

This made me think:

Good news everyone! 43% is dead!

We no longer have to hop at 0.43*difficulty!
...

Of course in any given round, after total shares=diff, your shares are worth less than one. But over time the shorter rounds make up for it. Even with only 3 Prop and backup, your efficiency will always be about 1.83, unless you hop off *too soon*. With ten other pools you get about 250% over PPS - sound familiar?

tl;dr BOLD CLAIM: As long as you always hop to the pool with the lowest shares - regardless of hashspeed - you don't need to hop to backup at 0.43.

I tried several schedulers now and I thought about the following (new "--HopLowestSharecount" scheduler):

- mine the 3 pools with lowest sharecount at any moment (where 3 can be changed to a custom value with "--hop_ x_pools=3" parameter)
- forget about the 0.43 threshold
- It won't need back-up pools, it will always hop between the 3 pools with lowest sharecount and with 18 pools, that should work without problems

It's a bit like the OldDefaultScheduler and SliceScheduler, without the threshold.

That is bold to make bold claims, and be incorrect at them. A share submitted after 43.3% of difficulty has elapsed in a proportional pool has a lower expected return than if that share was submitted to a 0 fee PPS or even-paying pool, or if a switch was made to solo mining. By mining from the start until 100% of difficulty shares, you reduce your expected return from 28% to 22%. Considering the lag in statistics and delays switching into and out of a proportional pool, you should be triggering an earlier exit than that to maximize your expected earnings. By mining more pools, you have a higher chance of one of the pools being in the sweet spot, and can also choose the highest reward pool at a particular time, but that doesn't change the ultimate temporal valuation of a submitted share.

I understand your confusion, but if you read my post you'd se the reason for the 200% efficiency at hop=1.0 is that IN THE LONG TERM (sorry but I *am* feeling a bit shouty since we've already been through this when I first posted) it doesn't matter. The simulations are for about 100000 rounds and tell us the expected efficiency.

If you set the hop to 1.0, and you have ten pools then the very few times it actually hits 1.0 before it jumps will have a minimal effect in the long term.

That is bold to make bold claims, and be incorrect at them.

I quite agree.
ooc

[r2edu]

I´m with latest version 0.1.7.1-30, don´t know why but: Polmine at the instant i run bh, shows the real percentage ad share count, and when it start a round resets to 0% and hop there and mine ok... but with bclc and db nothing of that happens

I think for moment i go back to mine bclc with the old pools.cfg, I know is not the real stats but i least i take some BTC in there that way... and with DB, don´t know.. I think i can live without it until it works, no problem!

btw, bitclockers is fakin the stats too?? just when i thought it starting to mine better there, with less "reconections" (?)

[muyoso]

I´m with latest version 0.1.7.1-30, don´t know why but: Polmine at the instant i run bh, shows the real percentage ad share count, and when it start a round resets to 0% and hop there and mine ok... but with bclc and db nothing of that happens

I think for moment i go back to mine bclc with the old pools.cfg, I know is not the real stats but i least i take some BTC in there that way... and with DB, don´t know.. I think i can live without it until it works, no problem!

btw, bitclockers is fakin the stats too?? just when i thought it starting to mine better there, with less "reconections" (?)

I think Bitclockers is alright for the moment.  For about an hour their they seemed to reset their JSON stats but they have been back to normal for a few hours now.

[ryouiki]

I got almost the same graph of @organofcorti two weeks ago. (from my own open-sourced simulator)
However, 100% agree with @deepceleron

When we have more proportional pools, efficiency doesn't 'seem' to be decaying because we have more chance to hop into < 43% pool all the time.
Earlier share is always more profittable, slicing reduces profit in the long time, and a share from > 43% pool is less profittable than a share from pps pool.

[c00w]

@auth arguments

auth was meant to be purely optional. It is currently purely optional in bleeding edge and I think the previous version.

[Big Time Coin]

bcpool has been faking stats all day, I've been watching it.  Here is an example (times are in Mountain):

[22:03:27] RPC request [getwork] submitted to bcpool
[22:03:30] bcpool: 1668  96.2gh/s 27min.
[22:03:30] Setting Block Owner bcpool:298e948fe1d2891ab0c201d0ff41e4e2b6aa6bcf1d
1734de000001db00000000
[22:03:31] RPC request [2274f000] submitted to bcpool

bcpool has been reporting between 1000 and 99000 shares on the round all day, but I've been checking bitcoinpool.com and they have not solved a block all day.

[muyoso]

bcpool has been faking stats all day, I've been watching it.  Here is an example (times are in Mountain):

[22:03:27] RPC request [getwork] submitted to bcpool
[22:03:30] bcpool: 1668  96.2gh/s 27min.
[22:03:30] Setting Block Owner bcpool:298e948fe1d2891ab0c201d0ff41e4e2b6aa6bcf1d
1734de000001db00000000
[22:03:31] RPC request [2274f000] submitted to bcpool

bcpool has been reporting between 1000 and 99000 shares on the round all day, but I've been checking bitcoinpool.com and they have not solved a block all day.

Yep.  I don't know if its possible but all of the stats for individual users are on this page:

http://bitcoinpool.com/index.php?page=1&ipp=All&do=currentround

If we were able to simply add up all of the user shares we would get the total shares for the current block.  Sounds simple enough but IDK anything about python or coding.

[creativex]

Bitparking IXC:

[ixparking]
name: IXParking.com
namecoin: Yep
mine_address: ixpool.bitparking.com:10098
api_address: http://ixpool.bitparking.com/user
api_method: re
api_key: Total Pool Shares</td><td>([ 0-9]+)</td>
api_strip: ' '
url: http://ixpool.bitparking.com/pool/%(user)s

[ixparking]
# IXC, use mine_ixc . Good for hopping if you want some ixccoins.
#http://bitparking.com/
#CHANGE THIS (if you want)
role: mine_ixc
penalty: .25
user: xxxGETYEROWNxxx
pass: x

[creativex]

TY.

[Sukrim]

Urgh, not these scamcoins!

Is mine_ixc really implemented? We need a difficulty for these btw. too...

[Clipse]

Urgh, not these scamcoins!

Is mine_ixc really implemented? We need a difficulty for these btw. too...

Its only a scam when you cant make money from it

[organofcorti]

I got almost the same graph of @organofcorti two weeks ago. (from my own open-sourced simulator)
However, 100% agree with @deepceleron

When we have more proportional pools, efficiency doesn't 'seem' to be decaying because we have more chance to hop into < 43% pool all the time.
Earlier share is always more profittable, slicing reduces profit in the long time, and a share from > 43% pool is less profittable than a share from pps pool.

What the graphs show is that for a large number of alternative pools what you gain in efficiency per share for hopping earlier, you lose on the PPS back up. The efficiency remains constant because as you increase the hop off point you don't need to hop to back up and go for 1.0 efficiency anymore. Did your sim include a PPS backup, or just look at per share efficiency?

I'd love you to post your graphs so we can get a side by side comparison.

The real problem is variation, which slicing can help with at a cost to efficiency.

You can hop early if you want (although too early loses you efficiency since there will be fewer available pools under that level leaving you with PPS) but your efficiency wont be any better in the long run. Your variance with be better if you hop since you'll be using PPS a lot and if it wasn't for hoppers being banned and having to manage extra PPS accounts I'd stay hopping early.

I've been hopping only one week at 1.0 and although it's early (given the extra variance doing it this way) I seem to be getting results in the ballpark I was expecting (150 to 250%).



Edit: While I'm on the subject, 43% only applies to one single prop pool with one single backup. The max is slightly different for two prop pools +pps, etc up to about 4 prop+pps when it levels out totally and there is no local maximum after about .2*diff.

[organofcorti]

bcpool has been faking stats all day, I've been watching it.  Here is an example (times are in Mountain):

[22:03:27] RPC request [getwork] submitted to bcpool
[22:03:30] bcpool: 1668  96.2gh/s 27min.
[22:03:30] Setting Block Owner bcpool:298e948fe1d2891ab0c201d0ff41e4e2b6aa6bcf1d
1734de000001db00000000
[22:03:31] RPC request [2274f000] submitted to bcpool

bcpool has been reporting between 1000 and 99000 shares on the round all day, but I've been checking bitcoinpool.com and they have not solved a block all day.

Yep.  I don't know if its possible but all of the stats for individual users are on this page:

http://bitcoinpool.com/index.php?page=1&ipp=All&do=currentround

If we were able to simply add up all of the user shares we would get the total shares for the current block.  Sounds simple enough but IDK anything about python or coding.

yeh, while I've been watching the json feed has shown them solve 140903, 140904, 140906, and currently on 140910. I thought they weren't going to screw with donors. Might have to rethink my 2% donation.

[MaGNeT]

Urgh, not these scamcoins!

Is mine_ixc really implemented? We need a difficulty for these btw. too...

Its only a scam when you cant make money from it

I don't complain The 2000 are withdrawn from https://ixchange.bitparking.com/main, where I still have parked 6000.
 

[Sukrim]

If bitparking gets an API, we might even be able to automatically convert mined ___coins into Bitcoins, lowering the arbitrage risk. I'm not sure however if this really should be a feature of a pool hopping client...

[hawks5999]

bcpool has been faking stats all day, I've been watching it.  Here is an example (times are in Mountain):

[22:03:27] RPC request [getwork] submitted to bcpool
[22:03:30] bcpool: 1668  96.2gh/s 27min.
[22:03:30] Setting Block Owner bcpool:298e948fe1d2891ab0c201d0ff41e4e2b6aa6bcf1d
1734de000001db00000000
[22:03:31] RPC request [2274f000] submitted to bcpool

bcpool has been reporting between 1000 and 99000 shares on the round all day, but I've been checking bitcoinpool.com and they have not solved a block all day.

Yep.  I don't know if its possible but all of the stats for individual users are on this page:

http://bitcoinpool.com/index.php?page=1&ipp=All&do=currentround

If we were able to simply add up all of the user shares we would get the total shares for the current block.  Sounds simple enough but IDK anything about python or coding.

yeh, while I've been watching the json feed has shown them solve 140903, 140904, 140906, and currently on 140910. I thought they weren't going to screw with donors. Might have to rethink my 2% donation.

they paid out... once their json stats are fixed to reality I'll begin mining them again.

[Clipse]

If bitparking gets an API, we might even be able to automatically convert mined ___coins into Bitcoins, lowering the arbitrage risk. I'm not sure however if this really should be a feature of a pool hopping client...

You dont need any api for this, it can be done with the magic of mathematics and regex scraping