Topic: Introducing CherryPicking - new Windows & Linux Pool Hopper - page 2. (Read 43136 times)

any update on the eta of 0.6.8? specifically, a way to prioritize merged mining pools

i'm having an issue with arsbitcoin. sometimes, but not all the time, CP will list their efficiency number as 10.0 even though they are a SMPPS pool. however, when i switch them to backup(PPS), it goes back to 1.00256....here is my cfg file for them

Type=SMPPS
Host=arsbitcoin.com
Port=8344
JSON=https://arsbitcoin.com/api.php
HashEx1="hashrate":"\d+
HashEx2=\d+
SharesEx1="currentroundshares":"\d+
SharesEx2=\d+
Div=1e3

I am, but I have significantly less free time and therefore significantly less time to dedicate to CherryPicking. I'm working on 0.6.8, most notably it will have an implementation of organofcorti's hop point approximation functions and a new parameter you can add to pool files to change their priority, so people who want to prioritize merged mining pools over regular pools can do so.

bloodred, you still here?

so with merged mining becoming active now in a few pools (eligius, slush) and others no doubt looking into it, are there plans to adapt CP to this?

Yes, the 40% bonus was applicable at the time of my post.  In the long term future the income bonus for merged mining will be precisely the market value of a namecoin divided by the market value of a bitcoin, maybe around 2%.  Right now that is 28% and falling.  In a small number of hours from now the income bonus will shoot up to around 100% (due to the falling Namecoin difficulty) but this will only hold for a day or so before returning to the mid 20's (my best guess).

That said, the income bonus should remain relatively high so long as the big pools don't use merged mining.  This will pressure the large pools to switch and we will soon reach a stable point where most pools are using merged mining.  I very much expect the proportional reward system will still be popular (why it's popular baffles me but it seems to be holding) so the miners which profit the most will be ones that have pool hopping software which takes full advantage of merged mining.  I don't doubt that in the mid-term that pool hopping will dwarf merged mining in terms of income bonus but right now I think merged mining is more profitable than pool hopping regular bitcoin pools.

I personally have no desire for such software as I mine PPLNS.  I just wondered whether or not hopping software could easily take both blockchains into account for effective merged mining pool hopping.

it sounds like a good feature for CP to have. but what exactly do you mean by 40% bonus? is this compared to just sitting in an only BTC pps pool 24/7? do you mean hopping several merged pools or just staying on one? and with changing difficulty and exchange rates surly merged mining can't always give a steady 40% increase in BTC.

One question that comes to mind is how this software can be configured to hop merged mining proportional pools effectively.  I expect that both the Bitcoin and Namecoin blocks would have to be taken into account when working out whether or not to mine at the proportional pool but perhaps ignoring the Bitcoin blocks and using the Namecoin blocks directly would yield most of the profit.  Will this software work directly on a merged mining pool?

I'm also not aware of the approximate income bonus that one might expect from pool hopping but I doubt it competes to the current 40% bonus of merged mining so if one has to choose then merged mining will have priority.  It would be great to be able to stack these methods for a higher bonus (maybe 60 or 70%?).

The other problem is having a non proportional merged mining pool to hop to.  All I know of right now is simplecoin PPLNS (BTC+2%, NMC+10%), simplecoin SMPPS (BTC+2%), and solo merged mining but all of these have high variance.

Thanks for the heads up...

mtred switched to pps payouts only. use it as a backup or take it off your hop list

http://www.reddit.com/r/mtred/comments/l7ik5/after_the_current_block_mtred_will_be_offering/

Rather than have discussions about the 'How to hop' blog here, I'm posting update announcements about new 'how to hop' posts at here. Make a comment to subscribe!

Also, there's a new 'How to hop', and the last one has been rewritten with errors removed - wtfman you might be interested in that.

Enjoy!

I've probably not explained as well as i thought. In 1.   PPS vs full time mining I showed the non hopping situation. In 2. PPS vs the first share in a round I look at the situation of a miner submitting only 1 share each and every round. This is equivalent to submitting the first share in each round, or 'hopping off' after only one share. This is still pool hopping.

The actual full quote of the tl;dr is:

So what I mean was that the reason the first share submitted in each round is worth so much more than the other shares is that the proportional payout rewards shorter rounds more (one share round is worth 50 btc) and that because shorter rounds are more likely because of the nature of block solving, earlier shares are worth more than later ones - hence the reason for pool hopping.

This part that explains it is:



So, I guess I failed at trying to make it an explanation accessible to everyone - what could I have done differently in terms of what you know about pool hopping?

Thanks for the feedback

I dont understand that at all to be honest. Also you are not even "pool hopping" in your example.

That would imply that simply mining in a prop pool would have a higher expected value than PPS and that is obviously not true.

So what other pools would CherryPicking work best with? When I think of pools that CherryPicking should have, I look through

https://github.com/c00w/bitHopper/blob/master/pools.cfg

and see pools like Deepbit, Swepool (which is down right now?), RFCPool, BTCWorld, BTCGuild, BitMinersUnion, and others, and I'm not sure which ones I should make a config for, and which ones are most compatible, etc.

How to hop 5 out now! Ever wonder why pool hopping works? Wonder no longer. No math required.

If Miner0 was running and then the others started on a hop it could very well be the account information issue I suggested. CherryPicking does not handle networking for the actual miners, so it's pretty much impossible for different instances of the same software (the miners) on the same machine to have network issues while others work.

Seems to be a problem with either the pool or the miner or CherryPicking.. the other night Miner0 was running just fine, and the other 4 miners were running @ 0MH/s with lots of connection errors. A little while later, the pools were updated, and all the miners were back up and working again at full blast, submitting shares to the various pools.

I also monitored the temperatures while this was happening.. during the time that all but Miner0 were idling, they were running at a low temperature, and when the pools were updated, they increased in temperature again and returned to mining. This suggests to me that the clocks and GPU loads weren't the problem.

That feature is actually already implemented and has been implemented from release, so you're saying you've encountered a bug with it?

When using poclbm, it invalidates a pool for 10 minutes if it receives 8 "Problem communicating with bitcoin RPC" errors in a 30s period. With Phoenix, it invalidates if it receives 3 "Failed to connect, retrying" errors in 40s. However, these checks are only made for Miner0 as they are meant to detect network errors (since everything is running on the same machine and on the same connection).

If Miner0 is working and the rest aren't it's very likely that the problem lies elsewhere, not with the pool or the network. They could have indeed crashed or have some other issues, such as bad miner accounts (be very careful with these, some pools accept shares even if your accounts are wrong, so in essence you'd be mining for nothing). If you have wrong accounts for certain pools and certain GPUs, those may not work on those pools but would be perfectly fine on others, so they would seem to stop randomly.

Also, please check actual GPU load to make sure they aren't working, that's a sure-fire way of knowing.

k, and as such I will remove my configs. It's a shame they're not hopable. :/

Also, bloodred, every now and then CherryPicking will just spend a long with just one GPU doing mining while the others idle @ 0 (making me think they've crashed) while the console log spits out "Failed to connect, retrying..." messages. Is it possible you could implement some feature that when a minute or so goes by and there's problems connecting, the miner switches to a backup pool (which is very reliable) and mines with that pool, checking back on the original pool every few minutes or so? During this time that no mining is taking place, no money is being made, and my 2150MH/s machine is being reduced to a 400MH/s drop-in-the-bucket.

I'll be fully back in action tomorrow or the next day.

BTCGuild and Deepbit do not work, I haven't made cfgs for them with good reason. They are too fast and delay stats for too long (they get to over 43% of a round during the delay period so you're essentially hopping blind which cannot guarantee efficiency), furthermore in the case of Deepbit the average shares in the last 24h have pretty much nothing to do with the shares of the current round.

Anybody is of course free to try, but I advise not to.