bitHopper: Python Pool Hopper Proxy

[johnj]

I may be missing something obvious, but

I put ~400 shares into the last btcworld.de block and I was credited for 0.

Just a heads up.

Edit:  Worker shows up as active, i'm attributed with shares *during* the round, just afterwards it says 0.

[organofcorti]

Yes I know, the duration of the rounds and the founded blocks are real but they are delaying randomly the json stats...

I´m with lp_penalty:2 and is working fine

deepbit with lp_penalty:0, it´s ok?

I´m with 0.2.3-11 now...

Sorry, haven't done deepceleron's analysis yet, so not using LP_penalty, just the old penalty. I found I had much better outcomes with deepbit when using it, although that might have something to do with my threshold [0.8] and the frequency of new rounds on deepbit. Maybe just use mine_deepbit with bclc, no penalty.

[tysat]

Yes I know, the duration of the rounds and the founded blocks are real but they are delaying randomly the json stats...

I´m with lp_penalty:2 and is working fine

deepbit with lp_penalty:0, it´s ok?

I´m with 0.2.3-11 now...

Sorry, haven't done deepceleron's analysis yet, so not using LP_penalty, just the old penalty. I found I had much better outcomes with deepbit when using it, although that might have something to do with my threshold [0.8] and the frequency of new rounds on deepbit. Maybe just use mine_deepbit with bclc, no penalty.

I'm curious how you're getting your hopper to go to deepbit.  Mine never seems to want to as when i use --p2pLP I think the IRC connection ends up dying after 20-30 minutes (don't get any votes after that time), and without --p2pLP it rarely decides it's time to go to deepbit.

[organofcorti]

Yes I know, the duration of the rounds and the founded blocks are real but they are delaying randomly the json stats...

I´m with lp_penalty:2 and is working fine

deepbit with lp_penalty:0, it´s ok?

I´m with 0.2.3-11 now...

Sorry, haven't done deepceleron's analysis yet, so not using LP_penalty, just the old penalty. I found I had much better outcomes with deepbit when using it, although that might have something to do with my threshold [0.8] and the frequency of new rounds on deepbit. Maybe just use mine_deepbit with bclc, no penalty.

I'm curious how you're getting your hopper to go to deepbit.  Mine never seems to want to as when i use --p2pLP I think the IRC connection ends up dying after 20-30 minutes (don't get any votes after that time), and without --p2pLP it rarely decides it's time to go to deepbit.

Sorry, can't help you. For me bH actually went to deepbit more than I wanted, so I put a penalty in to have a hop point lower than my usual to maximise efficiency and reduce overall shares. On the other hand I never get btcguild. I think it has to do with deepceleron's explanation a few pages back, on how long it takes an LP to get to you which will vary between miners but seems pretty consistent for a particular miner. This is why LP_penalty and an analysis of LP delays by pool might be useful.

[Technocrat]

I may be missing something obvious, but

I put ~400 shares into the last btcworld.de block and I was credited for 0.

Just a heads up.

Edit:  Worker shows up as active, i'm attributed with shares *during* the round, just afterwards it says 0.

The same thing happened to me. I mined over 10,000 shares over the last two completed blocks there and received nothing.
My balance still says zero. Their stats are messed up too. Every language gives a different total share number.
Probably best to stay away from this pool.

[lucita777]

I think their balance it just heavily delayed, as they wait for enough confirmations. My balance just got updated and the number does make some sense.

[MrWizard]

I think their balance it just heavily delayed, as they wait for enough confirmations. My balance just got updated and the number does make some sense.

True.  My balance went from zero to positive only after 120 confirmations.  They do not show a pending balance, just an estimate (current working block) and confirmed balance.

And yes, each language status page shows a different current block count.  The default page, the one bH reads, lags the most.   

[johnj]

Okay, yep, btcworld.de has my balance updated.  Whew.

[r2edu]

Not a good hopping days for me...
DB mines 2/3/4 blocks every 2/5/10 rounds, lots of shares goes to bclc (now disable), mtred is down or are banning ip´s, i can´t see the stats or the webpage...
I don´t see anymore votes in bh console, "mine_slush" misses various short rounds...

I think i´m going back to 0.2.1, I don´t remember what version gives me better results 

[Starlightbreaker]

mtred works fine.

[tysat]

Mt Red is working great, the past 24 hours have been pretty lucky for them.

[r2edu]

Not for me... I´m from Argentina and is not the first time they ban some ip ranges, really don´t know why :/

[spectra]

I've been testing a somewhat old version from github (77c462709129376c2f259561d4e9af25c4e38303). The only thing I grab from more recent versions is pools.cfg. I got 47% of the block owner guesses correct... This seems kind of disappointing, but in fact it's much better than pident score accuracy (34%) which seems to be the method to be beaten.

I don't know if people are saving stats, but are newer versions any better? If yes, with or without p2p turned on?

[Jezzz]

Anyone have a good spreadsheet for organizing income from all these pools?

[toliman]

just a bit of a blank ended question, and i've only read 1/10 of the thread, because, 6 hours time to read one thread ... (sigh.)

do any of the schedulers allow load-balanced/parallel pool usage ?

i.e. 2 pool types interleaved so that while you might be on mine_slush and their rotations/slice priorities, it will also interleave another thread with a mine_charity or mine_deepbit thread ?
it would probably be easier to work with the pool categories in parallel, so that each connected miner, would be handling various packets, and shared pools at the same time. it does complicate the proxy nature of bH, but this would work if each share were equal in payload or there were metrics to use on each share/packet. it would possibly require a more advanced metric measurement of the size/difficulty of the work, as well as a few metrics for the minimum rate for each pool type, and a way to rate-limit work.

The more i think about it, the less it seems practical, except in the cases where you want to maintain goodwill with pool operators by contributing 1 out of every 4 shares, instead of 1 out of every 100 or 500 shares, or limit it down to 1 : 10, etc.

it would also reduce the 'surge' phenomenon, where combined rates halve or decimate once the minimum share dividend has been reached, it also allows for acceleration and deceleration over time for PPS/Proportional 'surges' where a new block will reset the current shares. on the flipside, if aggressive pools implemented duration-based timeouts or a last-man-standing proportional system, to prevent surges, which is not as difficult to implement as a routing metric, this approach would be designed to stop that kind of ban taking place, as long as enough shares were being sent to keep that 'window' open.

without a real metric routing protocol, modifying an existing scheduler could probably do this on a 1:10 share basis, maintaining a minimum work rate of say, 80mh/s on one, or two "non-hoppable" pools and still continue with the PPS/Prop/last-man-standing pool hopping to maintain a shared dividend.

or is this idea just silly for reasons i can't fathom, namely that routing metrics are ridiculously difficult and complicate things ?

[Rino]

i am getting this in current version:

Code:

Traceback (most recent call last):
  File "D:\_Soft\_Bitcoin\bitHopper\lp.py", line 124, in receive
    response = json.loads(body)
  File "C:\Python27\lib\json\__init__.py", line 326, in loads
    return _default_decoder.decode(s)
  File "C:\Python27\lib\json\decoder.py", line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "C:\Python27\lib\json\decoder.py", line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

[organofcorti]

Can anyone mining coinotron send me your stats for a few rounds. I'll need the payout, your shares, total shares, your average hashrate while connected and the score (if they publish that somewhere) so I can work out the the 'magic number' in the score system.

tia

[paraipan]

just a bit of a blank ended question, and i've only read 1/10 of the thread, because, 6 hours time to read one thread ... (sigh.)

...
or is this idea just silly for reasons i can't fathom, namely that routing metrics are ridiculously difficult and complicate things ?

hehe, toliman your question is not "blank ended" at all but it's been put repeatedly over the thread. You should take the entire reading of it like a second job or something similar if you want to assimilate all the info
You can read the bH "readme" and other included files to realize that this king of mining has already been implemented in various flavors too, time based and share based, even if it seems difficult at first.
Try joining our irc chan to get more info on whatever you like, we're trying desperately to keep the posting to this thread to a minimum because of the high page count

[organofcorti]

Can anyone mining coinotron send me your stats for a few rounds. I'll need the payout, your shares, total shares, your average hashrate while connected and the score (if they publish that somewhere) so I can work out the the 'magic number' in the score system.

tia

Coinotron is a Prop. pool.  No score system utilized.

from the coinotron thread

Coinotron advantages:
-  security is our priority, users passwords are hashed and salted
-  we are startup pool, so odds of DDOS attack are at this moment slight 
-  anti-cheating score system punishing pool-hooping cheaters
-  long poll support ( mining efficiency raises about 2% )
-  on demand payouts
-  automatic payouts

and from later on, same thread

Here you have exact formula :

Share Score = exp ( C * time span from beginning of the round to share delivery time / round duration )

Payout = 50 * sum( miner’s share scores ) / sum( all miners share scores )

For C = 0 we have Share Score = 1 for each delivered share i.e system is proportional.
When we raise C value, system becomes similar to Slush’s method. Most precious are shares delivered at the end of the round.

Currently we use C = 0 – pool is small, round duration is measured in days.
But when we observe increase of pool-hoopers activity we will set this value to about 6.

It's an interesting score system, slightly different to slush and I'd like to see how it works.

[MrWizard]

My bad.  Thanks for the update.  I had a bad experience there so I lost interest in what they are up to.