[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[windpath]

Back up and running.

...

Also what is the Node Fee?  It shows at 0% on the Node Scanner page, but on the 'node page' it was 1%+1%

The fee is 2% (1% for me and 1% for Forrest), the scanner will show it as 1% as it only takes the fee for the node operator into account.

[KorbinDallas]

Here's my node for those that need a backup, reliable pool.  Self hosted about 70 miles from the Washington DC backbone. I'm a geek about the node settings, but typically have great efficiencies.

Zero (0) fees, open to anyone, and my long term hope is P2Pool will decentralize mining again.

http://chamberslogicsystems.com:9332

For those who don't like DNS; http://73.148.18.80:9332

Cheers!

[jtoomim]

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.

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?

[Mister S]

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.

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?

The amount of network traffic can significantly affect users who are subject to data limits (Comcast users) and those who also run full node core. I know I bumped against my data ceiling last month. Reducing it slightly would definitely incentivise me to maintain a full running p2pool node even if I wasn't hashing at the pool. As with most things bitcoin, if it doesn't harm my wallet, I'll help where I can.

[frodocooper]

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).

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.

[windpath]

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.

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?

The traffic does not bother me, but it appears to affect others...

On improving fairness (and possibly variance for smaller miners/dust payments) I had talked with Sergio from Rootstock and he had some cool ideas. Considering they are going live soon it might be worth following up. The gist was that P2Pool would merge mine both BTC and RSK, and that the block reward would be trustlessly pegged immediately to RSK where smaller payouts could be accumulated and redeemed for BTC when the given miner decided to cash out. There is a lot to flush out there, but at the time (several months ago) Sergio offered to assist with the development.

I'd also like to see our fork resolved ASAP as our variance is just plain ugly

Thanks again for your work on this!

[jtoomim]

On improving fairness (and possibly variance for smaller miners/dust payments) I had talked with Sergio from Rootstock and he had some cool ideas. Considering they are going live soon it might be worth following up. The gist was that P2Pool would merge mine both BTC and RSK, and that the block reward would be trustlessly pegged immediately to RSK where smaller payouts could be accumulated and redeemed for BTC when the given miner decided to cash out. There is a lot to flush out there, but at the time (several months ago) Sergio offered to assist with the development.

Sorry Sergio, but that's not a cool idea. For one, it doesn't actually help the fairness problem at all, which is due to DOA/orphan rates being unequal between miners. SDL's proposal only helps with the minimum viable payout size and transaction fees, which is not a problem that we really have with one block a week.

Besides, there are much simpler ways to fix that problem. P2pool could easily encode a balance for each user into the share structure, and only make payouts for users whose balance (including this block) exceeds some threshold. Alternately, for a stateless system, if a user is owed 0.001 BTC and the minimum payout is 0.0015 BTC, we could pay out 2*.001=0.002 BTC each time a block is mined if (parent_hash % 2) == 0. Replace 2 with n for even smaller amounts owed.

[frodocooper]

On improving fairness (and possibly variance for smaller miners/dust payments) I had talked with Sergio from Rootstock and he had some cool ideas. Considering they are going live soon it might be worth following up. The gist was that P2Pool would merge mine both BTC and RSK, and that the block reward would be trustlessly pegged immediately to RSK where smaller payouts could be accumulated and redeemed for BTC when the given miner decided to cash out. There is a lot to flush out there, but at the time (several months ago) Sergio offered to assist with the development.

Sorry Sergio, but that's not a cool idea. For one, it doesn't actually help the fairness problem at all, which is due to DOA/orphan rates being unequal between miners. SDL's proposal only helps with the minimum viable payout size and transaction fees, which is not a problem that we really have with one block a week.

Besides, there are much simpler ways to fix that problem. P2pool could easily encode a balance for each user into the share structure, and only make payouts for users whose balance (including this block) exceeds some threshold. Alternately, for a stateless system, if a user is owed 0.001 BTC and the minimum payout is 0.0015 BTC, we could pay out 2*.001=0.002 BTC each time a block is mined if (parent_hash % 2) == 0. Replace 2 with n for even smaller amounts owed.

The RSK idea has one thing going for it, though — it allows for a user-configurable threshold, i.e., the miner can choose to cash out whenever he or she wants to.

If we were to go for the built-in version, it might be a good idea to find a way to make the threshold user-configurable as well (with a reasonable default). It gives miners more options, especially if P2Pool variance one day drops to an average of one block or more a day.

I'd also like to see our fork resolved ASAP as our variance is just plain ugly

Talk about an understatement .

[jtoomim]

User-configurable thresholds aren't hard. Each share you mine could contain a committed number representing your desired payment threshold. The current active threshold for each user is the threshold specified in the most recent share mined by that user.

While I've thought about the minimum payout problem and possible solutions, I don't intend to invest any time implementing them in the near future.

[Meuh6879]

i prefer an upgrade of the "package" (language ?) around the P2Pool installation ... before all others stuff.
P2Pool node (server) is really hard to install from a profane/rooky view.
And many links around Python (twisted ?) are old, too (ie. 64 bits instructions to keep the path).

I talk about this because many noobs in my part of the -french- forum don't really understand how to set a P2Pool node ... easly on all available OS.

I run a P2Pool node since 2015 with a full Bitcoin Core node.  

[sawa]

I started the thematic chat https://t.me/p2pool in the Telegram messenger https://telegram.org/
Join, share opinions, ask questions. Owners of nodes can publish addresses, exchange the source code of p2pools for different coins there.
Chat is multilanguage. Those who do not know languages, install the bot-translator http://telegram.me/ytranslatebot to the messenger

[tubexc]

This problem of the existence of two P2pools is easily solved if forrestv issues a node warning for everyone to install the P2Pool version of jtoomim!!!

[Meuh6879]

Pretty.

[jtoomim]

Looks like another nicehash miner with high DOA rates, but on mainnet this time. It's interesting to see how they drive the orphan rates down even as they drive the DOA rates up.

[veqtrus]

This problem of the existence of two P2pools is easily solved if forrestv issues a node warning for everyone to install the P2Pool version of jtoomim!!!

Why would forrestv want people to use a p2pool fork which would only make it more centralized?

[tubexc]

This problem of the existence of two P2pools is easily solved if forrestv issues a node warning for everyone to install the P2Pool version of jtoomim!!!

Why would forrestv want people to use a p2pool fork which would only make it more centralized?

More lucrative for the miners who come here to complain, you wanted to say !?!

[veqtrus]

This problem of the existence of two P2pools is easily solved if forrestv issues a node warning for everyone to install the P2Pool version of jtoomim!!!

Why would forrestv want people to use a p2pool fork which would only make it more centralized?

More lucrative for the miners who come here to complain, you wanted to say !?!

We can't force miners to care about decentralization. If they want centralized pools they can use them but that doesn't mean p2pool has to change.

[tubexc]

This problem of the existence of two P2pools is easily solved if forrestv issues a node warning for everyone to install the P2Pool version of jtoomim!!!

Why would forrestv want people to use a p2pool fork which would only make it more centralized?

More lucrative for the miners who come here to complain, you wanted to say !?!

We can't force miners to care about decentralization. If they want centralized pools they can use them but that doesn't mean p2pool has to change.

Anything
As long as this brings more blocks  
Blocks where are you ?

[jtoomim]

Why would forrestv want people to use a p2pool fork which would only make it more centralized?

Maybe because my fork has lower CPU usage, lower memory usage, lower orphan rates, better fairness, and substantially higher revenue from tx fees? And maybe because your premise of that causing centralization is, I dunno, wrong?

[veqtrus]

Why would forrestv want people to use a p2pool fork which would only make it more centralized?

Maybe because my fork has lower CPU usage, lower memory usage, lower orphan rates, better fairness, and substantially higher revenue from tx fees?

That's because new shares aren't 1MB yet as your fork allows. Then again you advocate making Bitcoin's block size limit infinite...