Quote from: jojkaart on October 15, 2012, 03:07:55 PM

This is not a hoppable scheme. To be hoppable, there needs to be both the promise of a cut and the idea of a round. This has neither.

round and promise of a cut is not what makes hopping possible.
Hopping is possible when you can expect more reward from the system than your fair share by changing who you are "contracting" with based on expected income probabilities. But anyway let's not discuss this point as there are more basic flaws here.

When you say there is no "promise of a cut" you are playing with semantics again: a share with a coinbase giving a percentage to one address must be a promise of a cut: it means that its miner was using a coinbase that will give this address a cut if a block is found. The miner who owns the address wouldn't start working on a coinbase giving back the same amount of work if it didn't consider that the other miner will continue working with a cut to it in the coinbase so these shares are indeed a "promise of a cut". If you don't agree with the share being a promise of a cut, the alternative is pretty bleak: there's no way for a miner to check that reciprocity is met and so the system is wide open for cheating.

Sorry but this protocol seems full of big holes and I really don't see the advantage: I'm not even sure what the "needlessly strict pool boundaries" are. Would you advocate a system where there is no pool at all and everyone should look for individual partners with a local "reciprocity daemon" finding/maintaining partners and checking that everything is going on nicely? That would be a mess: with p2pool we have ~200 users (and it's arguably high variance), should I contact them all to setup the thing? What about small miners, who would bother contact them (they don't help your variance much, so why bother)?