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

[Meuh6879]

Upgrade instructions to pass in Python v3.4 (in French) : https://bitcointalk.org/index.php?topic=1114415.msg26086837#msg26086837

Initial Tutorial (in French) for the initial Python v2.7 : https://bitcointalk.org/index.php?topic=1114415.0


Take time to understand the pip & wheel install & upgrade ... science (i'm not a linux user).

[1714177666]

1714177666

[1714177666]

1714177666

[Cryptonomist]

https://en.bitcoin.it/wiki/P2Pool#Stales

Could anybody be so kind to explain in more details, what does this mean?

On P2Pool stales refer to shares which can't make it into the sharechain. Because the sharechain is 20 times faster than the Bitcoin chain many stales are common and expected. However, because the payout is PPLNS only your stale rate relative to other nodes is relevant; the absolute rate is not.

What's PPLNS got to do with it?

Hello Rabinovitch,

The reason is in my opinion the following.

PPLNS is pay per last n shares. So lets assume that the last 200 shares result in a payment to the nodes that mined the shares. Lets assume that A, B, C and D mine and lets also assume they have the same hash rate. Further we assume that their stale rate is 0 (so each miner has a stale rate of 0). In this case each miner has 50 shares (this is not necessarily true in reality because mining is a random process) in the share chain. Lets also assume for simplicity that every share leads to an equal payment. In that case each miner gets a payment when a block is found that is equal to 1/4th of the block reward.
Now lets assume that A, B, C and D mine, but they all have a stale rate of 10%. This means that 10% of the shares of the network are lost. This means that to generate a chain of 200 shares, the network takes 10% more time than in the previous situation. Since they all have a 10% stale rate, they all wast an equal amount of work, so in the end the share chain of 200 shares will again contain 50 shares of each node. This means also that they have right on 1/4th of the block reward.
Now lets assume again that A, B, C and D mine, and they again all have the same hash power. But now A, B, C have a stale rate of 0, and D has a 50% stale rate. Now there is a difference in the amount of shares each node will have in the share chain of 200 shares length. A, B, and C will have 57.14 shares in the share chain, and D will only have 28.57 shares in the share chain. This means that D will get much less reward than A, B and C if a block is found. The share for D decreases, but the share of A, B and C increases.
So the relevance of PPLNS is that it pays a reward to a miner according to the number of shares it has in the share chain. The relative stale rate has an impact on the distribution of the reward, because it determines how many shares each miner will have in the share chain.
Of course the examples here are simplifications of the real algorithm. PPLNS comes in many different forms. You can find a more detailed explanation of PPLNS at https://bitcointalk.org/index.php?topic=39832.

I hope this is an answer to your question.

[jtoomim]

I have a test node up mining Bitcoin Cash

code plz

I was able to mine some blocks on testnet. Yay. I want to finish some code that will make it avoid exceeding block size/weight limits first. Almost done.

[Cryptonomist]

Cryptonomist, your CPU is faster than bitlock1's, and is probably fast enough to run jtoomimnet p2pool with pypy and with an acceptable (but not excellent) DOA+orphan rate, though of course faster would be better.

Edit: based on PMs, it looks like Cryptonomist's setup is working okay. jtoomimnet will often choose higher pseudoshare difficulty, especially on startup, and Cryptonomist is using USB miners with a very low hashrate (~80 GH/s), so he's only finding one stratum share (p2pool pseudoshare) every 15 minutes or so. But it's working.

Hello,

So i'm no mining again on my own p2pool node using jtoomim's fork. However, there are still some things that aren't very clear to me. I've been running my miners and node now for a couple of hours, however, the p2pool output is still the following:

Code:

2017-12-11 13:57:56.476565 Peer sent entire transaction c714882643dfb355152cffe5ec79754a64c73610fb9c41edaccc8e4ca641c6b7 that was already received
2017-12-11 13:57:58.721058 Peer sent entire transaction c714882643dfb355152cffe5ec79754a64c73610fb9c41edaccc8e4ca641c6b7 that was already received
2017-12-11 13:57:59.927420 Peer sent entire transaction c714882643dfb355152cffe5ec79754a64c73610fb9c41edaccc8e4ca641c6b7 that was already received
2017-12-11 13:58:04.081785 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:05.791001 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:06.049836 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:06.285570 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:06.726747 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:12.124851 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:14.679518 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:14.902474 P2Pool: 17628 shares in chain (16240 verified/17632 total) Peers: 10 (4 incoming)
2017-12-11 13:58:14.902849  Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2017-12-11 13:58:14.903110  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0000)=0.0000 BTC
2017-12-11 13:58:14.903413  Pool: 7173TH/s Stale rate: 3.2% Expected time to block: 11.0 days
2017-12-11 13:58:15.408087 Peer sent entire transaction 5fc8f4ccf5ccd68c4a0ca57a30fbca580061a75873b0bed4cbc9e8a441e5e64a that was already received
2017-12-11 13:58:18.516933 Peer sent entire transaction bea3223c82a3c08b75c9d51b7ce7a3bb1931d3dec355903a0d214ad50e569393 that was already received
2017-12-11 13:58:19.591504 Peer sent entire transaction 521b0e85fece2a4af6b84f9cd7a9a57b310a9a1b3a0349f74308f07ed33bf196 that was already received
2017-12-11 13:58:21.115704 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:21.277624 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:21.414326 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:22.602042 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:29.465659 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:30.497847 Peer sent entire transaction 7f7e0343783c01bd435e6c2291d2c3ff662e7f2f011c20e63cda9753b5ef5e91 that was already received
2017-12-11 13:58:30.743429 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:35.010332 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:36.765627 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:36.815290 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:38.326642 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:39.066717 Peer sent entire transaction eefc6be2c096c3f0a4b5a2f40b3db71dee318b094db1c4669560495b1f60a742 that was already received
2017-12-11 13:58:43.359680 Generating a share with 1009297 bytes (289609 new) and 572 transactions (281 new)
2017-12-11 13:58:43.454053 Warning: Previous share's timestamp is 205 seconds old.
2017-12-11 13:58:43.454353 Make sure your system clock is accurate, and ensure that you're connected to decent peers.
2017-12-11 13:58:43.454537 If your clock is more than 300 seconds behind, it can result in orphaned shares.
2017-12-11 13:58:43.454685 (It's also possible that this share is just taking a long time to mine.)
2017-12-11 13:58:43.510764 New work for xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Diff: 346418.14 Share diff: 49058729.28 Block value: 13.78 BTC (572 tx, 1009 kB)
2017-12-11 13:58:43.999881 Generating a share with 1009297 bytes (289609 new) and 572 transactions (281 new)
2017-12-11 13:58:44.095464 Warning: Previous share's timestamp is 206 seconds old.
2017-12-11 13:58:44.095825 Make sure your system clock is accurate, and ensure that you're connected to decent peers.
2017-12-11 13:58:44.095977 If your clock is more than 300 seconds behind, it can result in orphaned shares.
2017-12-11 13:58:44.096125 (It's also possible that this share is just taking a long time to mine.)
2017-12-11 13:58:44.226306 Peer sent entire transaction c1200722f49b5865e71c72509ba7378a720b04597208b3ea84dcc2d2736ed1d0 that was already received
2017-12-11 13:58:44.325999 Peer sent entire transaction 896452b94905c8bab594c088a3ae17f99a286f3e0d4514c31ab8ae52e84cfe23 that was already received
2017-12-11 13:58:44.494081 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:44.671330 Peer sent entire transaction 896452b94905c8bab594c088a3ae17f99a286f3e0d4514c31ab8ae52e84cfe23 that was already received
2017-12-11 13:58:44.911456 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:45.033646 P2Pool: 17628 shares in chain (16240 verified/17632 total) Peers: 10 (4 incoming)
2017-12-11 13:58:45.033913  Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2017-12-11 13:58:45.034058  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0000)=0.0000 BTC
2017-12-11 13:58:45.034204  Pool: 7173TH/s Stale rate: 3.2% Expected time to block: 11.0 days
2017-12-11 13:58:45.092149 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:53.621809 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:53.957365 Peer sent entire transaction 688583e03e9043bbd6566c9ef5da8f0550d8a8b960f0b9239a94e4fc99887c5e that was already received
2017-12-11 13:58:57.317096 Peer sent entire transaction a94cf7b5a6d446b901783e8168141bd5699b18b099d6315621441251b7c4659b that was already received
2017-12-11 13:58:57.330907 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received
2017-12-11 13:58:57.527107 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received
2017-12-11 13:58:57.970848 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received
2017-12-11 13:58:58.373802 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received
2017-12-11 13:58:58.617500 Peer sent entire transaction 97d75c8a745d8b8593d328e3f4150a243f75cf3531c7f4c67fef447841500d87 that was already received

So as you can see, although my miners are pointed to my node at 127.0.0.1:9332, the local rate is still 0H/s. My miners are very slow, but still I think that their hash rate should be visible. Or am I missing something?

Also, it is strange that my cgminer now again gives 0 accepted and 5815374 rejected. This is something I find strange.

The output of cgminer is:

Code:

 cgminer version 4.10.0 - Started: [2017-12-11 11:12:05.150]
--------------------------------------------------------------------------------
 (5s):105.8G (1m):96.54G (5m):93.58G (15m):90.14G (avg):95.91Gh/s
 A:0  R:5815374  HW:263  WU:1334.1/m
 Connected to 127.0.0.1 diff 329K with stratum as user xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 Block: 8ee4d35a...  Diff:1.59T  Started: [14:10:53.954]  Best share: 226K
--------------------------------------------------------------------------------
 [U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
 0: BSC 10000197: COMPAC-1 150.00MHz HW:0 | 7.307G / 8.277Gh/s WU:115.7/m
 1: BSD 10013137: COMPAC-2 200.00MHz HW:262 | 21.02G / 21.96Gh/s WU:301.0/m
 2: BSD 10013099: COMPAC-2 200.00MHz HW:1 | 34.09G / 21.93Gh/s WU:306.4/m
 3: BSD 10013031: COMPAC-2 200.00MHz HW:0 | 28.43G / 21.79Gh/s WU:304.4/m
 4: BSD 10013138: COMPAC-2 200.00MHz HW:0 | 21.81G / 21.95Gh/s WU:306.7/m

Code:

[2017-12-11 13:52:13.774] Stratum from pool 0 requested work restart
 [2017-12-11 13:52:27.996] Stratum from pool 0 requested work restart
 [2017-12-11 13:52:40.520] Pool 0 difficulty changed to 342703.6
 [2017-12-11 13:52:40.521] Stratum from pool 0 requested work restart
 [2017-12-11 13:53:40.111] Pool 0 difficulty changed to 338314.9
 [2017-12-11 13:53:40.111] Stratum from pool 0 requested work restart
 [2017-12-11 13:53:42.105] Stratum from pool 0 requested work restart
 [2017-12-11 13:54:00.967] Pool 0 difficulty changed to 337301.9
 [2017-12-11 13:54:00.967] Stratum from pool 0 requested work restart
 [2017-12-11 13:54:22.709] Pool 0 difficulty changed to 335591.2
 [2017-12-11 13:54:22.710] Stratum from pool 0 requested work restart
 [2017-12-11 13:54:23.999] Stratum from pool 0 requested work restart
 [2017-12-11 13:54:53.832] Pool 0 difficulty changed to 333706.6
 [2017-12-11 13:54:53.832] Stratum from pool 0 requested work restart
 [2017-12-11 13:55:18.669] Pool 0 difficulty changed to 332825.1
 [2017-12-11 13:55:18.669] Stratum from pool 0 requested work restart
 [2017-12-11 13:55:41.308] Pool 0 difficulty changed to 329907.0
 [2017-12-11 13:55:41.308] Stratum from pool 0 requested work restart
 [2017-12-11 13:57:11.395] Stratum connection to pool 0 interrupted
 [2017-12-11 13:57:12.424] Pool 0 difficulty changed to 322413.0
 [2017-12-11 13:57:12.428] Stratum from pool 0 requested work restart
 [2017-12-11 13:57:13.008] Pool 0 difficulty changed to 329907.0
 [2017-12-11 13:57:13.008] Stratum from pool 0 requested work restart
 [2017-12-11 13:57:13.008] Rejected untracked stratum share from pool 0
 [2017-12-11 13:58:43.051] Stratum connection to pool 0 interrupted
 [2017-12-11 13:58:44.164] Pool 0 difficulty changed to 346418.1
 [2017-12-11 13:58:44.169] Stratum from pool 0 detected new block at height 498741
 [2017-12-11 13:58:44.256] Stratum from pool 0 requested work restart
 [2017-12-11 13:58:44.262] Rejected untracked stratum share from pool 0
 [2017-12-11 13:59:04.957] Pool 0 difficulty changed to 345313.8
 [2017-12-11 13:59:04.957] Stratum from pool 0 requested work restart
 [2017-12-11 13:59:49.833] Pool 0 difficulty changed to 349850.7
 [2017-12-11 13:59:49.833] Stratum from pool 0 detected new block at height 498742
 [2017-12-11 14:00:26.001] Pool 0 difficulty changed to 344780.4
 [2017-12-11 14:00:26.002] Stratum from pool 0 requested work restart
 [2017-12-11 14:00:27.293] Stratum from pool 0 requested work restart
 [2017-12-11 14:00:44.426] Pool 0 difficulty changed to 342663.0
 [2017-12-11 14:00:44.427] Stratum from pool 0 requested work restart
 [2017-12-11 14:00:53.575] Pool 0 difficulty changed to 341213.7
 [2017-12-11 14:00:53.575] Stratum from pool 0 requested work restart
 [2017-12-11 14:00:55.052] Stratum from pool 0 requested work restart
 [2017-12-11 14:02:04.548] Pool 0 difficulty changed to 333298.2
 [2017-12-11 14:02:04.548] Stratum from pool 0 requested work restart
 [2017-12-11 14:02:26.943] Pool 0 difficulty changed to 330923.5
 [2017-12-11 14:02:26.943] Stratum from pool 0 requested work restart

So it detects the new blocks. But the work is always restarted, and the difficulty adjusted. Under normal operation I should see a lot of accepted, which is here not the case. I understand that the difficulty is higher on the jtoomim fork, but even then I should have seen some accepted in the last couple of hours.
We know (jtoomim confirmed this) that my miners work, so it must be that something is wrong with my p2pool node or with the connection between my miners and my p2pool node. However, the output of p2pool doesn't seem abnormal. It looks like a normal operating p2pool node, except for the timestamp error (this error was only temporary). Also, cgminer doesn't give any error messages. It's just that I don't know what is going wrong, since that I use exactly the same setup like the one i was using for mining on the main p2pool. So does anyone have a suggestion of what I can try next? Or is this purely because my miners are to slow?

Thank you in advance.



 

[Kiefff]

Hey all, been running a p2pool LTC node and its been going great until I get 10GH + of miners on my node. Ive ran it on my 12 core xeon(only 2.6gh clock). Then after reading that p2pool does better on single core high clock I ran the node on my i5 OC'd. Still the same issue. Now I'm trying my i7 3770 with the same issues. My pipeline is a biz connection, 100/20 to my home. Would running it with pypy work? I seen Jtoom mention it, but not sure if its just for his 1mb_segwit fork? Sorry, been trying to read ALL the pages in here before I come and ask. I'm all about p2pool, great work.

[jtoomim]

Cryptonomist, your node is handing out a difficulty of around 300k to your miners. The expected number of hashes needed to find a 300k diff pseudoshare is 300000*2**48/0xffff = 1.28 PH. With a hashrate of 80 GH/s, it's expected that would take about 4.47 hours per pseudoshare. Since p2pool needs to switch jobs every 30 seconds or so, that means that 99.82% of the time, p2pool would switch jobs before your miner found a (pseudo)share.

I suggest you manually set a lower pseudoshare difficulty (e.g. 256, for about 14 sec per) by putting address+256 as your stratum username. This will only affect your stats, not your revenue. You can also put address+256/32768 to set your share difficulty target to either 32768 or the network's minimum share difficulty (whichever is higher) if you want to have a better chance of mining an actual share.

Ideally, I would tweak my p2pool code so that it would adjust pseudoshare difficulty more quickly and intelligently to miners with different hashrates. However, that's pretty low on my priority list right now, since it does not affect revenue or resource requirements at all.

[jtoomim]

Hey all, been running a p2pool LTC node and its been going great until I get 10GH + of miners on my node.

Kiefff, can you describe in more detail what the issue is when it hits 10 GH/s? What goes wrong? Does your CPU get pegged at 100% on one core? Does the web UI become less responsive? Does it spit out error messages? Does your efficiency drop and your orphan rate increase? Does your machine halt and catch fire? It would be useful to have some more information on what the problem actually is.

[Kiefff]

Hey all, been running a p2pool LTC node and its been going great until I get 10GH + of miners on my node.

Kiefff, can you describe in more detail what the issue is when it hits 10 GH/s? What goes wrong? Does your CPU get pegged at 100% on one core? Does the web UI become less responsive? Does it spit out error messages? Does your efficiency drop and your orphan rate increase? Does your machine halt and catch fire? It would be useful to have some more information on what the problem actually is.

Hi, thanks for the response and sorry for lack of detail when asking for troubleshooting help. I know it can be super annoying. It seems everyone on the node, now that it is past 10GH local, now has high rejection rates(even my locally connected miners) and I also notice a increase in local stale shares. So it seems when A CPU core spikes to 100%, local dead on arrival spikes to around 15-16% and then goes back down after things seem to calm down on the CPU core. Local stale share % then starts to drop until the process starts all over again. Web UI seems to be just as responsive during these times, from what I can tell. No fire yet =] Thanks again for the reply.


it seems when this comes up, the CPU core spikes and my problem above happens

Code:

2017-12-11 12:23:58.579394 Peer sent entire transaction ffe7dff1b877c24f5dab32947698137d7e35fec51ab8accc0cbc59c947d5d230 that was already received
2017-12-11 12:23:58.591211 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received
2017-12-11 12:23:58.596509 Peer sent entire transaction ffe7dff1b877c24f5dab32947698137d7e35fec51ab8accc0cbc59c947d5d230 that was already received
2017-12-11 12:23:58.601995 Peer sent entire transaction ffe7dff1b877c24f5dab32947698137d7e35fec51ab8accc0cbc59c947d5d230 that was already received
2017-12-11 12:23:58.820905 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received
2017-12-11 12:23:58.844515 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received
2017-12-11 12:23:59.009682 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received
2017-12-11 12:23:59.031231 Peer sent entire transaction 8560094e76b112e54302624cbfe9aa0f666edd19d8526fa7da46fd7c2c460749 that was already received

[Kiefff]

http://814204445081.sn.mynetname.net:9327/static/

[jtoomim]

Kiefff, it looks like you have a lot of different mining addresses on the same node. Most of the work that p2pool needs to do is per worker address, not per worker. If you have 1000 miners all sharing the same worker address, that's less work for p2pool than 10 miners each with a different address. If you can change the miners to all use the same worker address, you should be able to handle the load just fine. That might not be an option, though.

I also notice that you seem to have enabled incoming p2p connections (e.g. by forwarding a port on your router) a few days ago, and you're now getting about 2x as many connections. Each connection increases the CPU load on your node, so if you have a slow CPU, you may be better off limiting your node to e.g. 5 connections total.

Pypy will probably also help as long as you have enough RAM. It looks like you're currently using about 1.8 GB of RAM on CPython, so that might increase to 4 GB if you switch to Pypy.

My p2pool modifications would probably help too, but I haven't tried running them on Litecoin yet, so I don't know if they would work.

[Kiefff]

Kiefff, it looks like you have a lot of different mining addresses on the same node. Most of the work that p2pool needs to do is per worker address, not per worker. If you have 1000 miners all sharing the same worker address, that's less work for p2pool than 10 miners each with a different address. If you can change the miners to all use the same worker address, you should be able to handle the load just fine. That might not be an option, though.

I also notice that you seem to have enabled incoming p2p connections (e.g. by forwarding a port on your router) a few days ago, and you're now getting about 2x as many connections. Each connection increases the CPU load on your node, so if you have a slow CPU, you may be better off limiting your node to e.g. 5 connections total.

Pypy will probably also help as long as you have enough RAM. It looks like you're currently using about 1.8 GB of RAM on CPython, so that might increase to 4 GB if you switch to Pypy.

My p2pool modifications would probably help too, but I haven't tried running them on Litecoin yet, so I don't know if they would work.

Jtoomim,

I will try to limit total connections as you suggested. I will give pypy a go as well. The rig itself has 16Gb of memory and I will always increase it to meet the needs. I will do some messing around with your fork as well on my spare rig. Thank you again for the reply and honestly, what you do for p2pool in general. I see EST block time is down on your Jtoomimnet. I tell anyone that asks to hop on if they want to mine some BTC.

[Kiefff]

and thanks to all that contribute with different p2pool forks as well. Its all good work.

[jtoomim]

I have pushed some new code into 1mb_segwit. Changes:

• Initial support for Bitcoin Cash. Use --net bitcoincash at the command line. Please let me know if you plan on running a BCH node with high uptime so I can add you to the DNS seeds list.
• Compatible with bitcoind pruning. Set "prune=10000" in your bitcoin.conf to limit it to 10 GB of disk space used for block storage (plus around 5 GB for the UTXO database)
• Improved block size and weight checking to avoid invalid blocks caused by the coinbase transaction putting the block over 4 million weight. Shares that exceed the block size or weight limits will be punished (i.e. orphaned).
• Minor CPU usage improvements by caching deserialized and unhexlified transactions when performing getblocktemplate calls

[Cryptonomist]

Cryptonomist, your node is handing out a difficulty of around 300k to your miners. The expected number of hashes needed to find a 300k diff pseudoshare is 300000*2**48/0xffff = 1.28 PH. With a hashrate of 80 GH/s, it's expected that would take about 4.47 hours per pseudoshare. Since p2pool needs to switch jobs every 30 seconds or so, that means that 99.82% of the time, p2pool would switch jobs before your miner found a (pseudo)share.

I suggest you manually set a lower pseudoshare difficulty (e.g. 256, for about 14 sec per) by putting address+256 as your stratum username. This will only affect your stats, not your revenue. You can also put address+256/32768 to set your share difficulty target to either 32768 or the network's minimum share difficulty (whichever is higher) if you want to have a better chance of mining an actual share.

Ideally, I would tweak my p2pool code so that it would adjust pseudoshare difficulty more quickly and intelligently to miners with different hashrates. However, that's pretty low on my priority list right now, since it does not affect revenue or resource requirements at all.

Hello,

@jtoomim: It was indeed just a difficulty issue. I've lowered the difficulty and now I get the local statistics in the p2pool output. Everything seems to work as expected. So thank you for the info.

[IAmLoco]

quick question
what are the current Hashrate required to have regular payout (bitcoin)?
I run 2 S7 (10Th total)
is it enough or should I stick to regular pool

[jtoomim]

S7s have a firmware bug that causes them to have about 10-20% lower hashrate on p2pool than on ordinary pools. If you mine on p2pool with a S7 with Bitmain-supplied firmware, you will experience lower revenue than you would get on a good centralized pool. (The bug was fixed in the S9.)

The payout frequency does not depend on your hashrate. The payout frequency depends on the amount of hashrate that p2pool has as a whole. Currently, the jtoomimnet btc p2pool has about 5.75 PH/s and is expected to find a block about once every 14 days on average. In contrast, the mainnet btc p2pool has a hashrate of 1.12 PH/s, and is expected to find a block about once every 70 days on average.

If you have low hashrate, the size of each payout that you receive will fluctuate a bit, but the frequency of payouts will be no different.

[kano]

S7s have a firmware bug that causes them to have about 10-20% lower hashrate on p2pool than on ordinary pools. If you mine on p2pool with a S7 with Bitmain-supplied firmware, you will experience lower revenue than you would get on a good centralized pool. (The bug was fixed in the S9.)

...

It exists in the earlier miners they made before the S7 also.
I pointed it out to them many times, MANY years ago, when I fixed the Bitmain drivers and put that in the main cgminer git - but they only did something about it finally in the S9.

What it does is throw away shares it thinks are stale, rather than pass them to the pool to decide if they are stale or not.
However, this has another rather drastic issue of throwing away blocks they think are stale, but may not be stale ...

The problem exists on all pools, but since p2pool changes work (on average) every 30 seconds, the effect is 20 times what it has on a normal pool.

[IAmLoco]

Great I currently looking to buy one S9 to replace my s7
I will look into p2pool with the S9 later

also maybe you have recommendation ofr non EOM firmware for S7?

[sawa]

Please let me know if you plan on running a BCH node with high uptime so I can add you to the DNS seeds list.

Please add to BOOTSTRAP_ADDRS:

Code:

crypto.office-on-the.net siberia.mine.nu

My nodes of the BCH p2pool:
http://crypto.mine.nu:9338
http://siberia.mine.nu:9338

I use different internet channels for the WORKER_PORT and P2P_PORT. Therefore, crypto.mine.nu need not be added to BOOTSTRAP_ADDRS

[jtoomim]

Please add to BOOTSTRAP_ADDRS: crypto.office-on-the.net siberia.mine.nu

Done.

Edit: Uh-oh. I just noticed that 9338 conflicts with the LTC p2pool p2p port of 9338 (which is nowhere near the worker port of 9327, grr!). I'm going to have to change the Bitcoin Cash ports. Sorry!