Quote
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
Topic: bitHopper: Python Pool Hopper Proxy - page 181. (Read 355816 times)
Miningmainframe uses Scoring and not prop:
http://mining.mainframe.nl/index
http://mining.mainframe.nl/index
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.
latest release just scrolls through empty RPC request [[]] to ozco.in.
I've validated that password.py has the right info.
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.
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,
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.
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.
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.
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.
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.
It was more a case of curiosity than anything.
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.
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 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
Mmm just started to get a ton of this.
Dude, you are having a crappy night! Hope you get it sorted. Maybe for the time being you should revert back to an earlier git clone that worked for you?
Those json errors only happen with eligius , bithopper or slice bithopper version. I wonder if they somehow banned my IP from connecting to their pool.
Anyhow no biggy, just removed them and its gone
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.
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.
Mmm just started to get a ton of this.
Dude, you are having a crappy night! Hope you get it sorted. Maybe for the time being you should revert back to an earlier git clone that worked for you?
On a different but related note, anyone tell me how to parse the following simple but nested json feed? looking for 'round_shares' doesn't work.
Here's the line you'll need:Code:
{"poolstats":{"hashrate_unit":"GH/s","hashrate":25.02,"workers":81,"round_time_unit":"seconds","round_time":177163,"round_shares":1120942}}Code:
round_shares = int(info['poolstats']['round_shares'])
Thank mate!
Mmm just started to get a ton of this.
This seems to happen when connecting to eligius and not ozcoin.
Code:
12:53:38] OK NOT slicing because of arsbitcoin
[12:53:38] reslice 1: -1 677034 677034
[12:53:38] reslice 1: 63.9894742825 1094840.21559 1094840.21559
[12:53:38] OK NOT slicing because of eligius
[12:53:38] reslice 1: 183.360485614 730747 730307
[12:53:38] OK NOT slicing because of triplemining
[12:53:38] reslice 1: 95.5366532248 938434.470503 938434.470503
[12:53:38] OK NOT slicing because of multiclone
[12:53:38] reslice 1: -1 5977429 5977429
[12:53:38] reslice 1: -1 1295915 1295915
[12:53:38] reslice 1: -1 2939783 2939783
[12:53:38] reslice 1: -1 0 0
[12:53:38] slicing False
Caught, jsonrpc_call insides
Connection was refused by other side: 111: Connection refused.
Caught, jsonrpc_call insides
Connection was refused by other side: 111: Connection refused.
Caught, jsonrpc_call insides
Connection was refused by other side: 111: Connection refused.
Caught, jsonrpc_call insides
Connection was refused by other side: 111: Connection refused.
Caught, jsonrpc_call insides
Connection was refused by other side: 111: Connection refused.
Caught, jsonrpc_call insides
Connection was refused by other side: 111: Connection refused.
Caught, jsonrpc_call insides
Connection was refused by other side: 111: Connection refused.
This seems to happen when connecting to eligius and not ozcoin.
Wow, this really feels like we're on a war footing.
The difference being that every strategy session from the PoolHopper side of the war takes place in a public forum. A public forum that is likely monitored by the PoolOperator side of the war.
I dunno. The whole point is to be open and help the pool operators 'hop' to a better system. We're aiming to put ourselves out of business! By not hopping on a prop pool, miners are cheating themselves.
Wow, this really feels like we're on a war footing.
The difference being that every strategy session from the PoolHopper side of the war takes place in a public forum. A public forum that is likely monitored by the PoolOperator side of the war.
Would be handy for some counter measures, I think its good idea that pools change but we are helping them way to much without them having to do much work right now
On a different but related note, anyone tell me how to parse the following simple but nested json feed? looking for 'round_shares' doesn't work.
Here's the line you'll need:Code:
{"poolstats":{"hashrate_unit":"GH/s","hashrate":25.02,"workers":81,"round_time_unit":"seconds","round_time":177163,"round_shares":1120942}}Code:
round_shares = int(info['poolstats']['round_shares'])
Sorry that didn't help. I have no idea what I did differently this time, but it's working with c00w's bithopper. Previously I got the same error as you.
On a different but related note, anyone tell me how to parse the following simple but nested json feed? looking for 'round_shares' doesn't work.
On a different but related note, anyone tell me how to parse the following simple but nested json feed? looking for 'round_shares' doesn't work.
Code:
{"poolstats":{"hashrate_unit":"GH/s","hashrate":25.02,"workers":81,"round_time_unit":"seconds","round_time":177163,"round_shares":1120942}}Weird yeh, seems to work with slice bithopper version, I double checked and compared with default bithopper version and except for removing sliced parts it checked out.
Anyhow, im test running sliced version now.
Btw, any reason bitpit is still enabled to mine with the slice bithopper version?
Sorry that didn't help. I have no idea what I did differently this time, but it's working with c00w's bithopper. Previously I got the same error as you.
On a different but related note, anyone tell me how to parse the following simple but nested json feed? looking for 'round_shares' doesn't work.
On a different but related note, anyone tell me how to parse the following simple but nested json feed? looking for 'round_shares' doesn't work.
Code:
{"poolstats":{"hashrate_unit":"GH/s","hashrate":25.02,"workers":81,"round_time_unit":"seconds","round_time":177163,"round_shares":1120942}}
yeh I did remove the slice part since first tried with default c00w bithopper.
Will try now as is with slice bithopper.
Will try now as is with slice bithopper.
ok seems to be working for me. Thanks again Sukrim!
OK, Clipse, if you are going to use the code as given with c00w's bitHopper, you'll need to remove thefrom the code.
OK, Clipse, if you are going to use the code as given with c00w's bitHopper, you'll need to remove the
Code:
'slice':-1, 'slicedShares':0,
Jump to: