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

[smooth]

No it doesn't. The probability that a block will be found on the next attempt (ignoring various constant scaling factors) is 1/D. It is independent of M.

By "on the next attempt" do you mean on the next share, or on the next level of the DAG, or something else? If you mean on the next share, then you need to multiply by M/N to correct for the expected number of shares per DAG level. According to PPLNS, your share only gets kicked off after a certain number of DAG levels, so you get multiple "attempts" per level.

Are all shares paid equally, or is this a scoring-based system?

I think if I am reading correctly, all shares are paid equally. That means during periods that M is higher due to random variation, the value of mining on the pool is lower. During periods that M is lower, the value of mining on the pool is higher. The steady-state average is not what matters here because the miner can choose to participate only during certain system states.

If you attempt to apply a score to correct for this, you can do that, but then you have the issue of how to score multiple shares at the same level. To do this fairly and unexploitably, you need an order. Back to square one.

[1714199658]

1714199658

[jtoomim]

Are all shares paid equally, or is this a scoring-based system?

Shares are paid in proportion to their difficulty. You take the difficulty for a share, divide by the summed difficulty of all shares among the last M (or N for vanilla p2pool), and multiply by the block reward for that block (including fees), and that gives you the reward a share would receive for that block if it were found.

I think if I am reading correctly, all shares are paid equally. That means during periods that M is higher due to random variation, the value of mining on the pool is lower. During periods that M is lower, the value of mining on the pool is higher. The steady-state average is not what matters here because the miner can choose to participate only during certain system states.

In periods where M is higher due to random variation, the probability of a share getting rewarded by another share finding a block increases, but the payout size decreases. These effects cancel out.

For example, if M is 4 (and all shares are the same difficulty), then if I mine a share, it will have 4 chances of probability 1/D to earn 1/4 of a block. If M is 256, then my share will have 256 chances of probability 1/D to earn 1/256th of a block. In either case, the expected revenue is the same.

The problem comes not when M is higher or lower, but when M is rapidly changing.

A share will be payable for a considerable amount of time, and M might change during that time. For example, if N is 4, my share will have its potential reward calculated 4 different times as it travels through different levels of the DAG. Let's say that we start with 1 share per level in all 4 levels of the DAG when my share is mined (my own share being the top level). After this, 1 more level is mined with 1 share per level, and then a level with 5 shares is mined, followed by another two levels with 1 share. The first chance I have to get paid comes from my own share, where the DAG looks like this:

Round 0:
1*
1
1
1

I get one 1/D chance of getting a 1/4-block reward here. (The asterisk denotes my share.) Next round:

Round 1:
1
1*
1
1

1/D chance of getting a 1/4-block reward.

The next round is a bit tricky. Five shares are mined at once, but since they aren't yet aware of their siblings, each one sees the top level of the DAG as having only one share:

Rounds 2a-2e:
1
1
1*
1

Five 1/D chances of getting a 1/4-block reward. Finally:

Round 3:
1
5
1
1*

One 1/D chance of getting a 1/8-block reward.

Total expected reward = 2*(1/4D) + 1*(5/4D) + 1*(1/8D) = 15/8D blocks. The fair reward would be 1/D blocks.

The above was a rather contrived and extreme example. I wrote a script to simulate the rewards for a N=2016 PPLNS system with between 1 and 10 shares per level, and the typical revenue per share varies by less than 1%, with the maximum I've seen being 2.6%.

Again, you can't hop based on this, because it depends on events that happen after you mine a share, which can't be predicted. It's a selfish mining vulnerability, but not a hopping vulnerability.

And also again, this variation is completely eliminated by the PPLKD scheme I described earlier.

[jtoomim]

If you attempt to apply a score to correct for this, you can do that, but then you have the issue of how to score multiple shares at the same level. To do this fairly and unexploitably, you need an order. Back to square one.

It's actually quite simple to fairly order shares within a level, as long as you don't care whether the ordering is chonological. For example, you can sort the shares by their hash -- lowest hash (closest to mining a block) comes first. Fair, simple, easy, and unnecessary.

It's also trivial to make a DAG with a constant M/N ratio. Instead of allowing shares to specify as many uncles as they want, you can force each share to specify exactly K parents, and create a rule where the parent with the lowest hash is the canonical parent, and only the canonical parent's parents are counted as grandparents. Fair, simple, easy, and unnecessary.

The best solution is just to make sure that the portion of the share chain that's used for calculating rewards always represents the same amount of work. This puts the fewest restrictions on the DAG structure, and ensures that the ratio of the numbers that actually matters -- the amount of work used to calculate the size of the payout, and the amount of work done by others that would have made the payout -- remains a constant 1.0. As in the PPLKD scheme I described earlier.

[smooth]

This reminds me very much of the arguments I used to have 5 years ago when people denied that pool hopping worked at all.

It was tedious then and it is tedious now. The problem is that logical falacies involving probability are subtle and difficult to explain convincingly if you lack a formal background.

I may return to the discussion later, or I may not. Either way, I'm pretty sure you are incorrect, but I'm not the one working on a project based on a faulty model, so its not really my problem. It may also be fixable without drastic changes (your later post that showed up while I was typing this may be sufficient, or close enough), but it will almost certainly be more complicated and probably still vulnerable to something. It is also possible, somewhat, that I'm still misreading what you are proposing. I don't think so though.

BTW, I was always assuming a constant difficulty for each share for simplicity of description, but that doesn't change anything in general.

[jtoomim]

Either way, I'm pretty sure you are incorrect

If you can specify how you think the system is flawed, I'm all ears. However, simply stating that you think it's flawed without going into any detail or even demonstrating that you understand the system is not very helpful.

[winterfresh7]

Recently got a warning that over 50% have voted for an upgrade to v16?

[jtoomim]

Recently got a warning that over 50% have voted for an upgrade to v16?

You should upgrade. Do a git pull.

I have not yet upgraded my nodes. Once I do, due to the size of my mining operation, almost all of the network hashrate will be on v16, and v15 shares will start to be rejected. It would be a good idea to upgrade before I do.

[Meuh6879]

  binaries isn't here ... https://github.com/p2pool/p2pool/releases/tag/16.0

[forrestv]

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.

[ziiip]

Which coin daemons are supported this release? Just core 0.12.1+?

[forrestv]

Which coin daemons are supported this release? Just core 0.12.1+?

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

[ziiip]

I see Classic 0.12.1 isn't supported. This just for BIP 9 compatibility or what?

[ziiip]

I suppose i'll just dirty up the code a bit . . .

[forrestv]

I suppose i'll just dirty up the code a bit . . .

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.

[ziiip]

i'm running Classic 0.12.1 and i get
coin daemon too old! Upgrade!
unless i replace the helper.py from version 15.
Was this tested with Classic?
I don't believe Classic is signaling CSV or BIP 9, they just removed the upgrade warning from the code in 0.12.1.

[veqtrus]

Classic isn't supported because it doesn't support the CSV softfork yet. Considering CSV will almost certainly reach 95% hashpower signaling before the difficulty retargets, CSV will be enforced from the start of the retargeting period after the next (in about two weeks). Unless Classic adopts CSV miners using it may have their blocks rejected.

Note that simply changing the share version to get them accepted by the P2Pool network is an attack after CSV is enforced.

[jtoomim]

Unfortunately, Bitcoin Classic has not been updated to support CSV and BIP9 yet. Consequently, it will be inadvisable to mine with it after the CSV fork activates. If you try, you will probably have any blocks that you mine get orphaned. This will make other p2pool users unhappy, as you will basically be freeloading off the others in the pool. So please don't.

You can still vote for the Classic BIP109 2 MB hardfork without running Classic. You can do so quite easily in p2pool by editing the source code to bitwise OR the block version with 0x30000000. I will be doing this myself soon. Something like this should work:

    version=max(self.current_work.value['version'] | 0x30000000, 0x30000000),

If the BIP109 vote exceeds about 10-15% of the network hashrate, or if a large miner (e.g. Bitfury or Bitmain) asks me to, I will take a week and merge in CSV, BIP9, and whatever else needs merging into Classic, if Gavin and Zander haven't beaten me to it. In the mean time, I will keep voting for BIP109 but using Core, similar to what f2pool does.

[windpath]

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.

Thanks Forrest!

CoinCadence is now running P2Pool 16

[ziiip]

Unfortunately, Bitcoin Classic has not been updated to support CSV and BIP9 yet. Consequently, it will be inadvisable to mine with it after the CSV fork activates. If you try, you will probably have any blocks that you mine get orphaned. This will make other p2pool users unhappy, as you will basically be freeloading off the others in the pool. So please don't.

You can still vote for the Classic BIP109 2 MB hardfork without running Classic. You can do so quite easily in p2pool by editing the source code to bitwise OR the block version with 0x30000000. I will be doing this myself soon. Something like this should work:

    version=max(self.current_work.value['version'] | 0x30000000, 0x30000000),

If the BIP109 vote exceeds about 10-15% of the network hashrate, or if a large miner (e.g. Bitfury or Bitmain) asks me to, I will take a week and merge in CSV, BIP9, and whatever else needs merging into Classic, if Gavin and Zander haven't beaten me to it. In the mean time, I will keep voting for BIP109 but using Core, similar to what f2pool does.

Makes sense, hopefully Classic will be updated soon. I wasn't looking forward to re-building bitcoind but looks like it's necessary.
Thanks!

[sawa]

Thanks Forrest!
In version 16.0 an issue #253 in work with pypy disappeared.
This version works correctly and has the fastest speed.