Quote from: jtoomim on June 15, 2017, 11:23:21 PM

Does the amount of network traffic used by p2pool bother anyone? I have some ideas for how to reduce the amount of traffic (without improving propagation performance), but the traffic doesn't bother me, so I haven't made implementing it a priority.

It does bother me a little. I run my (mainnet) P2Pool node on an Amazon EC2 instance AWS charges $0.09 per GB out for the first TB so any reduction in data transfer out would be most welcome

.

Also, having less network traffic may help to reduce latency from my miners to my P2Pool node, which should help lower my DOA rates. (AWS doesn't seem to have user-configurable network QoS).

Quote from: jtoomim on June 15, 2017, 11:23:21 PM

The other project I have in mind is trying to improve fairness independent of performance by using some sort of share DAG (e.g. with uncles) or one of the other ideas mentioned in https://bitcointalk.org/index.php?topic=18313.msg19248232#msg19248232. That's going to require far more work than the network traffic reduction, though.

Alternately, I could work on polishing the current code a bit, merging into the main p2pool repo, and organizing the community to upgrade. If I do that before the fairness work, that means that we have to do another big upgrade later.

Thoughts?

I personally would prefer having the jtoomimnet code merged into the main P2Pool branch first. We're essentially shooting ourselves in both feet by currently having two separate pools. With the current insane difficulty levels showing no signs of slowing down, it makes the most sense to consolidate our hashpower for a better chance at finding blocks. This may, in turn, attract more miners to P2Pool, since there would be one P2Pool again (network splits seem to scare people off), and a larger total P2Pool hashrate may make P2Pool more attractive again, potentially further attracting more miners which should help reduce variance for everyone.

I'm assuming that the improvements to fairness may take some time before it's ready for mainstream deployment, i.e., more than a month. I think that it's a reasonable tradeoff for us to merge first and then upgrade again in about a month's time (or two), rather than continuing to hobble along with our hashpower scattered across two P2Pools.