Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 713. (Read 2591919 times)

Bam bam! 2 in a row, i'm rich!

Yeah but a pretty brutally bad run of it.

Take a look at avg block times for the last 5 blocks.

If we find 50% of the block (compared to expected) your payout will be 50% of expected.
If we find 200% of the blocks (compared to expected) your payout will be 200% of expected.

The issue with those proposals is that without an enforced minimum difficulty cheating to reduce variance becomes trivial.  You create a tragedy of the commons situation where users unhappy with their share variance simply "cheat" and submit lower variance shares.  The network "speeds up" and avg LP interval falls from 10sec to 7sec or 5 sec.

If anything 10 sec is too short.  It is right at the inflection point.  Intervals shorter than 10s will result in significantly higher oprhan rates.  5s won't be double the 10s rate it will be more like 4x (so ~40% global stale rate). It is absolutely critical that the LP interval remain >=10s.

That got me thinking.
Yes, this seems to be a good idea!
How to adjust the individual share difficulty?

- To have it similar to now (one share each 10 sec), each node would poll the number of nodes and the p2pool hashrate. If the individual hashrate is "high" compared to the average node's hashrate, make the local share-difficulty higher.
Quite complicated, maybe unstable, and all in all not too elegant, in my view..

- Drop the "one share every 10 sec" altogether. Make every node find one share, say, every 10 mins. Big miners will have a high local difficulty, small miners a low one. Depending on the amount of nodes, the sharechain would grow faster or slower than now. With those 10 mins per local share and approx 200 users at the moment, there would be a new share every 3 secs. This probably is too short, so we may make it "node, find a share every 30 mins!" for an approx sharechain-growth of one share every 10 secs.

This would not scale too far neither. But it would be a lot easier and with less drastic changes than the other, older proposals (sub-p2pool, multi-p2pool etc). So it might be a bridge-technology, as we say here.

Ente

Hopefully, auto-adjusting difficulty based on hashrate is something that will be coming in a future version.

But then you can have the larger (say 5ghash/sec +) miners use a > 300 share difficulty so the smaller miners can remain semi-profitable and use a lower difficulty. Since the larger miners have "lower" variance as-is, a slightly higher share difficulty will have little to no impact on their payouts, but greatly help the smaller guys.

Who cares if you get a share in every block? You'll still get roughly the same number of payouts each day, even at a deepbit-size level.

Now if p2pool was 10 times the size of deepbit, then the difficulty would be so high that lots of small miners would not get daily payouts. That would be a problem. I look forward to p2pool growing so large that becomes a problem.

Right, I should clarify: yes p2pool itself should be able to handle it, but I doubt many miners would remain when the difficulty is so high that they may or may not get in a share in each block. It would have a negative feedback kind of effect, I would think.

Huh? P2Pool would continue to work if one DeepBit-equivalent of miners joined. Variance would just go up. P2Pool adjusts the share difficulty to keep traffic/CPU usage constant.

Sure, if p2pool could scale infinitely. But there are a few things that would have to be resolved before we could get that kind of scalability.

Average daily payout would be the same. Time to find shares would go up, and blocks found per day would also go up.

A slow 1 gh/s miner on p2pool gets a share on average every 45 minutes while p2pool finds a block every 4 hrs. Deepbit is 10 times the size of p2pool, so the 1 gh/s miner would get a share every 7.5 hrs and p2pool would find a block every 24 minutes. Large scale p2pool miners can adjust their share-rate, which will make shares easier for slow miners.

Um - you wanna explain that one?
I'd like to see your opinion of how p2pool would cope with DeepBit's hash rate ...

Not to mention people are staying with p2pool because they are lazy... (this guy). All jokes aside, it's easy to stay with the familiar.

No need to get all uppity, I'm just trying to eliminate some possibilities to get to the bottom of the pool's poor performance ... it may be bad luck but it is looking like more than that the longer it continues.

"Worth"? That assumes some gain by doing that. To drive away p2pool-users? It would be easier by a magnitude to use those 30Gh/s to "normally" mine for profit, and attack a regular centralized pool with DDOS. That would drive off their users to some degree, maybe attracting some of them for his own pool.

All data is there already anyway. We see which nodes exist, which nodes contribute how many shares (to add to the p2pool net hashpower) and which nodes do or do not find bitcoin blocks (to reduce the luck). If someone wants, he should be able to dig through the stats to verify/falsify this. Even if those 30Gh/s were on dozens of individual nodes, they probably come from the same IP. Even if not, with 30Gh/s you should be able to find anything, any clue.

You see, even with this "bad luck", people are sticking to p2pool, as can be seen in the stats. Not because p2pool is necessarily paying out better than all other pools at any time, but because p2pool is superior and healthier for the whole bitcoin universe.

But yes. I believe p2pool has a problem which may have stayed unidentified yet. The "hashing power reflected by hashes" and "hashing power reflected by blocks" are two fairly straight lines, but clearly diverging. Its not two overlapping lines, its not one line being crossed by the other all the time.
Connectivity seems to be one problem for the individual miner. Not for the global p2pool efficiency though.

Ente

Might be worth running the calculation to see how much hashpower it would cost a large competitor (pool) to run a p2pool node and refrain from sending in blocks. It would need to do this only at a level that makes p2pools persistent "bad luck" slightly worse than paying fees at pools to be effective.

Back of envelope says 5-10% has gone missing somewhere, assuming it is not all bad luck, so say around 30 GHash/s? Would it be worth it to "them"?

Note, the orphans that are known (the 6 on p2pool.info) are already accounted for in the luck calculations (i.e. luck is not reduced by known orphans).  The only think that could, in theory, be making the luck look lower than it should is unknown orphans, and I don't think there are many of them.  While the statement I made on p2pool.info is technically accurate, I do scan blockchain.info regularly looking for orphaned blocks and it does a pretty solid job of knowing about all orphaned blocks because it connects to 3000+ bitcoin nodes.

Let's talk numbers and theory. My theory is that orphans (p2pool's stale shares or Bitcoin's orphan blocks) are caused by latencies between the miner, p2pool node, p2pool network for p2pool stale shares and miner, p2pool node, bitcoind and the Bitcoin P2P network for orphan blocks.

Furthermore, as I understand things, the amount of stale shares should be proportional to the miner/p2pool node/p2pool network latencies. For example, if on average a share comes every 10 seconds and on average the latency is around 100ms for all miners, we should have 1% of stale shares (there's a ~1 in 100 chances that another valid share can be found by a node until it knows the share and inform miners to work on it). We have around 8% stale shares right now, so I estimate the latencies between miners on the p2pool network to be around 800ms (seems high at first but isn't too bad when you consider that the p2pool network should cover the whole planet and there are at least 3 components involved in latencies : miner, p2pool node and bitcoind process).

If bitcoind and the Bitcoin network were roughly as efficient as p2pool, the amount of orphans should be around 800ms/10min (in fact around 1/60 the proportion of p2pool's stale share given the target interval difference). Currently it should be 0.133% instead of 1.8%. Although 1.8% can't impact us much (our luck is around 90%, so if there's a problem, it isn't caused by orphan blocks), it's rather high when compared to what p2pool can achieve with a 10 seconds target interval instead of a 10 minutes. Either bitcoind isn't optimized or the size of the Bitcoin network compared to p2pool adds noticeable latencies.

The note about orphans on http://p2pool.info/ suggests that the real number is higher than that too. A pool can count every one of their orphans but we can't. Would be nice to know for sure one way or another if the block orphans are a big factor or not. (The share orphans are a non-issue)