bitHopper: Python Pool Hopper Proxy - page 180.

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

Quote

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

Nope and considering that cow said

Quote

I did no work this weekend. So the same as friday.

that earlier I did not expect to update.

Thanks for the the fixes though as I plan to update.

muyoso

member

Activity: 84

Merit: 10

Quote from: ?? on ??

SOOOOOOOOOOOOOOOOO multipoll hopper still can work on bitcoins.lc Grin

Multipoll hopper? How does it work when bitcoins.lc is apparently setting their shares to a static number of 126,183?

zybron

member

Activity: 66

Merit: 10

Quote from: Clipse on July 18, 2011, 01:57:50 PM

And yet some more errors

Code:

[19:56:22] RPC request [[]] submitted to mtred
[19:56:23] LP triggered from server mtred
[19:56:23] Reading LP Response failed

I dont see anyone else reporting in here similar errors yet I find it hard to believe that I am the only one getting these.

Did you all update to the latest git version ?

I'm running the latest GIT version but not seeing anything like that. Maybe you're having connection issues?

muyoso

member

Activity: 84

Merit: 10

Quote from: ?? on ??

Quote from: muyoso on July 18, 2011, 01:52:53 PM

I am sorry to you guys who disabled bitcoins.lc. I got in on 4 blocks this morning already.

Edit: Make that 5 blocks.

really or that are faked stats ?

Quote

296    136898    532 540    540 340    18 Jul 16:15:20    1 h 17m
295    136888    1 120 599    1 130 838    18 Jul 14:57:53    2h 40m
294    136877    2 646 739    2 682 072    18 Jul 12:17:49    6h 59m
293    136840    4 905 846    4 995 134    18 Jul 05:18:46    14h 5m
292    136739    75 365    77 056    17 Jul 15:13:33    13m 29s
291    136737    3 133 727    3 299 934    17 Jul 15:00:04    12h 42m

Actually looks like 4 blocks. I think they just set the shares in their API to 126,183 so that is why I thought it was a new block. Did get payment on 4 blocks though. Damnit, have to re-disable bitcoins.lc until they stop playing games with the shares.

Absolutely need to implement something that stops mining at a pool when their shares remain static from one poll to another. I have been really lucky and caught btcguild, bitp.it and not bitcoins.lc within minutes of them setting static share counts, but I won't always be able to catch it.

Clipse

hero member

Activity: 504

Merit: 502

And yet some more errors

Code:

[19:56:22] RPC request [[]] submitted to mtred
[19:56:23] LP triggered from server mtred
[19:56:23] Reading LP Response failed

I dont see anyone else reporting in here similar errors yet I find it hard to believe that I am the only one getting these.

Did you all update to the latest git version ?

muyoso

member

Activity: 84

Merit: 10

I am sorry to you guys who disabled bitcoins.lc. I got in on 4 blocks this morning already.

Edit: Make that 5 blocks.

gno

newbie

Activity: 28

Merit: 0

Quote from: bb on July 18, 2011, 01:28:50 PM

Code:

[19:26:47] RPC request [[]] submitted to mtred
Error in json decoding, Server probably down

[19:26:47] Server change to arsbitcoin, telling client with LP
[19:26:47] LP Call arsbitcoin.com:8344/LP
[19:26:47] RPC request [[]] submitted to arsbitcoin

I can't submit to mtred. Anybody else?

I'm getting the "error in json decoding" but it appears I'm submitting shares to mtred

bb

member

Activity: 84

Merit: 10

Code:

[19:26:47] RPC request [[]] submitted to mtred
Error in json decoding, Server probably down

[19:26:47] Server change to arsbitcoin, telling client with LP
[19:26:47] LP Call arsbitcoin.com:8344/LP
[19:26:47] RPC request [[]] submitted to arsbitcoin

I can't submit to mtred. Anybody else?

gno

newbie

Activity: 28

Merit: 0

Quote from: ?? on ??

mtred got a block you should be there

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

Clipse

hero member

Activity: 504

Merit: 502

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

Clipse

hero member

Activity: 504

Merit: 502

Quote from: ?? on ??

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

hero member

Activity: 504

Merit: 502

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

hero member

Activity: 504

Merit: 502

Quote from: joulesbeef on July 18, 2011, 12:04:55 PM

Quote

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"[0-9]*", 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.

gno

newbie

Activity: 28

Merit: 0

Is there anything worth hopping at the moment?

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

Quote

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 '

Clipse

hero member

Activity: 504

Merit: 502

Quote from: anty on July 18, 2011, 11:29:44 AM

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.

anty

newbie

Activity: 40

Merit: 0

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...

gno

newbie

Activity: 28

Merit: 0

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

OCedHrt

member

Activity: 111

Merit: 10

Quote from: organofcorti on July 18, 2011, 07:36:52 AM

Quote from: Clipse on July 18, 2011, 07:22:10 AM

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 Wink

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, Wink

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 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 Grin

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.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

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.

Topic: bitHopper: Python Pool Hopper Proxy - page 180. (Read 355689 times)