^^ but still we have the problem to know when btcg did found the block.

lp:
i am not sure. but we could try to monitor lp's and guessing that the first lp coming in is probably from the pool who found the block (still we have no clue about solo or pools we dont monitor)

still interested in the way multipool did with bit deepbit. reading perl is a PITA

how is deepbit handeld by multipool/multiclone?

the only way i can imagine is watching historic data and if they had bad luck, thank think they'll get lucky.

but this only works with an algorithm that spreads shares and does not stays within a pool ( i posted such a variant before; but it has too much rejects and i dont know how to handle them)

don't count on that: http://fasthoop.appspot.com/

^^ problem with this is that users get approx 30% more income (at costs of other miners... its just not that bad "per person" because the most are honest) - and you say if the donate 2.5% to the owner thats ok

i stopped pool hopping; i really like the maths behind it and try to learn more. but for now i decided to stick with a fair system (and keep an eye, on another problem with this system - i wont name it. btc guild is a GREAT pool- if you like prop - you should stay)

EDIT: but still, i dont like stats delay. i think there are other options, as just a "shortage" on miners which left to early (as i thought this pool was about as much stats as possible

^^ i like this idea.

but: what about 2.5% donation and invalid blocks?
don't see any possibility to keep this (and this is one of the things i like)

would me make come back

i still prefer "the user transparent" way too.

just start with a stats page how many people earn more than others through hopping (i already offered you writing the db statements, just need your schema)

THEN if ALL know whats going on, we can make a decision.
maybe: top 30% of people who profted from entering/leaving too much get a cut.

if you state that clearly one your site i don't see a problem. as it would only affects rounds which the miner left early

does this work with all miners?
i think i heard that some versions of diablo miner only calculates difficulty 1 shares - regardless what their getwork gave them

every monday.
but only collected (means which have been withdrawn from pools) payments are payed.

why kickout python 2.6?
for me this version works...(debian)

i made a small linux-vm for this purpose.
works well

(i used debian which is a little tricky when it comes to python 2.6; you could try latest ubuntu)

like it to..

could you provide an json output of this table?
and stats delay info per block.

would be really nice

https://mtred.com/api/user/key/'YOUR API KEY'

returns:
{"balance":"####","rsolved":"###","server":{"hashrate":289.1658,"workers":960,"roundshares":640637,"servers":{"n0":{"id":0,"host":"us.mtred.com","hashrate":257.4976,"workers":858,"roundshares":567980},"n1":{"id":1,"host":"eu.mtred.com","hashrate":31.6682,"workers":102,"roundshares":72657}},"foundblock":####},"workers":{"WORKERNAME":{"rsolved":"#####","mhash":####}}}

i now have a working implementation. i just starts a new server select whenever your client founds a share

its based on an old version with lp disabled completly - but (for me) its more stable.

(no password.py, no stats...) i don't know if i iwill upgrade the code. depends if i can go > 48hours without error

please remeber to change your pool accounts in pool.py!

here: www.k1024.de/dev.zip

no

lp announces a new block ANYWHERE on the network

and you just want to enter THAT pool. but how do you find out which one it was?

i prefer user transparency over stats delay:

http://forum.bitcoin.org/index.php?topic=7760.msg363810#msg363810

(just join us

i dont like stats delay - but its a very good way to stop hopping.

and: for a pool of the size of btcguild it really doesn't matter. hopper can't jump in rounds less then one minutes. and they are REALLY hot..

so i do believe for btcguild there is nothing to change.

for small pools i prefer a different way: user transparency

just show an additional (anonymous) stats page where everybody can see how many people profited how much more from a pool-hopping-like behavior (for a pool owner ist easy to detect if a users leaves early regulary).

let their users vote what to do (but be fair; no banning without giving them their funds eg)

but that doesn't help at all as you don't know who found the block.

could be a solo miner.

multipool tried to detect new rounds on deepbit that way. it wasn't very efficient.

i just read point 2)

are you saing it would be possible to submit the same share to multiple pools?

i am pretty sure you must deliever a share where the getwork came from.

i'll try the idea to switch pools fast tonight. lets see... my python skills still lack

is it possible for bitHopper to switch between pools very fast without producing stales?

if so, i think it could be better to decide pool target per submitted share:
one (simple) example for each client getwork request:

DIFF = 10000 (example)
btcguild =     1/100    = 0.01 (means btcguild has 100 shares right now)
bitpit =         1/3000  = 0.0003
bitclockers =  1/500    = 0.002
bitcoinslc =    1/10000 = 0.00001

BREAKEVEN = DIFF * 0.4 = 4000 (only switch between pools lower than break even)
RAND(0, (btcguild + bitpit + bitclockers))
0-0.01 -> btcguild
0.01-0.0103 -> bitpit
0.0103-0.0303 -> bitclockers

i want to implement this (and submit a pull request if it works of course). but i don't know if is feasible to switch that fast. i dont want to have much more stales

you convinced me!

but: 10% of TH are 200GHash.

if they where hopping around... just imagine

at the moment i think they are approx 50GHash hopping through your and other (smaller) pools (estimations just from watching pool stats, no math behind that number)

i like it very much that you don't want to switch another system. prop-payouts are for me a warm feeling