The majority of p2pool discussion is no longer performed in this thread. It has moved to forum.bitcoin.com, since bitcointalk's moderators wanted only BTC-related discussion in this thread, and most of p2pool's users wanted to be able to discuss everything p2pool related in the same thread instead of having one thread for BTC and a different thread for everyone else.

Information on the current *bug* on the jtoomimnet BTC p2pool can be found in the following thread, along with most other p2pool discussion:

https://forum.bitcoin.com/pools/p2pool-decentralized-dos-resistant-trustless-censorship-resistant-pool-t69932-120.html

I currently believe that this is a compound bug in both bmminer 2.0 and p2pool. Older S9s (bmminer 1.0) seem to be working fine, and newer S9s are also working fine on different pools, but new S9s don't work on BTC p2pool right now as long as the BTC p2pool is the primary pool, in which case bmminer crashes on startup.

Installation instructions for p2pool (both jtoomimnet and mainnet) can be found in the second post of this thread:

https://forum.bitcoin.com/pools/p2pool-decentralized-dos-resistant-trustless-censorship-resistant-pool-t69932.html

I recommend that all subsequent discussion of p2pool be done in that thread, as it seems that the majority of p2pool-related discussion is now being considered off-topic in this thread. That forum's software is better, too. And, unlike bitcointalk, it's not blocked by the Great Firewall of China.

Perhaps there is a misunderstanding here. I did not release "Litecoin and Bitcoin Cash P2pool forks". I only released one fork. That fork was created to allow p2pool to create blocks that were consistently 1 MB (or more) in size, as a fix to #341. The changes that I made early on in that fork broke p2pool's existing Litecoin compatibility. This prevented me from merging my code back into the p2pool/p2pool github master branch, which in turn forced my fork to remain a fork and forced the mainnet and jtoomimnet p2pool networks to remain separate. So bugs on altcoins affect the BTC pool.

Recently, I unbroke Litecoin compatibility in my code, and allowed people to mine with my code on the mainnet Litecoin p2pool. Unlike BTC, it's the same pool, same network, and 100% compatible with forrestv's legacy code branch. It just has better performance. Soon, once I work out the last few bugs and find the time to do some git wrangling, I will submit a pull request to p2pool/p2pool master which will unify the BTC p2pool networks and get everyone mining into the same BTC pool.

Support for mining Bitcoin Cash is new and unique to my code, but it is also not a fork. It's the same codebase as is used for the jtoomimnet BTC pool. Adding Bitcoin Cash support took 5 commits out of 1775 total commits. It was basically just adding config files for Bitcoin Cash.

Frodocooper, everyone in this thread except you agrees that splitting this into two separate threads -- one for Bitcoin, and one for everything else -- is unnecessary and would make it harder to participate in the p2pool community. Most of the people who have altcoin p2pool nodes also have a BTC p2pool node. Forcing us to use one thread if your node's port is 9327, 9348, or 7903 and a different thread if your node's port is 9332 is silly and arbitrary.

This is the core of the issue. Bitcoin's market dominance used to be 95% or more. At that time, it might have made sense to segregate off non-Bitcoin discussions into their own sideshows. Now, Bitcoin's market dominance is only 35%, and so the distinction between Bitcoin and non-Bitcoin has become less important. Nowadays, Bitcoin is just one of many cryptocurrencies. As such, it no longer makes sense to give Bitcoin privileged status.

Splitting the discussion into Bitcoin and non-Bitcoin does not make sense. Moving the discussion entirely into the Altcoin forum doesn't make sense either, as Bitcoin is still the largest p2pool community.

This forum's structure was designed around a hierarchy that no longer exists. This forum topic should perhaps be in a forum titled "Cryptocurrency Mining" to encompass both Bitcoin and Altcoin. Unless you're planning on creating that forum, I suggest you just leave things as they are, since it seems to be working as it is.

Otherwise, we will need to move this discussion to another forum. I have created a thread on forum.bitcoin.com should that prove to be necessary:

https://forum.bitcoin.com/pools/p2pool-decentralized-dos-resistant-trustless-censorship-resistant-pool-t69932.html

The current code is in the 1mb_segwit branch. I haven't been keeping the release tags up to date.

My reading of the rule is that this topic does not violate the rule. Take this sentence:

This topic is about p2pool. P2pool is related to multiple currencies, but it is primarily about Bitcoin. As such, I do not think that this topic violates that rule. Note that the rule says "topic", not "post". My reading of the rule is that a post about an altcoin is permitted in this forum if it is relevant to the topic of the thread, and the topic is mostly about Bitcoin Mining.

P2pool has supported mining Litecoin as well as Bitcoin from the same codebase since 2012. Choosing to start forbidding altcoin posts after 6 years of allowing them is extremely disruptive. If you insist on forbidding them now, we will need to find another forum.

The password is ignored. To set the difficulty to 12k, append "+12000" to your worker username.

http://xpool.net/faq.html -- ctrl-f pseudo

I've seen this issue too, and have not yet been able to figure out the cause. I didn't realize it was affecting all nodes on the network at the same time. Thanks for pointing that out, it's useful information.

If you're running one of the nodes that does not have this issue (siberia.mine.nu:9338 and p2p-spb.xyz:9338) could you please contact me and let me know which version of bitcoind and which version of p2pool you're using?

Not really, no.

GBTL is the amount of time that it takes for p2pool to get a response back from bitcoind when it asks for a new block template (i.e. a new batch of transactions). It is a poor indicator of CPU performance. It mostly just reflects block size. If the CPU is way too slow for p2pool, then this number will climb to 200 ms or longer (possibly even several seconds), but if the CPU is just a bit too slow, it won't show much at all.

That was written many years ago, back when block sizes were under 100 kB, long before p2pool started to show the CPU performance bottleneck.

Because p2pool has not gained as much hashrate as the rest of the Bitcoin network. In other words, p2pool has relatively less hashrate than it used to.

75 ms is fine. The network latency to the node is a lot less important than the CPU speed of the node. A node with a slow CPU might take 3000 ms to hand out new work to your workers, whereas a node with a fast CPU might only take 500 ms. Whether you're adding 1 ms or 200 ms of network latency to that is nearly (but not quite) irrelevant.

Someone else might be able to answer #3.

^ jtoomimnet BTC block. This was p2pool's biggest block yet, at 1288.919 kB. It only brought in 0.07 BTC of fee revenue, though.

Another BCH block, mined by 1EN7cctiCdSU3jhdYZ8rwLLk1nRjGpWT5E:

https://blockchair.com/bitcoin-cash/block/00000000000000000027a67aad7c2556d84c29efe08f036da77b293792b75e48

Hmm, it looks like the coinbase transaction in that BCH p2pool block is causing Electron-cash to crash. Block explorers seem to be fine with it, though. Is anyone else having issues with it? If so, what wallet are you using? Are you able to access that transaction fine? If so, what wallet are you using?

Edit: This has been tracked down to a bug in Electron-cash which, apparently, has been fixed.
https://github.com/fyookball/electrum/issues/542

1st block mined on BCH!

https://www.blocktrail.com/BCC/block/00000000000000000242abe408a650a10eaf356f4547bb3e91a3e7033d57b6d2

The check_block_header function (which uses the getblockheader RPC method) is already compatible with pruned blockchains. It's only the getblock RPC that fails on pruned blockchains. The commit you made to change the initialization routine will allow people to use the wrong daemon at startup (e.g. Bitcoin ABC on the regular BTC network) and is dangerous.

For reference, I added support for pruned mode in this commit, with the fork protection and some renaming done here.

You don't need to change the RPC port in both e.g. ~/.litecoin/litecoin.conf and int p2pool/bitcoin/networks/litecoin.py. Changing it in the latter is probably a bad idea, actually. P2pool already checks litecoin.conf for non-default settings, and if any are present (e.g. RPC password or port changes) p2pool will use the litecoin.conf settings instead of the litecoin.py settings. It's only if the user has not changed the default port that p2pool will use the litecoin.py settings. If that's the case, then litecoin.py should point p2pool to the actual default litecoin ports, which are 9333/9332 not 10333/10332. The same applies for Bitcoin Cash.

Someone put about 3.5 PH/s onto the BCH p2pool around 30 hours ago. Current hashrate for BCH is around 4.4 PH/s, with an expected time to block of 3.7 days.

You should not use my nodes (ml.toom.im:933x) for all three pools. If my internet connection goes down and you're only using my nodes, then your machines will stop mining.

I don't have time to give p2pool the ability to parse the new address format right now. Old addresses still work. Internally, Bitcoin (Cash) software converts the address format into a public key, and the pubkey is what is encoded in the transactions. The pubkeys have not changed.

If you tell p2pool to mine to an old-style p2pkh address and are using a wallet that only supports CashAddr addresses, you can use https://cashaddr.bitcoincash.org/ to convert between them.

If someone is able to add CashAddr support in a pull request, I would be most appreciative.

There's no 100% reliable way to filter mainnet and jtoomimnet. The jtoomimnet blocks have different users and different payment addresses (e.g. the 1GuDN address) than mainnet, so you can do it manually if you'd like.
It's probabilistic. Luck is involved. Sometimes it takes less than the expected value. Sometimes it takes more. It's the same as how Bitcoin has 10 minute blocks on average, but sometimes it takes an hour between blocks, and sometimes it's only 2 minutes.

https://www.khanacademy.org/math/statistics-probability/random-variables-stats-library/poisson-distribution/v/poisson-process-1

recent_blocks will return any blocks found in the last 24 or 72 hours (depending on the software version -- I changed it recently). If no blocks have been found in the last 72 hours, then the most recent block is not recent, and it doesn't show up there. Since the expected time per block is currently around 20 days on jtoomimnet and 80 days on mainnet, recent_blocks will usually show nothing at all.

https://blockchain.info/address/1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 is a list of all Bitcoin p2pool blocks found. This includes both jtoomimnet and mainnet.

Oh, this is on Bitcoin. I was looking on my Litecoin node. I see the error now.

Taking a brief glance at the code (node.py:53 and p2p.py:71), it looks like the "in handle_share_hashes: ... twisted.internet.defer.TimeoutError"  error happens when a peer takes longer than 15 seconds to reply to a request for a share and its parents. This will happen e.g. when one of your peers is saturating its CPU at 100% on one core. It does not mean there's a problem on your node. It just means that someone else has a problem.

kr1z1s, you seem to be missing most of the error message traceback. The next 10 or 20 lines will contain most of the useful information.

I cannot find any similar errors on my node.