i think doing this publicity is the only way to go.
i dont want that only some people can hop.

everybody or nobody. (ok everybody means nobody too, as if everybody would do it ALL prop pools will die shortly)

so my goal ist: make the best hopper available. and publish it.
then prop-pools have two choices: still try to counter it (which will get them an endless story - they can't really win. at least the pool's isp or the pool owner itself always has the possibility to hop] or just go with another payout system)

i also do think we need more configuration options (eg port). i just didn't do it, because i want to merge easily with c00w's new versions (you know... he is really fast; my old versions couldn't never catch him up)

soo it's late (germany)... will come back tomorror evening.
enjoy your hopping :

ozcoin has a 15min stats update-delay and sometimes an unstable api.
thats why i thought about 30min.

EDIT: btw: suggestions are welcome
EDIT: regarding github: i want to wait for c00w. maybe we can combine our "trees". i dont like the idea of multiple versions. one version which is configurable - that should be enough

 

no it's confirmed

bitp.it is faking stats. so it stays at 438035 - which is "better" than ozcoin 581449

just implementing a feature to automatic disable pools which didnt changed their round_shares in a 30minute frame.

btw: bitp.it is currently thinking about a new payout system. maybe just kick them out.

my patched hopper evenly splits my shares between them atm

Edit: (Thank you bitpit for good sample data for two pools next to each other. now i need a pool at 40% and all others at 60% - ok i think i just have to do the math myelf

sorry
i am running it at port 80
you can change it in bithopper.py at the very end)

that was the main reason i use a proxy: i wanted to be able to mine from work

in case of dynamic ips we could just use hubs near to the pools (near means: known to be connected to that pool)

social engineering times begin

but i don't believe that: from a pool's point of view it is important to spread new blocks as fast as possible - to reduce invalids.

btw: does bitp.it fakes it stats?
second time today that my hopper reports > 70%/diff and then immediatly goes down to 28%

unconfirmed reward did not change. so did they even found a block?

as long as their blocks have a fixed delay from a pre known node it shouldn't be a problem.

i don't know if the pool operators could live with only 50 nodes. as far as i know their goal is to spread new blocks as fast and wide as possible (this counts especially for btcguild as elu pays for invalid blocks and looses money if he has an high invalid rate)

i just try.
i will publish my experience to everyony.

my goal is not to pool hop my self. i want to stop it in the long term. but if we want to stop it we have to understand it completely.

i don't like the idea, that a few "high-minded" people are able to cheat the rest.

everybody could cheat; or nobody: thats what i am trying to archive

i think we need to be that hub itself.
because if the hub announces the new block it wouldn't tell us where it get it from.

but: the long way to go is with a central server like fasthopper.appspot.
^^ the only question is how good that service would/could be

please recheck pool.py

there are entries missing. my new keys: slice and slicedShares (or sth like that)

if it were ms i KNOW it will work
i just have to include ping times...

you take the risk of getting banned.
its VERY easy for pool operators to caught a hopper if he stays for more- let's say - 5 rounds.

and make a new account every 3 blocks: you need much hashrate to afford that, as there is a minimum payout

edit: btw the time-slice-method makes it more difficult for pool operators will detect you. as your hashrate will slowly go down

its not mine... its c00w. just for clarification
i am just playing with the maths

and it is not perfect right now!

planned:
 - better handling of backup bools
 - regard pools hashrate

but next i'll try to patch bitcoin itself to detect btcguild block - just because i think its possible

somebody said you could detect it through bitcoin itself.

just patch your bitcoin to do > 100 or more connections.
when a new block is announced have a look at the sender.

if the first announce came from btc guild its most likely their block.

its not my idea. but i am currently thinking about writing a patch for bitcoin.

bitcoins.lc is known to HATE hoppers.
and the owner is a really unkind person

i wont ever mine their again (even when hopping [hopefully someday] becomes unprofitable)

i don't work for douches!

here you go:

www.k1024.de/dev.7z

it has a small web interface:

http://ip:mineport/current/index

i emptied password.py completely

EDIT: please check pool.py. sometimes i change keys there too.... to lazy to look at it right now

this current version i published to discuss it only works with pools which has an more-or-less equal hashrate.

i don't say you should ever not switch to a pool with the most less shares.

but if there are two pools which found a block the same second you don't know which of them is better (means: who will solve this block first).

so best thing would be to divide your shares 50/50 (again: same hashrate atm only, could be improved)

i would prefer to switch pool whenever a share is found on a random basis (see my other version, not on git but in this forum - just for a look; it isnt really usable), but that just do only work if you have just one miner attached. with two or more you'll fuck up some getworks and get way more stales.

i am using my "time-slice" method since ten hours now (tweaked it a little more) and it seems good.

eg: the last mtred -> ozcoin switch. for you it switched immediatly. for me my shares has been splitted

earlier sharesare worth more than later shares.
you always (prop) want to go the pool which founds a block.

it gets a little tricky if two pools found a block very close. i made a patch for that - have to discussed with c00w (just see git if interested)

it'll only work if you bitcoind client listens to MANY other clients.

when it sees the message from btcguild first it's very likely btcguilds block.

shouldn't be that difficult to code either.

VERY nice; that could give good data

could you pm techwtf?
maybe he is able to put some of those on his site: http://fasthoop.appspot.com/

(i guess we need people working at isps to watch winning getwork requests too)