P2Pool release 17.0 - commit hash: 62fa7b020b82a92138d7652c26be2953b26fd4e5

HARDFORK - Upgrade URGENTLY required in the next few days.

Windows binary: http://u.forre.st/u/iqvaqprd/p2pool_win32_17.0.zip
Windows binary signature: http://u.forre.st/u/ysrjpsls/p2pool_win32_17.0.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/17.0
Source tarball: https://github.com/forrestv/p2pool/tarball/17.0

Changes:

* SegWit compatibility
* Increased new transactions size limit per share to allow producing larger blocks
* Requires Bitcoin >= 0.13.1

SegWit (segregated witness) **has already activated** and for P2Pool to continue working without producing invalid blocks, everyone needs to upgrade. At 50% of our hashrate upgrading, P2Pool instances will start displaying a warning saying that an upgrade is required. Reaching that point as quickly as possible is very important. And then, at 95%, users that have not upgraded will be excluded. If non-upgraded users aren't excluded soon enough, P2Pool users will be subject to paying other users for invalid work - effectively a withholding attack.

Due to SegWit already activating upgraded users of P2Pool must not mine SegWit transactions as they are incompatible with older P2Pool versions. After v17 shares activate a new release will be made which removes this restriction.

So, please upgrade to 17.0 now and also tell everyone else to.

I don't see anything wrong with jtoomim's posts here.

With regard to development efforts, jtoomim: I'll merge any pull requests from you from now on that pass a quick review (I don't have means to test currently). If you want, we can discuss giving you push access to https://github.com/p2pool/p2pool.

ck-'s point about making a new thread may make sense if jtoomim takes over and creates new releases, as he'll be unable to directly edit the first post of this thread that links to them.

Shares are compared using the total work of their 5th parent, rather than their own work (data.py line 836). As a result of that, practically, forks are chosen between based on height with arrival time breaking ties. Difficulty doesn't come into it.

Can you correct that in your post? I think most of your arguments are unaffected.

Hey, jtoomim. All of what you described (including the edit) are not bugs.

First of all, remember that orphaned shares are not inherently bad. If everyone on P2Pool has the same orphan rate, then everyone's payouts are fair. Now, with that in mind...

Here's an example scenario:
(letter is share ID, number is block it refers to)

You noticed that a node will always prefer building off of C2 rather than B1, even if C2 came in way later than B1. I think that most would agree with this policy, on the basis that C2's work is much more useful, since it was entirely on a new block, instead of possibly partially on an old block (and therefore possibly partially useless). You implied that you agree with this, so I won't go any further.

Given that rule, the optimal (selfish) strategy for any node mining is to try to make a share C2 if it doesn't exist yet (assuming B1 isn't theirs), since they will benefit from the pool ignoring share B1. This situation is when the "Punishing share for Block-stale detected!" message is printed.

Doing anything else, as you proposed, would (slightly) disadvantage the people doing it. If the software didn't follow the optimal strategy by default, people would be (slightly) motivated to patch their P2Pool instances to implement the optimal strategy. Right now, every node follows the optimal strategy, and so we're at a Nash equilibrium. Everyone does everything the same, so all is fair, and there's nothing better to do.

Yes, the current strategy results in one share being orphaned per block (the last share that was mined for a given block). However, the current state of things:

• Is unavoidable, by the argument above
• Is still fair (just a slight variance increase) if everyone gets the new blocks at the same
• Punishes people with slow bitcoind instances in a manner that I believe is fair (which is good for the pool, as people with fast bitcoinds aren't paying those with slow bitcoinds for useless work)

Also, note that a node will not try to orphan a share if it has the same payout address as theirs, so running a few nodes with the same payout address won't disadvantage you compared to running a single node.

Ah, oops. I misread max as what it used to be (min). Great, so that's not a problem.

---

sawa, you shouldn't be using the fork right now. The main branch does everything you could want right now (namely, just indicate SegWit support). A majority of P2Pool hashrate using a fork will indeed confuse other miners.

Hi all. As windpath said, I'm not very active with Bitcoin recently. However, I will continue to merge/develop, test, and release changes necessary to keep P2Pool working with any Bitcoin hardforks.

There's an issue tracking SegWit support in P2Pool here which references veqtrus's awesome work adding SegWit support.

I don't plan to merge/test/release that until it looks like SegWit activation is actually happening, which according to http://segwit.co/, won't be in the near future.

---

As a separate issue, I now realize that current P2Pool doesn't allow *expressing* support for SegWit, due to line 372 in work.py, which veqtrus's changes don't touch:


If anyone can confirm that fixing that is as simple as changing it to


, then I will publish a new P2Pool release with that change.

It should run fine with Bitcoin Classic...

EDIT: I don't really know. I assumed Classic would support and indicate that it provides support for the upcoming softforks, but I don't know.

For the Bitcoin network, yes. For other P2Pool networks, no requirements were changed.

P2Pool release 16.0 - commit hash: d3bbd6df33ccedfc15cf941e7ebc6baf49567f97

HARDFORK - Upgrade URGENTLY required in the next few days.

Windows binary: http://u.forre.st/u/wanckfqm/p2pool_win32_16.0.zip
Windows binary signature: http://u.forre.st/u/wqjnuihh/p2pool_win32_16.0.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/16.0
Source tarball: https://github.com/forrestv/p2pool/tarball/16.0

Changes:
* CSV compatibility
* Requires Bitcoin >=0.12.1

Several BIPs will take effect in the next few days and in order for P2Pool to continue working without producing invalid blocks, everyone needs to upgrade. At 50% of our hashrate upgrading, P2Pool instances will start displaying a warning saying that an upgrade is required. Reaching that point as quickly as possible is very important. And then, at 95%, users that have not upgraded will be excluded. If non-upgraded users aren't excluded before the Bitcoin changes takes effect, P2Pool users will be subject to paying other users for invalid work - effectively a withholding attack.

So, please upgrade to 16.0 now and also tell everyone else to.

Hey squidicuz, I started an issue to track this problem: https://github.com/p2pool/p2pool/issues/305

Can you upload a more complete section of your P2Pool log file? Ideally an hour behind and forward or so?

When P2Pool learns that there's a new block, it mines empty blocks until bitcoind gives it a block template.

The alternative to doing this would be to mine orphaned blocks rather than empty ones. :/

If someone appears to have gotten paid, it's just because they still had shares in the sharechain (which is several days long).

As of a few days ago, outdated miners are excluded from the Bitcoin P2Pool. There's no problem or changes required.

Ah, okay, fixed in git HEAD. You probably should be using a release if you want stability, FYI. (To do that, look at the output of "git tag" and then "git checkout" the latest one.)

Can you post the error/traceback you're getting from P2Pool?

Yes.

You need to be upgraded to the newest P2Pool version (v15.0, to support v4 blocks/BIP65) and then also make that change (if you want to support Bitcoin XT).

Hmm, can you apply this[1] patch to P2Pool and post the relevant log sections of both bitcoind and P2Pool?

1: http://im.forre.st/pb/80707844.txt

P2Pool should immediately call getblocktemplate after it knows that there is a new block. It is notified that there is a new block via its P2P connection to bitcoind, through which bitcoind sents an inv message when it has a new block. The code that does this is the work_poller in node.py. The reason that you saw a 18 second delay is something within that loop. Maybe bitcoind was lagging and took a long time to announce the block after it printed "new best"? Or maybe P2Pool was lagging and took a long time to respond. Is the delay always long or just for this one block?

That said, P2Pool will generate its own work if it knows that there is a new block (via its P2Pool peers) and bitcoind hasn't given it new work yet. These blocks will be empty, though. It's just a stopgap solution for bitcoind sometimes taking a long time to catch up.

In other news, a lot of users (or one big user) upgraded to v15 in the last day, and we'll probably be fine when BIP65 takes effect.

Okay, can you post the output of the RPC getinfo command?