bitHopper: Python Pool Hopper Proxy

[RevolutionMaster]

Anyone else getting an error where BitHopper stops after a period of time?

It just gets stuck...

[14:16:38] writing to database
[14:17:38] writing to database
[14:18:38] writing to database
[14:19:38] writing to database
[14:20:38] writing to database
[14:21:38] writing to database
[14:22:38] writing to database
[14:23:38] writing to database

[1713918638]

1713918638

[1713918638]

1713918638

[1713918638]

1713918638

[1713918638]

1713918638

[1713918638]

1713918638

[1713918638]

1713918638

[r2edu]

mines always stuck after an "LP Call" to btcserv... 0.2.2.4-68

now I will try with 0.2.2.4-83

[norulezapply]

Anyone else getting an error where BitHopper stops after a period of time?

It just gets stuck...

[14:16:38] writing to database
[14:17:38] writing to database
[14:18:38] writing to database
[14:19:38] writing to database
[14:20:38] writing to database
[14:21:38] writing to database
[14:22:38] writing to database
[14:23:38] writing to database

+1 for this since i got the latest version

EDIT: this still isn't fixed in the latest version... just a heads up.

I get an LP call then constant "writing to database" messages.
renders my miner useless until i restart bithopper
occurs every 30 minutes approximately for me.

[Atroxes]

Regarding this issue: https://github.com/c00w/bitHopper/issues/177#issue_comment_form

Manual triggers for mine_deepbit pools

If a feature like this was added, being also able to execute this function through win/*nix commandline, would allow for extremely easy writing of tcl/mirc scripts that could catch blockannounces in certain IRC channels and do manual triggers. This would effectively enable hopping on pools like deepbit, btcguild etc.

[user7516]

  OMG, look at slush's block #7543:
http://img269.imageshack.us/img269/9049/clipboardimage1.png

[lucita777]

OMG, look at slush's block #7543:
http://img269.imageshack.us/img269/9049/clipboardimage1.png

Lots of BTC for anyone who was able to squeeze a share in. To bad I didn't  

[organofcorti]

@deepceleron: how are you getting on with LP penalty - Did you end up with a significant increase in accuracy?

[Sukrim]

I still have a problem with p2pLP - My router seems to drop connections (like LP connections...) quite fast, so I rarely actually get Longpolls. I hoped p2pLP would still notify me of found blocks (didn't yet look deeply into the code to find out what's going on) but this doesn't seem to be the case.

Would it be possible to just set up an IRC bot that announces each block on the network and the (either confirmed or guessed) pool that owns it for people like me? The input could still come from bitHopper users via this ranking mechanism or whatever you actually use...

[deepceleron]

@deepceleron: how are you getting on with LP penalty - Did you end up with a significant increase in accuracy?

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.

[organofcorti]

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?

[organofcorti]

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.

[Sukrim]

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!

[deepceleron]

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?

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.

[deepceleron]

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.

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.

[lucita777]

Anyone else getting an error where BitHopper stops after a period of time?

It just gets stuck...

[14:16:38] writing to database
[14:17:38] writing to database
[14:18:38] writing to database
[14:19:38] writing to database
[14:20:38] writing to database
[14:21:38] writing to database
[14:22:38] writing to database
[14:23:38] writing to database

+1 for this since i got the latest version

EDIT: this still isn't fixed in the latest version... just a heads up.

I get an LP call then constant "writing to database" messages.
renders my miner useless until i restart bithopper
occurs every 30 minutes approximately for me.

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

Code:

@echo off
set DELAY=1800
set PYTHON_IM=python.exe
set PYTHON_PATH=c:\Python27\python.exe
set BH_PATH=d:\c00w-bitHopper\bitHopper.py

:loop
echo Restarting BitHopper....
taskkill /T /IM %PYTHON_IM%
start %PYTHON_PATH% %BH_PATH%
echo Waiting %DELAY% sec...
ping 127.0.0.1 -n %DELAY% >nul
goto :loop

[Atroxes]

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

[r2edu]

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"?

[johnj]

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

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)

[organofcorti]

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

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)

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

[r2edu]

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