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

Pretty.

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!!!

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

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.  

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.

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.


Talk about an understatement .

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 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!

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


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.

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.

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://bitcointalksearch.org/topic/m.19248232. 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?

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!

Back up and running.


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.

^^frodocooper-Yeah I get the variance on P2P but this happened before we ramped up last week that is why I started to dig a bit. All good info you have though.
Soi I had read the A7 thread, I guess as there is not a problem with the Avalon units there is not the need for specific threads as with other units.

Ah, then the difference is most likely due to luck and variance. Windpath's miner stats calculate your hashrate based on how many accepted shares — weighted by share difficulty — you currently have in the P2Pool sharechain relative to the entire pool. It is quite normal for Windpath's stats to differ from your actual miners' hashrate, since Windpath's stats are heavily influenced by your miners' luck and the pool's total hashrate. For example, if a large miner suddenly dumps a significant amount of hashrate on P2Pool and gobbles up a large amount of accepted shares within a short amount of time, expect to see everyone else's hashrate on Windpath's stats drop significantly while the stats readjust to compensate for the large miner's presence. Similarly, when the large miner leaves P2Pool, expect to see your hashrate on Windpath's stats remain at the low end while your miners catch up on the additional shares now available in the large miner's absence.

P2Pool's total hashrate — mainnet, at least — has been fluctuating a lot recently. So the differences you see in Windpath's stats should not be of much concern. What matters most, and what you should be monitoring closely, is your efficiency relative to the pool's.

I'd wager that your miners' P2Pool efficiency is a little bit on the low end. Have a look at this guide to see where else you might be able to eke out a little bit more efficiency from your miners and your P2Pool node.


No. The bug fix was in response to a support ticket that I opened with Canaan. It's still in beta, though, which is probably why there hasn't been any official word from Canaan regarding the fix. But then again, Canaan doesn't have an official thread or account on bitcointalk, as far as I know, nor do they usually announce the release of new software or firmware.

There is an unofficial Avalon A7 thread here.

Good luck with that!

I had been on there for nearly 2 weeks

What's the status of the Node Version?

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

thanks!

I'm unable to get p2pool.org up and running again remotely, ill be able to access the server in the morning... I hope everyone has solid backup p2pool nodes in their config

Windpath's active tab had me ~3TH for one 741

Interesting about the MM Firmware, I will try that.

I do failover only but the NTP client I used was Colorado, I will change them. Thanks for the info, is there a 741 topic I missed?

How much of a difference are we talking about?


Check if one, or some, of your 741's are dropping off after a while of mining. I had been struggling with an issue where both of my 741's would detach from the Controller at random, and only one 741 would reattach about a minute later. This beta 7411706-3e3ab60 MM firmware fixes that bug. The latest stable 7411706-3162860 MM firmware doesn't.

Edit: If you haven't already, try running your 741's with the "--failover-only" option. And be sure that both your node's and Controller's clocks are set correctly and have their NTP clients enabled and synced to "pool.ntp.org". In some rare and random cases, this, and setting both clocks to UTC, might lower your DOA rates.

Thank you, will do!