BIP148 states that all miners must signal for SegWit after August 1st. Currently, p2pool is capable of signaling for SegWit, so p2pool is compatible with this phase. If a majority of miners are following BIP148, then SegWit (BIP141) will enter into the LOCKED_IN state for two weeks, followed by the ACTIVE period two weeks after that. If 100% of miners follow BIP148, then the signaling phase will last 2 weeks. (If 10% follow, then 20 weeks, etc.) This plus the LOCKED_IN period means that we will have at least 4 weeks after August 1st before p2pool becomes incompatible with the Bitcoin chain.

It should take a week or less to merge and test SegWit support into jtoomimnet and/or mainnet's code. We'll be fine.

Yes. p2pool has no code for maintaining a mempool of valid transactions or deciding which transactions to include in a block, so the block would need to be processed by bitcoind and a new block template received from bitcoind before p2pool could start new work. That should take a little less than a second, so it's not a big deal.

This is actually pretty straightforward to do. P2pool has access to the share chain as an index of recently used and recently seen transactions, so it is generally able to encode a block in much less space than bitcoind can. I think most transactions take 2 bytes to encode (8 bits to refer to which ancestor share first mentioned the transaction, and another 8 bits to refer to the index of the transaction within that share), although the mean is much higher than that, especially when there are a lot of novel transactions.

There are other changes to make to p2pool that are a higher priority (e.g. improving fairness), so it's not likely that I'll implement block propagation via p2pool any time soon.

I heard from one of the Nicehash miners. He abandoned p2pool because the DOA rates he was getting from Nicehash were significantly eating into his revenue, and he can get more by solo mining. I can think of three ways of addressing this issue.

The first one is to submit DOA shares to the network and have them compete with non-DOA shares, and possibly change the preference algorithm on the receiver's side to give DOA shares a significant and fair chance of winning the subsequent orphan race. This approach would be likely to increase the possibility and severity of selfish mining attacks, so I'm a bit reluctant to pursue it. It would be pretty simple in terms of code changes, though. Some more detailed thoughts on this below.

The second one is to add an uncle mechanism or DAG structure to the share chain. This would likely be much fairer, but it would require a p2pool hard fork and a substantial amount of new code. This would be the best option if developer time weren't an issue.

The third one is to try to increase the average share interval by increasing the default or minimum share difficulty. Changes to the minimum share difficulty require a hard fork, but a simple one. Changes to the default share difficulty just require that some nodes (especially the large ones) run different code. If the average share took 4x as long, then both orphan and DOA rates would be 1/4th their current values. Drawbacks of this approach are (1) that small miners would find it more difficult to get shares into the share chain (unless share difficulty were a function of the number of shares in the chain), and (2) that it's potentially not incentive-compatible, as the benefit of making high-difficulty shares goes to everyone who mines afterwards, and not to the person who mines the high-diff share. A person with a lot of hashrate has a greater chance of winning an orphan race if he works on low-diff shares than if he works on high-diff shares, since p2pool essentially just uses (1) the share height and (2) the time of arrival when determining which share to base its work off of, and ignores difficulty.

But maybe that isn't the best way to choose the share to base work off of? Ultimately, the problem we're having with fairness comes from the fact that some shares have greater expected revenue in the share chain than other shares, due to differences in orphan risk caused by differences in node performance and propagation times. If we no longer take time-of-arrival into account (or weight it less heavily), then the incentive to run a large, high-performance p2pool node dissipates. That might sound like a bad thing, since it could result in a higher block orphan rate for p2pool, but it's not really that bad. The issue comes from the fact that Bitcoin block intervals are 600 seconds, but shares are 30 seconds, which means that we are punishing low-performance nodes by 20x more than is fair.

Another problem with the existing algorithm for choosing which share to base work off of is that all shares are treated the same, regardless of their difficulty, which makes low-diff shares have an advantage for selfish mining attacks. Large-diff shares contribute more work to p2pool, so they should have a greater chance of winning an orphan race, ceteris paribus. But you can't just pick the highest-diff share of all shares in an orphan race, since that would cause a race-to-the-top scenario where the optimal difficulty to use for your shares is the highest diff that a competitor uses plus one. That would also allow a selfish miner to reliably win orphan races against siblings: instead of working on a child share of the best known share, you could just orphan it by creating a sibling with +1 difficulty. So it needs to be probabilistic.

The algorithm I'm thinking of for choosing the winner of an orphan race is this:

1. Take all of the shares at the best chain height (using the current 5th-gen-parent work done heuristic)
2. Find the time that the first of those candidate shares arrived, and call that start_time.
3. For each share, calculate the difference between that share's arrival time and start_time, and call that share_delay.
4. Calculate share_nonorphan_chance = 1 - share_delay/600 (for Bitcoin) for each share. This gives a correction factor for how much less likely than the best share this share would have been to not be orphaned as a bitcoin block. That is, a share that took 6 seconds longer than the fastest share would get a 1% higher orphan risk, and would get a share_nonorphan_chance of 0.99.
5. Calculate share_corr_share_diff = share_diff * share_nonorphan_chance.
6. Pick a share randomly, giving a chance of share_corr_share_diff/sum(share_corr_share_diffs) for each share.
7. Mine using that share as the parent.

If my math/logic is correct, this algorithm would give pretty much everyone a fair chance of winning a share orphan race, regardless of their node performance or share difficulty.

No, the 12 seconds was due to my bitcoind process, not p2pool, as you would know if you had read all of my original post. I'm not running Falcon or FIBRE on my node, just theblumatt's old relay network, which is probably why it took 12 seconds. If you think it is bullshit that it took 12 seconds to download that block, then I'm inclined to agree with you. If you think that it's bullshit that p2pool choose to mine an empty block during those 12+2.7 seconds, then I'm inclined to disagree with you.

We're not counting the same way. In my example above, it took 12 seconds (after p2pool received the header) for the block to arrive, less than one second for the block to be validated and a new block template to be pushed to p2pool, and 2.7 seconds (because CPython p2pool is slow) for p2pool to issue new work to the miners. You're not counting what took 12 seconds in the case above.

I'm having trouble following your assertion. Is 14.68 seconds not slow to you? Or is it bullshit that it's so slow? Or is it bullshit to mine transaction-less blocks during those 14.68 seconds? Or is it just bullshit because Luke-jr was involved?

It's more an issue of processing and propagation latency than mempool size. P2pool (along with most other pools) has code in it to generate empty blocks when the pool has heard of a new block header on the network, but has not yet gotten a block template from bitcoind. bitcoind can't generate a new block template until after it has fully downloaded and verified the previous block, since otherwise it might include transactions twice or include double-spends. Since downloading a block header is faster than downloading and verifying a full block, there can sometimes be a substantial amount of time in between where the best you can do is mine an empty block. The idea is that if you have a miner hashing on something, it's better to hash on an empty block at the right height than a full block at the wrong height (which would result in an orphan race). This condition should only last for a few seconds, though. The 23 actual seconds that elapsed seems excessive. It's possible that I need to do something to improve block propagation latency on that node. It's also possible that p2pool didn't poll getblocktemplate frequently enough or something.

If this happens when blocks are found in the first 30 15 seconds of mining, that would correspond to a 5% 2.5% reduction in average transactions included. That seems undesirable, but not excessive. The alternative -- mining on the wrong block height for up to 15 seconds -- sounds worse. I wish I had time to look into this more and improve performance, but at the moment I don't.

Edit: It appears that the timestamps on the blocks are wrong. This is pretty common, as generally timestamps are set when the stratum job is issued to the miner, not when the miner actually finds the block. Here's what shows up in my bitcoind logs:


Then, in my p2pool logs:


It's worth noting that this was a DOA share that happened to be a block. P2pool learned of the block at height 468172 at 3m20s, bitcoind learned of it 12 seconds later at 3m32s and had work for p2pool around that time, but p2pool didn't have it bundled into a stratum job until 3m34.7s. While p2pool was bundling the stratum job, a miner returned the block from the previous stratum job, and p2pool didn't process it until after it finished assigning the new work because p2pool is single-threaded. This means that the block was found at some point between 3m32s and 3m34.7s.

This node was running CPython, not pypy, because that server is running low on RAM. This may have contributed to the slow (2.7s) processing of new work, and increases the likelihood of a DOA share.

So in this case, we're talking about a 15 second time window, not 30 or 24. Of those 15 seconds, 12 seconds were due to bitcoind being a bit slow, and 3 seconds were due to p2pool being slow. Overall, I think finding an empty block in this scenario is a reasonable outcome, and do not consider this to be a priority for optimization right now.

LTC now requires SegWit, which requires veqtrus's PR. It would take some more work to get LTC working with both my code and veqtrus's. It would need to be a different alt for testing.

At the moment, I'm more interested in the memory issues and the share size issues than in doing testing and merging. I'd also like to add some code that checks the system clock against NTP (when reachable) at startup in order to reduce the clock offset issues that people have been having, and I think that might be good to do before merging into p2pool master.

Quick reminder: the jtoomimnet 1mb_hardforked branch of p2pool uses about 2x as much RAM, since the share chain contains around 2x as many transactions. If you are using pypy, this means that your memory consumption may get up to 6 GB. If you're using CPython, it's a little under 1 GB. Please make sure that you have enough RAM in your nodes. If you don't have enough RAM, you will get massive swapping, and you might notice that bitcoind is unable to keep up with blocks and may fall behind, causing p2pool to stop working.

Lowering RAM usage is my next goal for p2pool.

To whomever is mining on ml.toom.im:9332 with address 3GU89xZmzJfCBXFzbB3mC2dsxDyKqrD7nz:

P2pool does not support multisig or P2SH addresses. Any worker name that is not a regular P2PKH address (starting with a 1) ends up contributing to the default address for that node. In other words, you're mining into my wallet, not your own.

I'll send you the 0.125 btc you made in the last block soon-ish (few days? I don't currently have access to that wallet), but I think everyone would be happier if you mined directly into your own address. Edit: sent.

The difficulty of the share is different from the hash that the share actually gets. The threshold for the share is encoded into the share itself, and is part of what gets hashed, which means it's like saying "I promised you I would make a share with difficulty X, and if you hash this sentence (which includes nonce Y) you'll see that it meets that difficulty level." It doesn't matter how far you exceed that difficulty threshold.

Nicehash rates are probably high right now. This will give you a chance to get more of your shares into the share chain and increase the amount of reward per block you'll get should a block be found. The ≥1 PH/s of hashrate on my nodes will be staying on jtoomimnet p2pool no matter what, so we will find a block eventually even if the Nicehash renters never come back. It might take a few weeks, though.

sawa, I didn't touch any code related to the json-rpc stuff. My guess is that this is a recently introduced bug on the miningrigrentals end. It seems that they're appending an extra parameter on their share submission messages. Have you tried the same rentals on mainnet recently? My guess is that you'd see the same issue. You could also try packet sniffing (e.g. with tcpdump -X port 9332) to see what parameters they're sending; they might just be using some stratum extension that p2pool doesn't yet support.

If you use tcpdump, you're looking for lines that look like this:
If we know what extra data they're sending, we might be able to patch p2pool to support it (or, if it's safe, to ignore it).

I did some testing, and I was unable to reproduce this error. Is it still occurring? If so, do you think you might be able to give me remote access to this machine (e.g. via showmypc.com or teamviewer) so I could do some debugging and testing?

Ignore that. The version that p2pool advertises is not based on the code itself, but instead on the git history of the branch that you're logged into. Specifically, p2pool runs "git describe --dirty --always" in order to determine its version number. git describe will look for the most recent tag that is reachable from a commit. As I haven't tagged any new versions yet (though I totally should have), git describe doesn't say anything helpful. For some unknown reason, it shows up as 16.0-7-* on my nodes but 15.0-43-* on the nodes that other people have made from cloned repositories, even though the code is exactly the same.

If you run "git log", that will list the most recent changes that were made on the branch you're using. As of today, the most recent commit should be:

commit cc6fd7d227f869aa02cdf9f89e8349aa9d2a4344
Author: Jonathan Toomim
Date:   Wed May 10 06:11:49 2017 -0700

    Don't attempt retransmission of shares when transactions are missing (avoid hang on sync)

Sounds good. 1mb_hardforked isn't quite ready for master yet, as it hasn't been tested with any altcoins -- this commit (https://github.com/jtoomim/p2pool/commit/fe9179e4a81543aadfcc840c0697df0aa475748f) in particular worries me -- but once I've tested it at least with one altcoin and have investigated the timezone issue a bit better, I'll put in a PR.

This commit (https://github.com/jtoomim/p2pool/commit/e71535e4401d0e0b6d19b2c0741b1fff2d9770a1) significantly reduces the CPU load from p2pool dealing with large numbers of transactions. CPU load vs transaction volume was O(n^2) in the old version of p2pool, but should be O(n) in my branch.

As you may have noticed, forrestv isn't very active in this community any more. As such, I have been treating this more as a p2pool community thread rather than forrestv's thread. If he views it differently, then I will defer to that.

The branch that I made is still mostly his code, and still defaults to including a 0.5% donation to him. I'm not trying to steal p2pool away from him; I'm just trying to keep the project alive even though the official maintainer and sole github committer is inactive.

Bugs first, binaries later.