Bitcoin Forum

(*disclaimer- I'm very late to the game and don't expect to get any ASICs of my own any time soon*)

Premise:
I expect that the hashrate will increase greatly over the next few months (years?)

If I were a 'money-grubbing scumbag' (aren't we all  ;D ) then I think I would most likely mine at a pplns (or similar*) pool for the first n days when the hashrate to difficulty ratio is favourable, and then switch to pps towards the end of that difficulty period.

My reasoning comes mostly from here  (http://organofcorti.blogspot.ca/2013/02/99-asic-choices-avalon-update-2-by.html)

The reasoning being: the hashrate will be increasing so quickly that at the tail end of each difficulty period, the actual rewards paid out on pplns* would be much less than those of the pps systems (as I understand it, pps re-calculates their amount per share based on the difficulty that is set at the beginning of each difficulty change).

if this is indeed the case, then a miner on a pplns* pool (or a solo miner for that matter) could reasonably expect that he/she would earn the greatest amount of coins at the very beginning of the difficulty change, and much less as the next difficulty change draws near.

and, oh yeah, I promised a question...

Question:

What do you - the pool operators - plan to do about this? Will you simply maintain the status quo? Let the miners do as they will? Does this migration of hash power just become a new kind of pool-hopping? (never really got into pool-hopping myself, maybe this kind of thing is already old news to those that do hop)


Bonus suggestion: If I were an ASIC owner, and if I were a lazy bastard (aren't we all ;D ) I would be on the lookout for a "progressive" pps pool. This pool would offer low percentages at the beginning of the difficulty change, and then grow to progressively larger % towards the end ( say, 1% first few days, then 2% for a few days, and so on, until a max of say 5% near the end of the diff. period)


I dunno? Stellar idea? or stupid? let me know!



* for the purpose of this thread I am lumping all non-pps payment schemes together and just calling them pplns for simplicity. SMPPS DGM, prop. whatever... I believe the core issue will be the same in all cases, to varying degrees.

Well, obviously this is where your reasoning breaks. PPLNS is PPLNS and certainly not prop... Prop is definitely hoppable. PPLNS is as unhoppable as PPS, only it has variance while PPS doesn't. I don't think any of those is influenced by network total hashrate much if at all.

About share value, you can't compare the value of a share in PPS to a share in PPLNS IMO:
- in PPS, a share always has a value of [block value]/[share per block at current diff level] because this way the pool operator expects he will break even eventually (usually he takes quite a large fee to make big profit in the name of protecting himself against variance).
- in PPLNS, a share remains valid during the time it takes for the pool to compute N shares. And it doesn't matter how long this takes, because no matter the hashrate of the pool or the hashrate of the network, when you submit N shares at a given difficulty level, you will find (on average) always the same number of blocks. So if you yourself have submitted n shares in the same period, you'll get n/N*[block reward]*[number of blocks found in N shares]. If the pool goes faster but not you, your n will be smaller but this is only because the period defined as "the time it takes for the pool to compute N shares" is shorter. Let's say it takes half the time for the pool to complete N shares, and let's ignore the variance. In the time it takes you to submit n shares, the pool will submit 2N shares and also find twice as many blocks, so your reward becomes n/(2N)*[block reward]*2[number of blocks found in N shares]. Which is the same as before. More accurately you'll have a bit more variance, but that's all.

NB: I'm not a pool operator, just a miner who prefers to have variance and no fee but no hopping bunnies either, and thus who mines at a PPLNS pool (bitminter if you must know) ^^

No

Sorry schmadz, PPLNS hopping was known early on. Meni Rosenfeld discusses it (and other things) here: https://bitcoil.co.il/pool_analysis.pdf

Most PPLNS operators have made sure that their PPLNS implementations are not hoppable at changes in difficulty. Well done for figuring this out on your own, though.

if you die in outer space, mr. t cannot pity you

sound does not travel in a vacuum

Thanks for that pdf link!

and yes, my original post is failing in logic... but it all made so much sense to me friday night after the bar... oh well, teaches me once again the cardinal rule: Don't post drunk.

(*though if I hadn't, I probably never would have been introduced to Rosenfeld's paper, so I guess one can find a silver lining there*)