I have seen several instances with miners being stuck with the work queue empty.  I'm guessing LP must be getting stuck, and not returning data, but I don't know yet.  Looking into it, but takes a while for the behavior to exhibit itself, so debugging is a bitch.  Anyone have an idea of a fix?

I will acknowledge it is a shit load more work - that's what makes it more fun.  I actually pride myself on being able to take in new information and change my stance.  I never understood the concept of make up your mind, and stick to it no matter what.  It's that kind of crack thinking that got us into 2 wars

Is your auto payout not working?  I have it set to payout every .1 BTC, and I have .9 BTC and no payout

a few things:
1) In my mind, it is unethical, but a hell of a lot more fun
2) The majority see no problem with it
3) I was shocked to learn some pools actually like hoppers, and so be it
4) I like money

ok, I feel confident enough to leave it unattended for the night.  0 stales on ozco in the last 20 minutes

You know you are watching your stats screen too closely when you start seeing these:

[00:26:02] RPC request [dead1000] submitted to BTC World

Of course, right after I move it over to a screen session, I get this:

Last 15 Mins    1158    21    1.813%

21 stales, and on the stats page I see 9257 / 0

This is unfortunate, there might be an issue with stales not getting reported.  I think the store is working though, rfc sucks, so it isn't a good test

kick ass, is that one of your features?  I just keep becoming more and more of a fan of this proxy

Good idea...  I think I can take this as confirmation (rfc):
Last 15 Mins    1359    0    0.000%

I can't believe this gets less stales than phoenix by itself. 

But we hold the entire merkle root in string format (64 characters).  Assuming a 2 byte encoding, we are looking at 128 bytes per merkle root.  I would estimate I am averaging 3 getworks / s so 3*60*5 = 900.  900 * 128 = 115,200 BYTES...  I see my error in caclulations: I was thinking in kilobytes, duh computers are hard.

I think that is just rfc being rfc.  There is a lot of lag on their server.  The important thing is you don't get stales when you hop to and away from it

Holy carp on a stick.  I'm up to 11,000 shares / 0 stales.  I'm actually a little worried about the lack of stales.  Plus, I have to stop it and move it over to a screen session, and I really don't want to interrupt this run

What is really amazing, and I don't understand how this is possible, I have the exact same memory usage with update and I did before.  The new object should be pretty large

Did you include the mine_friendly role?


9000 shares, 0 stales for me, and that is with getting a lot of lagging out of rfc and switching servers.  I'm impressed, but I haven't tried your version yet

It was a fair assumption by the rules of encapsulation. 

That is a good offset to my 5500 shares / 0 stales 

Isn't critical mass bad?

??  My pruning function was working when I committed it

Edit: I see what you did, I put the LoopingCall in bitHopper.main() to keep it consistent

Edit Edit: Yup, you have 2 LoopingCalls

c00w: I just saw you have user data in the data site.  What are the number representative of, and over what period?



4500 / 0

Did you get it working?  I made some changes to flow, but I know you made your own fixes, so I don't know how similar our code bases are

2700 shares / 0 stales.  I would say I'll actually MISS them...

Edit: 3300 shares / 0 stales.  I'm digging this