I'm pretty sure it is also undervolted so you won't be able to overclock that much (possibly some).

I'll let others suggest nodes, but I will say you need more than a few days to evaluate p2pool. It is a small pool (about 0.5% of the whole network last I checked) so it only gets a block every day or two. To give it a fair eval you should be willing to wait a few weeks at least. This isn't really any different from other small pools if you have a few hundred GH. If you want to help decentralize things and not run on a huge pool that finds blocks every hour you have to be willing to accept more variance on found blocks.

It's called selfish mining and some guys from Cornell (I think) did a paper on it. You can come out ahead if you are 33% of the network.

You may get the 3%. You are still eligible for payouts but whether old shares get paid out depends on luck.The older they are the more luck would be required to ever pay them (and therefore the less likely they are to get paid).

BTW, luck has been somewhat poor recently which is why you are seeing 97% payouts (sometimes less). I've seen 99%+ at times in the past.

The head start effect is real but the value is very small. It would only matter if you solve another block very quickly (within a few seconds). Most of the time it doesn't matter.

It's not personal for me, I have no stake in this pool other than using it a little. (I mostly use p2pool.)  

I just think people should be realistic about it. Isn't it a month or so of these frequent stats problems, failsafe mode, delayed payouts, etc.? Nothing bad has come of it ultimately (all delayed payments were made as far as I know), but the practical reality is this pool can't be relied upon for smooth steady payments, and it won't be reasonable to rely on those until some period of operating that way has been demonstrated. It has other advantages still (which is why I use it).

To be realistic about it, these problems are a regular occurrence now and if you aren't prepared to just wait it out, it is probably best to move on to a different pool. The constant whining every time it happens (not saying its you every time, I don't know, it might be different people) is not going to help.

There are now 18 Monarchs listed on post #1. Did we order more or is that some kind of late ship compensation?

Not necessarily. In some older buildings there aren't even individual meters for each unit, so the landlord has no idea of anything other than the bill for the whole building (which will likely be much more than $750). I have no idea if that is the case for OP.

This is a good point. Maybe it should be possible to store deferred payouts in the share chain up to some minimum and apply them to a future block, the way eligius does. There is definitely value in coinbase payouts and the pool not having a wallet (though in practice eligius does have a wallet) while at the same time not paying out a tiny slice of every single block to every single miner.

I don't know if this can be made hop proof though.

Yes, I agree. Risk relative to assets does matter.

But there is no direct relationship between your hash rate and your assets, so risk relative to hash rate does not necessarily matter. Where I already said I agree is that someone who is poor (you said poor country but the wealth of the individual matters more) should be more concerned about smaller risks.

In other words, if you want to manage risk in "relative" terms, the correct denominator to use is assets, not hash rate. What this means in practice for hobby miners is they need not be overly concerned about variance.

Bitcoin in absolute terms are what you spend (or save). In fact the number you are quoting, standard deviation divided by mean, has no units at all. It's a number that doesn't exist in the real world, only on graphs.

The key word you are using there, which contributes much to the confusion, is proportionately. In fact the standard deviation, measured in units of dollars, btc, or anything else is higher for the larger miner. It grows more slowly than the mean, but it still grows. A small miner has a small standard deviation in absolute terms.

No not me. I'm only splitting two ways so the fee function works for that. I did consider at one point that if I needed to split more ways I would find the fee function (random split) in the code and modify it, but I haven't needed it yet.

Yes it is added variance. This is accepted in understood by the participants in my case. In practice the payouts seem to be fairly close (it is shares that are being split probabilistically and over the payment window the number of shares is fairly large). As you said it reduces the changes of wallets being compromised and other problems.

I don't really agree that "you could code it yourself" is a good answer to a missing function that could attract more miners. I obviously don't know how many miners this particular function would attract.

Yes that is the question. I'm not sure you can flat out dismiss "technical" concerns. Maybe things like graphs and so forth are important. There may be other feature issues. For example, I know a few people have mentioned automatic splitting of payouts for farms with investors and group buys as being an attractive feature of ghash.io. I'm personally using the fee function in p2pool for that, but that only gives a two-way split, and it means I can't really open up my node for public use, which I might otherwise do. (There are no public nodes in my geographic area as far as I can tell.) Marketing and awareness are also important of course.

It's significant only insofar as people make it out to be significant. If a hobby miner's earnings vary from $10 to $0, that might well be less significant than a larger scale miner whose earnings drop from $5000 to $4000 but who spent many thousands of dollars on mining gear and has an electricity bill of hundreds or thousands of dollars per month. A $10 shortfall is a $10 shortfall, and can't ever make more than a $10 difference. You can't change that at putting some scary percentage number on it.

In any case, as I suggested earlier, the focus on very small miners is misguided. What p2pool needs is more large miners. Adding a few thousand 5 GH miners won't make any real difference. Getting KnC or whoever that was to mine their 1000 TH on p2pool instead of eligius changes the whole picture.

There is no length that is necessarily guaranteed to be long enough. If you are saying to extend the chain until blocks are found, that is exactly what proportional payout does.

If you are just suggesting to extend the chain to some other fixed length like 7 days or 30 days or something else, that is another story, with its own tradeoffs. For example, even people with large hash rates will see very small payouts for a long time when first starting.

Even 7 days probably won't be long enough soon.

If you are mining on a public node, you can measure how well you have "optimized" your miner using the pseudo-shares (reported by your miner) and the overall efficiency of the public node. There is no real difference between pseudo-shares and real shares from the point of view of an external miner using a public node (other than a difficulty of course).

If you are trying to optimize your own p2pool node with a tiny hash rate, you are certainly not doing it to maximize return on investment, because you can't possibly justify the cost a p2pool node (and full bitcoin node) for a tiny hash rate on an objective basis.

Thank you for your efforts. One question I would ask is what work is being done to make p2pool more attractive to large miners. That is the real solution here. More blocks helps everyone.

A development project in progress is not "flipping a switch."