Topic: bitHopper: Python Pool Hopper Proxy - page 15. (Read 355811 times)

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

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.   

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.

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.

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.

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

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

No, they're not faking just delaying now. Try mining on mine_deepbit with penalty 2.

Last I read in the pools.info, BCLC fakes their api stats.  If you want to hop them, you gotta do it manually (ie, keep up with their stat page)

I´m with the latest (0.2.2.4-95) and I´m getting some troubles:

BH keeps jumping to BCLC as they start a round, tonight was basically the only pool were it mines, and they have a round of 17hs !!

In some previous version (i can´t remember wich one), in DB i was making 0.3 $B/24hs, now i´m doing 0.08

I think BCLC is getting all the work that belongs to DB...

I don´t change any "lp_penalty" value, in fact i got it # for a few days and use the same user.cfg in all versions, so the question is: could it be a "random" behavior.. i mean that some days some pools announce blocks earlier than others and some days don´t?

In this case do i have to lp_penalty BCLC? by how much, 1, 0.1, 10?

And the last one, is necessary to set lp_penalty to all pools or only that ones set it at "mine_deepbit"?

For some reason, with --p2pLP enabled, the pool that gets voted, doesn't reset round share count for me. Is this normal?

+1

occurs on BH 0.2.2.4-68.

As a workaround I wrote a very simple windows console script which restarts the BH about every 30 minutes. It assumes that there is only a single python.exe process running and that it is a BH.

Making realistic data for a dozen pools for each block with valid getwork timestamps is a higher barrier to entry than the current attack, which would be simply sending "Best Guess: {bitclockers} with 1 of 1 votes" over 9000 times. It's open source, so unless you want to only accept signed messages from a public key list of known-good users, there is always an attack.

If you want extreme time logging that is easier to process, replace instances of

print time.strftime("[%H:%M:%S] ")

in bithopper.py with:

print str(time.clock()) + ": "

Then you get:

258.662399982: LP Call http://ozco.in:8332/LP
260.253839675: LP Call http://eu1.triplemining.com:8344/LP
261.29642532: LP Call http://pool.bitclockers.com:8332/LP

or you can save to a log file if the message is "LP Call", etc.

If everyone publishes just raw data, it might be hard to eliminate fakers effectively... Maybe have it as an option + ask for/publish specific data only from the top 10(?) pool guessers.

If pools delay longpolls (they are already on a relatively long random delay), this would directly hurt their miners. Just delaying it for (potential) pool hoppers also won't work, as you can always easily fake a 24/7 CPU miner.

Also most pool operators seem to not be able to modify bitcoind on their own at all, if you just take a look at transaction policies or the lack of these... ironically the only one definitely able to really hack bitcoind seems to be a bit of a religious nutjob, including payers in the blockchain and flaming/preaching away on IRC!

For those of you who cant get to Hoppersden to read the "How to hop slush" post, if you want to play with the simulator yourself, it's posted here:

https://github.com/organofcorti/byteHopper-s

It requires you to have latest R installed, and editable variables are only accessible from the code. It's also not very well commented, sorry. On the other hand it's small enough and simple enough that you should be able to follow it.

Thanks for that - I just wanted to make sure you hadn't gotten any new results that invalidated your post. I was planning on trying out LP penalty and wanted to make sure you were still seeing a significant improvement since it seems like a lot of work to do.

Edit: let me clarify - I wanted to make sure that you still thought any analysis of LP arrival times was useful.

I'll try and write a script to do a daily summary from the console output - think that daily Lp penalty would be granular enough?

I kinda gave up on it for a while. As you saw from my post like five pages back, I put in the delays to the results I had already gotten and analyzed that. The conclusion was that even after inputting (or auto-learning) and even hand-tuning the average delay for each pool, the current 'first pool wins' method is suboptimal. A better algorithm, that in my limited sample gave no false positives, is to take the average delay of all pools after correction, and then analyze each pool against this average to determine if one stands out above the standard deviation expected if no polled pools were the finding pool. This improves results, since you aren't merely comparing the winning pool against the second-fastest, you are averaging out the LP delay capriciousness of your baseline over 15 pools.

Secondly, I propose a better p2p-IRC result sharing format, where all pool new block LP receive times (and the getwork timestamp) are published raw to IRC by each miner, perhaps after gathering LPs for a 10 second period after the first response. This would be better than the current "I think this pool won" publishing method, as then similar averaging can be done by the bithopper software independently, but with everybody's data, which, if we continue with the premise that the block-finding pool responds faster, should make identification clear.

This also will only last as long as pools don't take countermeasures, such as modifying bitcoind to randomly delay the RPC change to a new block if the local bitcoin found it, or by simply disabling long polling, like slush's pool.

As I would have to learn python, some database libs, and the current codebase before making improvements (and since improving hopping software was labeled as equivalent to "making poison gas for the Nazis" by hoppers themselves), I will leave it to someone else to implement this.