Topic: bitHopper: Python Pool Hopper Proxy - page 32. (Read 355813 times)

Oh and if you want to integrate all the info on nmc etc... into the difficulty module including prices that would be awesome. There already is nmc difficulty and adding everything else should be pretty quick.

Do you think the current value is really the best one? I'd rather use the 24h average from http://www.nmcwatch.com/...

"average: ([\.0-9]+).*
" should work I think... Unfortunately (for them) there isn't any API advertised.

Default scheduler. 

I'll see if I can find the time this weekend to give it a shot. The big hurdle is that, to my knowledge neither of the bitparking exchanges has an API available, and I'm not exactly a regex master.

If anyone knows of such an API or happens to have some already-existing regex to get the current NMC value I'd be forever in your debt. 

@Muyoso
Reducing the number of getworks?
We are working on it. Also issues with scheduling are confusing and I need to rewrite the whole scheduler system. Which scheduler are you using?

@enmaku
Its not very hard. Someone just has to code it.

So all this craziness with IXCoin recently has me thinking... How hard would it be to code in some checks to automatically compare the profitability of BTC, NMC etc. to automatically make the switch for the brief span in which NMC mining is more profitable? Once difficulty settles down on IXC we could do the same for them (easy enough since bitparking runs both the NMC and IXC exchanges). We could hack together the logic and just have the appropriate bitparking pool represented as some arbitrary low percent when it's more profitable and use the standard 10^10 when it's not, all configurable of course.

Anyone know how hard it would be to do this?

I see bitclockers is better than before but still far from perfect.  Is there anyway to just reduce the getwork requests?  I'm ignorant as to why cherrypicker for example hops it flawlessly with a normal number of getwork requests and bithopper doesn't.

Also, when Slush finds a block why isn't BH switching to it?  It just keeps mining at deepbit. 

startup parameter

--threshold=

1 = 100%
.90 = 90%
.43 = 43% (default)

With "mine_deepbit" when do we jump away from a pool?  I think bithopper is staying longer than 43%, which should be around 10 minutes right?  It almost feels like I am mining deepbit until 100% of difficulty.

How do you set threshold with 1.6.1?

i dont have enough time to maintain that site properly.

but (as i said way earlier) if some people would like to help me i could get them access to some of the openvz instances which do the stats grabbing.

Ok, after a bunch of testing it appears the problem (for me at least) is that bitHopper simply doesn't pick up Deepbit announces at all.   I disabled every pool aside from Deepbit and BitHasher (bit hasher was the currently active pool) and watched the console, IRC, and also another users config he kindly gave me the URL to.

The announce came through in IRC for deep, the other users config switch to it, but there was no mention of a new block at all in my bitHopper console.

Stats working for bitcoins.lc using mine_deepbit for anyone else?  Been messed up for hours for me.

Also repeatedly getting this error:


Also Polmine is just showing 100% and difficulty number of shares static with "mine_deepbit". 

@magnet
Did you get any errors on the bithopper side?

@simonk
I don't have enough access to my test machine to figure out the real issues. But it appears that it doesn't work for me.

Nope.. leave it at default "1" (0.43)

-perhaps in some screen I posted was 0.87 (50%) but those were some tests with "mine_deepbit" or when there´s nothing to hop to-

Edit: when i take that screen i was with 0.1.6.1-20 or -18, but with the pools.cfg edited pretty sure

have you set penalty (and how much)?

I looked around a bit for IRC support in Python, but the main problem I see there is that it might be hard to make sure only "good" clients get in there and a channel can't be taken over.

About reputation:
I would just normalize over all clients and cut the reputation in half for every wrong submission. Setting it back to 0 seems to work even better though - but I simulated with random data, so you couldn't predict future values. Here you can say that clients that work reliably deserve a higher reputation, even if they have a hickup from time to time.

All in all it seems like a very good idea to have, it would just create a dependency on a Python IRC library (quick google search: e.g. http://python-irclib.sourceforge.net/). If we somehow could even coordinate to announce every block found there, all BitHopper would need to do is to join + lurk there and get the list of the last let's say 50 blocks per pool, calculate an average hash rate from this and then estimate share counts. No API needed in any pool!

Yes, currently API scraping is easier + more exact, but this could be used to already get used to more repressive counter measures. As little as I understood from Polmine they also seem to consider just delaying stats instead of using a secure payout method.

Edit:
Seems that IRC is even easier, no external library required: http://www.devshed.com/c/a/Python/Python-and-IRC/

Don´t know why but "mine_deepbit" is working amazing with Polmine, but not with deepbit.. once it mines a block the shares keep counting and counting, and when i disable it for a while and re-enable it, when find the start of a round the workers doesn´t start..

With BCLC, i edit the new pools.cfg with the "old" one (with the json method) and just "mine" and give me good results:



(I´am with the newest version 0.1.6.1-24 & 1Gh/s)

Edit: I think when I send more shares the rounds was very large, and when I send a few is because BH was hopping between pools

I have about 300 ping with btcguild and almost never does it hit for me there

Dead on so far for bclc for me.
gets 80% of the blocks for deepbit for me.

I hit btcguild once in the past 2 days....they have found  a few blocks in that time.


I suppose ti could just disable them and just doo deepbit, but figured I would offer in my data point as well.


edit: still might need some work.. at my other box across town, it seems to hop more often to bclc when I am hopping to deepbit

Still zero deepbit joy here.   Did we determine it's ping related (as I have a 360ms ping to them, so other LP's get picked up before the DB one)?    I assume you're still having the same problem c00w?

Tried the latest versions of bitHopper but they gave me the same issue: problems with (serious) dropping of hashrate / rpc time-out messages in poclbm

Now back to tuesday version and running stable.