bitHopper: Python Pool Hopper Proxy

[organofcorti]

So heres a thought, anyone here consider putting together a theoretical luckbased approach ?

I know its been discussed here but I think it would still be interesting to actually do it.

Pull the last 2 or 3 blocks and see how far out of the difficulty range the avg is ie. 3blocks(just a number i like) combined gives 6million, that avg out at 2million per block so not terrible unlucky, however a different pool have their last 3 blocks at combined of 10million, thats > double avg difficulty per block thus we work a formula into the duration hopper should stay at this pool for this new block which would be the 1st block after the last 3blocks used for sample.

My rough approach would assume the following:

Right now we seem to use a 40% of diff approach, now if we use that as our base value and apply the difference of the last 3 blocks in example above we will get the following.

10million shares across 3blocks = 3333333.33 shares per block
This means the last 3 blocks lasted on avg 213% longer

We will then calculate our 40% into current difficulty which would be 625211.2 and add 213% which gives 1331699.85 difficulty thus the new difficulty for the selected pool to stay on for the 4th block(block just after the previous 3)

Now the reverse would be implied when a pool got really lucky in last 3blocks, thus we would be avoiding them or leave them far earlier than 40% of difficulty.

I hope this makes somewhat sense it does in my twisted mind.

please note: This is some hectic thumbsucking, would be nice to check it out in practice.

Hate to be the wet blanket that rains on your parade, but blocks are solved as a poisson process. Part of the definition of a poisson process is that it has no 'memory' of prior events. This means that each new block has a the same probability of being solved before <difficulty> as any other block. So a 'luck' based approach would only work randomly and increase variance. Sorry.

Now, who's going to open up another forum thread called 'Hoppers here!'. c00w must be getting sick of our meanderings, much as I enjoy them    

[1714132363]

1714132363

[1714132363]

1714132363

[1714132363]

1714132363

[Clipse]

haha oh yes I know it has no 'memory' and I didnt for one second assume you could cheat the 'luck'

It was more a case of curiosity than anything.

[organofcorti]

haha oh yes I know it has no 'memory' and I didnt for one second assume you could cheat the 'luck'

It was more a case of curiosity than anything.

Well, if you got it to work, you'd be making scientific history!  Give it a go, it would be an interesting test.

[bb]

haha oh yes I know it has no 'memory' and I didnt for one second assume you could cheat the 'luck'

It was more a case of curiosity than anything.

Well, if you got it to work, you'd be making scientific history!  Give it a go, it would be an interesting test.

No it wouldn't.

[nob]

I got rfcpool.com working, it's a very small and new pool

Code:

'rfcpool':{'shares': default_shares, 'name': 'rfcpool.com',
           'mine_address': 'pool.rfcpool.com:8332', 'user': rfcpool_user,
           'pass': rfcpool_pass, 'lag': False, 'LP': None,
           'api_address':'https://www.rfcpool.com/api/pool/stats', 'role':'mine'},

Code:

def rfcpool_sharesResponse(response):
    global servers
    info = json.loads(response)
    round_shares = int(info['poolstats']['round_shares'])
    servers['rfcpool']['shares'] = round_shares
    bitHopper.log_msg('rfcpool:' + FormatShares(round_shares))

Code:

'rfcpool':rfcpool_sharesResponse, 

[bb]

latest release just scrolls through empty RPC request [[]] to ozco.in.

I've validated that password.py has the right info.

I don't get what this means either, but it doesn't appear to mean that there are no shares commited.

[Rino]

Miningmainframe is up at 50ghash/s now, seems its still on prop. If it was off because of 2ghash/s speed before you may want to turn it back on.

[nob]

Miningmainframe uses Scoring and not prop:

We currently have an administration fee of 0.5% on top of the 1% (for a total of 1.5% total fees) and utilize a cheat proof scoring algorithm for calculating a fair payout of your shares.

http://mining.mainframe.nl/index

[organofcorti]

Anyone still using bclc note that the json feed now shows total shares to be 1/5 of the shares reported on the website. Tricky bugger. Change your bithopper accordingly.

[OCedHrt]

So heres a thought, anyone here consider putting together a theoretical luckbased approach ?

I know its been discussed here but I think it would still be interesting to actually do it.

Pull the last 2 or 3 blocks and see how far out of the difficulty range the avg is ie. 3blocks(just a number i like) combined gives 6million, that avg out at 2million per block so not terrible unlucky, however a different pool have their last 3 blocks at combined of 10million, thats > double avg difficulty per block thus we work a formula into the duration hopper should stay at this pool for this new block which would be the 1st block after the last 3blocks used for sample.

My rough approach would assume the following:

Right now we seem to use a 40% of diff approach, now if we use that as our base value and apply the difference of the last 3 blocks in example above we will get the following.

10million shares across 3blocks = 3333333.33 shares per block
This means the last 3 blocks lasted on avg 213% longer

We will then calculate our 40% into current difficulty which would be 625211.2 and add 213% which gives 1331699.85 difficulty thus the new difficulty for the selected pool to stay on for the 4th block(block just after the previous 3)

Now the reverse would be implied when a pool got really lucky in last 3blocks, thus we would be avoiding them or leave them far earlier than 40% of difficulty.

I hope this makes somewhat sense it does in my twisted mind.

please note: This is some hectic thumbsucking, would be nice to check it out in practice.

Hate to be the wet blanket that rains on your parade, but blocks are solved as a poisson process. Part of the definition of a poisson process is that it has no 'memory' of prior events. This means that each new block has a the same probability of being solved before <difficulty> as any other block. So a 'luck' based approach would only work randomly and increase variance. Sorry.

Now, who's going to open up another forum thread called 'Hoppers here!'. c00w must be getting sick of our meanderings, much as I enjoy them    

Indeed but the luck averages out over time:

Luck this difficulty (1563027)       1724037 shares   (-9.3%)
Luck at difficulty 1379223       1384144 shares   (-0.4%)
Luck at difficulty 876954       875473 shares   (+0.2%)

If a large pool has significantly worse luck than that you can usually suspect some foul play.

[gno]

Just to be sure-  it sounds like bitp.it has countermeasures making them unsuitable for hopping?

[anty]

Yes, bitp.it fakes stats.

BTW: anyone has an idea why I only mine at nofee until the next check and then fall back to the backuppool? They are significantly under the 40% and everytime i restart my bithopper it immediately begins mining there...

[Clipse]

Yes, bitp.it fakes stats.

BTW: anyone has an idea why I only mine at nofee until the next check and then fall back to the backuppool? They are significantly under the 40% and everytime i restart my bithopper it immediately begins mining there...

I have the same issue since recent update today(I didnt notice it till after I pulled new update) , it seems to get stuck at backup server.

[joulesbeef]

The triplemining code worked except it spaz out api errors

being a total noob, i have gotten the api errors nearly every time i have messed with the code.

10% of the time, i miss copied the api key, 90% of the time I accidently pasted over a quote.


go back and look at the changes you did and look for a missing '

[gno]

Is there anything worth hopping at the moment?

[Clipse]

The triplemining code worked except it spaz out api errors

being a total noob, i have gotten the api errors nearly every time i have messed with the code.

10% of the time, i miss copied the api key, 90% of the time I accidently pasted over a quote.


go back and look at the changes you did and look for a missing '

I fixed it by modifying alot of it, the following works with latest version of bithopper and you can clearly see why it didnt work before.

Code:

                'triplemining':{'shares': default_shares, 'name': 'triplemining.com',
                   'mine_address': 'eu.triplemining.com:8344', 'user': triplemining_user,
                   'pass': triplemining_pass, 'lag': False, 'LP': None,
                   'api_address':'https://www.triplemining.com/stats', 'role':'mine'},

Code:

    def triplemining_sharesResponse(response):
        statpage = response
        shares = re.search(r"<td>[0-9]*</td>", statpage).group(0)[4:-5]
        round_shares = int(shares)
        self.UpdateShares('triplemining', round_shares)

Code:

            'triplemining':self.triplemining_sharesResponse,

So all I can think if you dont have issue with previous code, you havnt updated bithopper today.

[Clipse]

Im still getting the follow errors, afaik only when submitting to ozcoin.

Code:

8:33:46] RPC request [[]] submitted to ozco.in
Caught, jsonrpc_call insides
'NoneType' object is not callable
Caught, jsonrpc_call insides
'NoneType' object is not callable
Caught, jsonrpc_call insides
'NoneType' object is not callable

This would appear randomly during the connection to ozcoin, on and off.

[Clipse]

mtred got a block you should be there

Yep Im at mtred now, however eventually it will hit ozcoin again and same errors appear, trying to figure out why thats occurring

[Clipse]

arg this is frustrating.

When I restart hopper it will mine at mtred as it should, however if I have one connection problem it then gets stuck at arsbitcoin backup server even tho at the rescan it shows mtred is the best option also doesnt anyone know what this json "nonetype" error is all about?

Code:

9:00:59] RPC request [[]] submitted to arsbitcoin
[19:00:59] RPC request [[]] submitted to arsbitcoin
[19:00:59] miningmainframe: 6,119,040
[19:01:00] RPC request [[]] submitted to arsbitcoin
[19:01:00] mineco: 1,313,300
[19:01:00] rfcpool: 1,253,394
[19:01:00] bclc: 307,077
[19:01:00] mtred: 132,696
[19:01:00] RPC request [[]] submitted to arsbitcoin
[19:01:00] RPC request [[]] submitted to arsbitcoin
[19:01:01] bitclockers: 1,563,953
[19:01:01] RPC request [[]] submitted to arsbitcoin
[19:01:01] ozco: 1,059,776
[19:01:02] eclipsemc: 582,859
[19:01:02] RPC request [[]] submitted to arsbitcoin
[19:01:02] RPC request [[]] submitted to arsbitcoin
[19:01:02] RPC request [[]] submitted to arsbitcoin
[19:01:02] RPC request [[]] submitted to arsbitcoin
[19:01:02] RPC request [[]] submitted to arsbitcoin
[19:01:04] RPC request [[]] submitted to arsbitcoin
[19:01:05] RPC request [[]] submitted to arsbitcoin
[19:01:05] RPC request [[]] submitted to arsbitcoin
[19:01:05] RPC request [[]] submitted to arsbitcoin
Caught, jsonrpc_call insides
'NoneType' object is not callable

[gno]

mtred got a block you should be there

Thanks-  I just looked and that's where I am.