[EXPERIMENTAL] poclbm-autohop: Yet Another Automatic Pool Hopper

[hawks5999]

Have you collaborated at all with c00w, bloodred, ryouiki or other hopping developers? Seems like some of them have different takes on various pools and are able to support some that you aren't. I also think their projects would benefit from your work with pident. Eventually I'd like to see all your projects roll together into one super hopping client.

[Aexoden]

Have you collaborated at all with c00w, bloodred, ryouiki or other hopping developers? Seems like some of them have different takes on various pools and are able to support some that you aren't. I also think their projects would benefit from your work with pident. Eventually I'd like to see all your projects roll together into one super hopping client.

My primary goal was to distrust the pools as much as possible. It'd be easy to hop a bunch of other pools if I were to just use their APIs. (In fact, older versions of poclbm-autohop did just that. Only pool I lost in the transition was bitclockers, though.) Of course, I'm trusting pools to report their blocks accurately. They might delay those stats, but I think most pools are unlikely to hide them completely. However, they might take a bitclockers type approach, where they make it almost impossible to associate the blocks with real blocks (by not providing the block number or hash).

In other news, I'm ready to report the first results of efficiency hopping BTC Guild. At first glance, it won't look good. My efficiency has been a paltry 81%. However, it's not as bad as it sounds. BTC Guild is stuck in a period of bad luck. A full-time BTC Guild miner's efficiency over the same period is only 72%. (Both of these numbers are relative to what the miner would have earned at a 0% PPS pool.) In the end, it looks like we should still be able to effectively hop pools that are delaying their statistics, if at a reduced efficiency.

[Aexoden]

Recent updates:

• Support for Bitminter was added.
• Since RFCPool has closed, support has been removed.

Otherwise, not much is happening. BTC Guild results are still significantly better than for a full-time miner.

[roos]

I get the following when trying to start poclbm for the first time after adding the following pools to pools.conf

bitpit
bitcoins.lc
bitminter
btcguild
mtred
ozco.in


Traceback (most recent call last):
  File "./poclbm.py", line 67, in <module>
    miner = BitcoinMiner(devices[options.device], options, VERSION, HttpTransport.HttpTransport)
  File "/home/roos/src/aexoden-poclbm-2889219/BitcoinMiner.py", line 33, in __init__
    self.transport = transport(self)
  File "/home/roos/src/aexoden-poclbm-2889219/HttpTransport.py", line 21, in __init__
    super(HttpTransport, self).__init__(miner)
  File "/home/roos/src/aexoden-poclbm-2889219/Transport.py", line 32, in __init__
    self.best_pools = self.pools.get_best_pools()
  File "/home/roos/src/aexoden-poclbm-2889219/pools.py", line 97, in get_best_pools
    return sorted(self.pools.values(), key=lambda pool: (pool.utility, pool.priority), reverse=True)
  File "/home/roos/src/aexoden-poclbm-2889219/pools.py", line 97, in <lambda>
    return sorted(self.pools.values(), key=lambda pool: (pool.utility, pool.priority), reverse=True)
  File "/home/roos/src/aexoden-poclbm-2889219/pools.py", line 125, in utility
    self.update_data()
  File "/home/roos/src/aexoden-poclbm-2889219/pools.py", line 116, in update_data
    self.rate = get_pool_rate(self.pident_name)
  File "/home/roos/src/aexoden-poclbm-2889219/pools.py", line 31, in get_pool_rate
    return _pool_data[0]['rates'][pool] if pool in _pool_data[0]['rates'] else 0.0
KeyError: 'rates'

[Aexoden]

I get the following when trying to start poclbm for the first time after adding the following pools to pools.conf

bitpit
bitcoins.lc
bitminter
btcguild
mtred
ozco.in

My copy of pident is currently having problems with its scoring system, causing it to not properly update the API. I'm attempting to fix it at the moment. It should work again in a few minutes, though.

EDIT: API is running again. Still not sure what caused pident to start having lots of division by zero errors. Since its base scoring code is opaque to me at the moment, I'm not in much of a position to debug it effectively. However, I have avoided the error as a stopgap measure.

[Aexoden]

As it turns out, the donation percentage code never actually correctly read the donation percentage from the configuration file. This has been fixed.

In other news, there will be approximately a one week period in late September where the API will not be updated. As a result, anyone using this miner will most likely only mine at fair pools for that week, rather than hop.

The ultimate goal, however, should be to somehow improve the whole process so that it doesn't rely on a third-party API. However, the reliance on pident makes this quite difficult. I have little time for bitcoin at the moment, so I'm probably not going to come up with anything myself anytime soon.

[roos]

This doesnt look right, btcguild had a new block 20mins ago and several others have had blocks too.


30/08/2011 21:31:18,   bitpit         : 1.000                                   
30/08/2011 21:31:18,   eligius        : 1.000                                   
30/08/2011 21:31:18,   mtred          : 0.310                                   
30/08/2011 21:31:18,   ozco.in        : 0.298                                   
30/08/2011 21:31:18,   bitcoins.lc    : 0.211                                   
30/08/2011 21:31:18,   triplemining   : 0.191                                   
30/08/2011 21:31:18,   bitminter      : 0.190                                   
30/08/2011 21:31:18,   btcguild       : 0.079                                   
30/08/2011 21:31:18,   nofeemining    : 0.054   

[Aexoden]

This doesnt look right, btcguild had a new block 20mins ago and several others have had blocks too.


30/08/2011 21:31:18,   bitpit         : 1.000                                   
30/08/2011 21:31:18,   eligius        : 1.000                                   
30/08/2011 21:31:18,   mtred          : 0.310                                   
30/08/2011 21:31:18,   ozco.in        : 0.298                                   
30/08/2011 21:31:18,   bitcoins.lc    : 0.211                                   
30/08/2011 21:31:18,   triplemining   : 0.191                                   
30/08/2011 21:31:18,   bitminter      : 0.190                                   
30/08/2011 21:31:18,   btcguild       : 0.079                                   
30/08/2011 21:31:18,   nofeemining    : 0.054   

Looks like the update process locked itself up ~18 hours ago. It should be catching up now, unless there's a bigger problem, which I'll find out shortly, I assume. Consider this a preview of how things will look when updates are suspended for ~8 days in late September.

[organofcorti]

New "how to hop" blog post:

How to hop part2: More on score

This week we discover Slush-type score systems fatal flaw, an update on the Slush hop point (previous estimate nearly 50% out), and what 'c' really means, and how to turn that old newspaper into something beautiful!

[Aexoden]

New "how to hop" blog post:

How to hop part2: More on score

This week we discover Slush-type score systems fatal flaw, an update on the Slush hop point (previous estimate nearly 50% out), and what 'c' really means, and how to turn that old newspaper into something beautiful!

Though, in order to add slush to this program, at least, I'd have to figure out how to calculate the utility of a given share. It should be possible once I've done the relevant analysis, but I don't exactly have the motivation to do such a thing at the moment.

As a second point, I'm worried that the list of pools I'm operating with is languishing a bit. It seems NoFeeMining changed to RSMPPS at some point, so it's been changed to a fair pool. Have there been any other proportional pools started? I hope we're past that point, given how easy it is to hop them. I'm unsure about adding any additional fair pools, as I already support several. In any case, they'd have to be added to pident first.

[organofcorti]

Though, in order to add slush to this program, at least, I'd have to figure out how to calculate the utility of a given share. It should be possible once I've done the relevant analysis, but I don't exactly have the motivation to do such a thing at the moment.

How do you define utility? If it is the expected value of a share if a given number of shares in a round have already occurred, I can send you a score table, or you can generate one yourself. Otherwise, let me know if I can help.

[Aexoden]

Though, in order to add slush to this program, at least, I'd have to figure out how to calculate the utility of a given share. It should be possible once I've done the relevant analysis, but I don't exactly have the motivation to do such a thing at the moment.

How do you define utility? If it is the expected value of a share if a given number of shares in a round have already occurred, I can send you a score table, or you can generate one yourself. Otherwise, let me know if I can help.

Based on available data, usually things like the current number of shares (but in slush's case, also the time since the last block and the hash rate, I believe), the expected value of a share, relative to PPS. I prefer a mathematical function to a table. For instance, the relevant function for proportional pools is equal to 1.0 at ~0.4348.

[organofcorti]

No problem. I'll run eureqa on Monday and make you a utility function for slush that will be accurate to at least 0.5*diff. That ok? It won't be derived from the calculus but it will work.

[Aexoden]

No problem. I'll run eureqa on Monday and make you a utility function for slush that will be accurate to at least 0.5*diff. That ok? It won't be derived from the calculus but it will work.

As long as it's relatively accurate up until the crossover point (when it drops below 1.0) it should be fine for my purposes.

[Vladimir]

Motivation

Many mining pools are still using the inherently unfair proportional payout system. My primary intent is to encourage pool operators to migrate their pools to fair systems. It seems as if the only way this will happen is if miners themselves see that the proportional system is unfair. (Unfortunately, the fair systems often seem unfair at first glance, making explanations more difficult.)

Good idea. The more the merrier. In all seriousness.

[MrWizard]

PPS/variation and prop is the most fair reward system and pplns is the most dangerous reward system and you miners should run away from pplns, maybe just maybe you need a slap to learn a lesson

+1

[cuqa]

Everyone should read this

After much consideration and review of how our anti-pool hopping system is looked upon by members of the Bitcoin community, we have chosen to change the way in which it is working.

In the Past:
If a user participated in less than 50% of the round, their shares would be reduced by 10%, unless a donation was set, in which case, no penalty was applied.

This allowed for our users with legitimate disconnects, or reasons for being unable to mine during long rounds to avoid being hit with a penalty.

Some people seem to belive that this is a negative aspect of the anti-hopping system due to the easily cheatable nature of the system and the fact that pool hoppers are still given a large incentive to exploit our pool.

From Now on:
If a user participates in less than 50% of the round, their shares will be reduced by 50%, regardless of donation. 50% of the penalty fee will be directed toward the donations account and will be applied to server costs and future monthly contests. The other 50% of the penalty will be removed from the total shares for the round, which will in-hand cause the value of all remaining shares in the round to increase.

Example -

100,000 shares are in the round.

User A has 5000 shares and is NOT a hopper. Their estimated earnings before penalties are applied is 2.5 BTC.

User B has 5000 shares and IS A hopper. Their estimated earnings before penalties are applied is 2.5 BTC.

Once penalties are applied, User B's shares are reduced to 2500 where 1250 has been credited to donations and 1250 has been removed from the round. After the penalty is applied, User B's unconfirmed earnings are 1.265 BTC and User A's unconfirmed earnings are 2.5316 BTC.

At this time, any donation currently set on your account will remain in place. Donations will be processed prior to any penalties. As a reminder, donations are entirely voluntary and are not required to use this pool.

We will use this new method of calculating penalties for a one week trial period, at which time we will decide whether or not it is effectively deterring pool hopping and effectively rewarding loyal members of the pool.

Regards,

BitcoinPool Staff

[iopq]

pplns is the most dangerous reward system and you miners should run away from pplns

why is that? because pool owners can hide solved blocks?

[Aexoden]

PPS/variation and prop is the most fair reward system and pplns is the most dangerous reward system and you miners should run away from pplns, maybe just maybe you need a slap to learn a lesson

I can't think of any reason PPLNS would be more dangerous than any other system. Assuming you can trust the operator, it is both hopping-proof and much more resilient to long periods of bad luck than any of the PPS variants.

If you can't trust the pool operator, then all systems have potential for abuse.

Everyone should read this

I had avoided adding bitcoinpool completely because of its Draconian measures designed to fight pool hoppers (rather than changing reward systems). Of course, as hopping becomes more prevalent, you can expect more pools to go down this road. Hopefully, they'll have to become so awful that users won't want anything to do with them, but I don't have high hopes in that regard. Users seem willing to tolerate a lot of abuse.

[iopq]

users still use slush, which is hoppable, api-friendly, and still doesn't have LP afaik
worse, it has a 2% commission and a high-variance payment method