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

[kavjlaeg]

Hi Kavjlaeg
Working OK from the UK.

Hi & welcome flameruk,
a some months ago I mined on your node too, working great from the Moscow
----------------------------------
...Russia is not only bears drink vodka and play the balalaika)

[windpath]

@jtoomim When you feel your code is tested and ready do you plan to open a PR on the P2Pool Github?

[-ck]

Maybe its the nature of p2pool's but what bothers me is the strain on my avalon A721 getting push to excessively high difficulties where it starts to under perform.
The flip side of that  is when I set my own difficulty to 4096 I can't find any shares and on several occasions have missed 4 rewards from blocks because my miner was unable to find just 1 share.

Are their any nodes that have controlled the pool difficulty as when I mine on other types of pools my miner chuggs along nicely.

So what would be the recommended difficulty to use.

The mining difficulty doesn't affect the avalon at all; it does not cause extra strain and it doesn't change your chance of finding a share. The mining difficulty is purely cosmetic in the case of p2pool and won't affect your chance at getting a reward. The only reason you're not finding a share at all for some blocks is the intrinsic design of p2pool - when the hashrate gets higher, smaller miners get lesser and lesser chance of finding a share per block. It's an unfortunate side effect of the design that it increases variance as the number of miners increases.

[jtoomim]

My attitude on the share difficulty thing is that a hybrid approach would be nice. It would be nice to maybe calculate (a) the difficulty needed to have shares last three days, (b) the difficulty needed to have shares last for an expectation of 3 blocks, and then take e.g. the geometric mean of (a) and (b).

Ultimately, we need to minimize total variance to the end-user. As there are two components (share variance and block variance), we need a formula for the difficulty that balances those two needs.

I've also been playing with some ideas that could dramatically reduce the orphan rates and CPU/memory loads of p2pool. If I implement some of those and they work out, then we might be able to reduce the share time and increase the share chain length, which would allow lower share variance and also lower block variance at the same time. But that's pie in the sky still.

@jtoomim When you feel your code is tested and ready do you plan to open a PR on the P2Pool Github?

Maybe. I find myself attracted to the idea of having commit access to the actively used repository, so part of me wants to just keep it as a code fork so that I can more easily do further development when the mood hits me. But if people would prefer to have it be in the p2pool/p2pool repository (with consequently fewer updates), then I guess I'd go ahead and submit the PR.

People are welcome to submit PRs to my repo, of course.

[frodocooper]

Those were the days when a share used to be valid for 3 days. Everyone was whining at the time that its too difficult to find a share and then it was adjusted so a share is nowdays valid for a day. It doesnt help if a big miner raises his shares to max which is 30x the minimium. Its like flooding the system with tiny shares. And no you dont get paid for every share you get like you should because shares are too fucking small and small shares flood the system.. But share should be valid not 3 days but somewhere near the shares needed to get 2 blocks, 1 block at least which was earlier today 8 days for 1 block now its 7.9 days - so difficulty should be so that shares would be valid for lets say 12 days. Then it would be like fun to get few shares and then few blocks..

Could you kindly point me to some reliable resources that show P2Pool's share lifespan being reduced from approximately three days to one day? P2Pool.org currently says that "a share in the P2Pool sharechain can be expected to last about 3 days (8,640 shares * 30 seconds = 3 days)" under "How do I get paid?".

Also, having a large miner raise his or her share difficulty to 30x the current minimum doesn't flood the sharechain with tiny shares. It does the opposite; the miner would be submitting fewer, but higher-difficulty and therefore higher-value, shares to the sharechain. Furthermore, large miners are encouraged to send higher-difficulty shares so that smaller miners would still stand a fair chance at having accepted shares — this method helps mitigate the impact of large miners on P2Pool's minimum difficulty, enabling smaller miners to still have a fair chance of submitting accepted shares.

You do get paid for every accepted share in the sharechain, according to the difficulty of those shares. Higher difficulty shares are worth more, and therefore pay out more. And you can't "flood the system" with shares; the sharechain is only as long as the last n shares, with the n being approximately 8,640 (unless this information is outdated). Anything more, and older, than that is disregarded and discarded.

[flameruk]

Hi.

Ive Git Cloned the jtoomim hardfork and am getting a connection to a couple of peers.
It says "downloading shares" but I get no "processing xxxx".
Fell to sleep in the end last night and still the same this morning.
Any ideas???

Code:

2017-05-06 08:01:18.912855 > Unhandled Error
2017-05-06 08:01:18.912969 > Traceback (most recent call last):
2017-05-06 08:01:18.913024 >   File "/home/p2pool/p2pool/p2pool/main.py", line 666, in run
2017-05-06 08:01:18.913081 >     reactor.run()
2017-05-06 08:01:18.913134 >   File "/usr/lib64/python2.7/site-packages/Twisted-12.1.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 1169, in run
2017-05-06 08:01:18.913189 >     self.mainLoop()
2017-05-06 08:01:18.913260 >   File "/usr/lib64/python2.7/site-packages/Twisted-12.1.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 1178, in mainLoop
2017-05-06 08:01:18.913316 >     self.runUntilCurrent()
2017-05-06 08:01:18.913368 >   File "/usr/lib64/python2.7/site-packages/Twisted-12.1.0-py2.7-linux-x86_64.egg/twisted/internet/base.py", line 800, in runUntilCurrent
2017-05-06 08:01:18.913423 >     call.func(*call.args, **call.kw)
2017-05-06 08:01:18.913473 > --- <exception caught here> ---
2017-05-06 08:01:18.913528 >   File "/home/p2pool/p2pool/p2pool/bitcoin/stratum.py", line 38, in _send_work
2017-05-06 08:01:18.913581 >     x, got_response = self.wb.get_work(*self.wb.preprocess_request('' if self.username is None else self.username))
2017-05-06 08:01:18.913635 >   File "/home/p2pool/p2pool/p2pool/bitcoin/worker_interface.py", line 129, in get_work
2017-05-06 08:01:18.913691 >     x, handler = self._inner.get_work(*args)
2017-05-06 08:01:18.913744 >   File "/home/p2pool/p2pool/p2pool/work.py", line 245, in get_work
2017-05-06 08:01:18.913799 >     raise jsonrpc.Error_for_code(-12345)(u'p2pool is downloading shares')
2017-05-06 08:01:18.913853 > p2pool.util.jsonrpc.NarrowError: -12345 p2pool is downloading shares

Also my node reports Version: 15.0-5-g6f55d05-dirty
Have I git cloned the wrong version here, Ive looked around some of the hardforked nodes there seem to be many different versions?

[in2tactics]

Maybe its the nature of p2pool's but what bothers me is the strain on my avalon A721 getting push to excessively high difficulties where it starts to under perform.
The flip side of that  is when I set my own difficulty to 4096 I can't find any shares and on several occasions have missed 4 rewards from blocks because my miner was unable to find just 1 share.

Are their any nodes that have controlled the pool difficulty as when I mine on other types of pools my miner chuggs along nicely.

So what would be the recommended difficulty to use.

The mining difficulty doesn't affect the avalon at all; it does not cause extra strain and it doesn't change your chance of finding a share. The mining difficulty is purely cosmetic in the case of p2pool and won't affect your chance at getting a reward. The only reason you're not finding a share at all for some blocks is the intrinsic design of p2pool - when the hashrate gets higher, smaller miners get lesser and lesser chance of finding a share per block. It's an unfortunate side effect of the design that it increases variance as the number of miners increases.

Well stated. However, I have observed the dropping of entire hashing boards or the temporary failure of a string of chips from my S7LN miners while mining on p2pool WITHOUT a manually specified difficulty. The issue would occur when p2pool changed difficulty both rapidly and frequently. The issues were temporarily resolved by cycling the power and completely resolved by using the "+2048" option.

With regard to notabeliever's specific problem, I would say that there must be some other issue at play. The A721 should have easily found a share during the time frame specified. I personally was finding many shares with only 2x S7LN. I would bet that either the payout address was incorrect or the node was collecting a 100% fee.

Forgive me for unleashing this rant. I really needed to get it off my chest.

I am glad you feel better.

[-ck]

Well stated. However, I have observed the dropping of entire hashing boards or the temporary failure of a string of chips from my S7LN miners while mining on p2pool WITHOUT a manually specified difficulty. The issue would occur when p2pool changed difficulty both rapidly and frequently. The issues were temporarily resolved by cycling the power and completely resolved by using the "+2048" option.

With regard to notabeliever's specific problem, I would say that there must be some other issue at play. The A721 should have easily found a share during the time frame specified. I personally was finding many shares with only 2x S7LN. I would bet that either the payout address was incorrect or the node was collecting a 100% fee.

It's well known that the extra block changes happening effectively every 30 seconds on the p2pool chain unlike bitcoin at 10 minutes leads to more fluctuations in effective hashrate on most hardware and unfortunately the avalon2+ designs do stratum on the inbuilt fpga on the devices because they were designed to be bundled with extremely low power Rpis that aren't up to generating the amount of work these devices hash at the software level. Moving stratum to the fpga means the change takes longer and is a little more prone to misbehaviour as a result. I'm not saying the antminers are much better as they have their own crazy design issues but either way p2pool work is more tricky for hardware to manage than the regular block chain. Newer hardware at least doesn't cut the power on changing blocks till there was new work the way old hardware does; the more the power levels were fluctuating to the chips, the more prone they were to failure.

[in2tactics]

It's well known that the extra block changes happening effectively every 30 seconds on the p2pool chain unlike bitcoin at 10 minutes leads to more fluctuations in effective hashrate on most hardware and unfortunately the avalon2+ designs do stratum on the inbuilt fpga on the devices because they were designed to be bundled with extremely low power Rpis that aren't up to generating the amount of work these devices hash at the software level. Moving stratum to the fpga means the change takes longer and is a little more prone to misbehaviour as a result. I'm not saying the antminers are much better as they have their own crazy design issues but either way p2pool work is more tricky for hardware to manage than the regular block chain. Newer hardware at least doesn't cut the power on changing blocks till there was new work the way old hardware does; the more the power levels were fluctuating to the chips, the more prone they were to failure.

Understood. I perhaps focused my original response on the wrong issue. I was more concerned with the fact that notabeliever found 0 shares during a time period of 4 block finds.

[veqtrus]

But, with a share size limit lower than 1MB; I would go for veqtrus' suggestion of 250kB per 30 seconds, or even 500kB. I agree with veqtrus that 1MB per 30 seconds is a little too much, especially for smaller nodes. They could potentially lose out significantly in terms of orphan rates.

Nevertheless, I also agree with jtoomim that the current 100kB share size limit is simply too small to meet Bitcoin's current demands. Transaction capacity is bursting at the seams and P2Pool should not be a bottleneck in Bitcoin's transaction processing, which it currently is — we seem to be consistently mining smaller-than-average blocks.

P2Pool's current limit is 50 kB, the 100 kB value is what I added to my segwit PR before jtoomim even suggested increasing it. I would be okay with 250 kB though.

I have a PR which lets users add text to their coinbase. I suggest people interested in the topic set it to something like /SZ250KB/ so that we can have some statistics.

[frodocooper]

I have a PR which lets users add text to their coinbase. I suggest people interested in the topic set it to something like /SZ250KB/ so that we can have some statistics.

Is there a simpler way of voting? I'm not a programmer — I assume that not every P2Pool node operator is a programmer too — and the only things I know how to do on GitHub are cloning the main repository and downloading releases. I also have no idea how to add text in my coinbase, let alone install a pull request (I hope that's the correct phrase for it). I would prefer to avoid tinkering in the bowels of my P2Pool node and/or Bitcoin node, for fear of messing up things that shouldn't be messed with.

That said, and for what it's worth here, I vote for the 250 kB share size limit.

[jtoomim]

frodocooper, please note that my fork includes several improvements, not just a change to the maximum number of transactions per share, and consequently actually has a significantly *lower* share orphan rate than the p2pool mainnet. I don't have any good data on whether jtoomimnet is more fair or less fair than mainnet as of yet, but preliminary data suggests that it's about the same or slightly better.

As for the voting, I'm not sure there was any point. If anyone wants to mine on a share chain that allows less than 1 MB of new transactions per share, then there needs to be two separate share chains, because there is at least one miner (me) who chooses not to mine on anything less than full blocks. Rather than have one chain on which everyone compromises, why not just have two chains to satisfy everyone's goals?

Also, there are plenty of methods by which share network traffic can be reduced or taken out of the latency-critical path. I would prefer to just make shares propagate faster regardless of size rather than organize a vote on how much to cap our block sizes.

Edit: Sorry if I came off as irritable earlier. I'm just tired of politics getting in the way of fixing the code. I think that forking, as a permissionless process, is just socially easier to deal with than trying to get consensus, and in the case of p2pool, it has very few disadvantages. This way, I can just write code, and if you think it's better, you can use it. It's really simple that way. I don't have to worry about writing the code and having it never be used, since I know that I will use it even if nobody else does. And users don't have to worry about voting on features they don't understand; they can see the new code already running before they decide whether or not they like it and want to make a switch.

[jtoomim]

Those were the days when a share used to be valid for 3 days.

Could you kindly point me to some reliable resources that show P2Pool's share lifespan being reduced from approximately three days to one day?

nreal is incorrect. Shares are currently valid for approximately 3 days. P2pool targets a difficulty for one share every 30 seconds, with 8640 shares valid at a time. 30 sec * 8640 / 3600 = 72 hours.

https://github.com/p2pool/p2pool/blob/master/p2pool/networks/bitcoin.py#L10

Previously, p2pool targeted one share every 10 seconds, with 8640 shares valid at a time, for a 24 hour window, but share orphan rates were too high, so forrestv slowed the shares down by a factor of 3.

It's worth mentioning that 30 seconds is what the default share difficulty will target. Individual miners have some leeway to override this share difficulty target (as long as it doesn't go below some pool-wide minimum). I'm not happy about that, as it seems like it could be used for selfish mining attacks or to flush out a competitor's shares from the share chain if they stop mining suddenly.

I could add some code based on https://github.com/donSchoe/p2pool-n/pull/6 to determine a per-miner share difficulty based on their hashrate, so that fewer shares would be issued by large miners and more shares by small miners (thereby minimizing share variance for those who are most affected by it). I'm a little concerned that it might increase the incentive for large miners to modify the codebase in order to do selfish mining, though, so I may wait on that until after I've improved share processing/propagation times and gotten rid of most of the orphan share fairness problem.

[in2tactics]

Those were the days when a share used to be valid for 3 days.

Could you kindly point me to some reliable resources that show P2Pool's share lifespan being reduced from approximately three days to one day?

nreal is incorrect.

We knew that already, but thanks for piling on. LOL

[windpath]

Feels like a Scooby Doo caper, but actually your both wrong  

I need to update the description on p2pool.org, and do not have the patience to find the code snippet on my phone, but the share chain length is kind of dynamic. While it stays close to three days, if I remember correctly both share weight and the "spread" change it to be less then 3 days under certain circumstances.

The real answer is both deep in this thread, and in the code... I'll spend the time to dig it out and update the site on Monday, unless someone feels like linking the code here before then

[frodocooper]

frodocooper, please note that my fork includes several improvements, not just a change to the maximum number of transactions per share, and consequently actually has a significantly *lower* share orphan rate than the p2pool mainnet. I don't have any good data on whether jtoomimnet is more fair or less fair than mainnet as of yet, but preliminary data suggests that it's about the same or slightly better.

As for the voting, I'm not sure there was any point. If anyone wants to mine on a share chain that allows less than 1 MB of new transactions per share, then there needs to be two separate share chains, because there is at least one miner (me) who chooses not to mine on anything less than full blocks. Rather than have one chain on which everyone compromises, why not just have two chains to satisfy everyone's goals?

Also, there are plenty of methods by which share network traffic can be reduced or taken out of the latency-critical path. I would prefer to just make shares propagate faster regardless of size rather than organize a vote on how much to cap our block sizes.

Edit: Sorry if I came off as irritable earlier. I'm just tired of politics getting in the way of fixing the code. I think that forking, as a permissionless process, is just socially easier to deal with than trying to get consensus, and in the case of p2pool, it has very few disadvantages. This way, I can just write code, and if you think it's better, you can use it. It's really simple that way. I don't have to worry about writing the code and having it never be used, since I know that I will use it even if nobody else does. And users don't have to worry about voting on features they don't understand; they can see the new code already running before they decide whether or not they like it and want to make a switch.

Point taken, jtoomim. I too apologize if I offended you in any way; my intention was simply to get the point across that there is almost always never an optimal solution, but there is almost always a better one. In the case of P2Pool, and Bitcoin in general, my personal belief is that compromise is almost always the better solution, compared to hard-forking.

But nevertheless, you do make very good, and reasonable, points. And I'll respect that, even if I do not agree with all of them. . (Also, I'm not a programmer, so I may have skimmed over much of the finer workings of your code, simply because I do not understand code. I do apologize if I made unfair and unfounded generalizations.)

Feels like a Scooby Doo caper, but actually your both wrong  

I need to update the description on p2pool.org, and do not have the patience to find the code snippet on my phone, but the share chain length is kind of dynamic. While it stays close to three days, if I remember correctly both share weight and the "spread" change it to be less then 3 days under certain circumstances.

The real answer is both deep in this thread, and in the code... I'll spend the time to dig it out and update the site on Monday, unless someone feels like linking the code here before then

Yeah, the P2Pool page on the Bitcoin wiki does say that "Each share contains a generation transaction that pays to the previous n shares, where n is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 8640 (= [72] hours of shares), whichever is smaller."

I'm still confused as to what the first part means.

(By the way, the P2Pool Bitcoin wiki page needs to be updated. It still says that shares are valid to at most 24 hours, among other outdated information.)

[windpath]

> whose total work is equal to 3 times the average work required to solve a block, or 8640

That's it, thanks! "3" is the "spread" from the network config file...

[keke51]

Dear PROs, can someone post an instruction on how to start jtoomims forked node. I cloned one from github, run it - and it keeps saying "Unknown share type 16"
I got usual p2pool node on that machine and it worked fine.

[frodocooper]

Dear PROs, can someone post an instruction on how to start jtoomims forked node. I cloned one from github, run it - and it keeps saying "Unknown share type 16"
I got usual p2pool node on that machine and it worked fine.

Hello, keke51. You need to connect your node to one of the jtoomimnet nodes, using the "-n [url:port]" command-line option. jtoomimnet's sharechain is incompatible with mainnet's sharechain, which is why you're getting the "Unknown share type 16" error. jtoomimnet's protocol version number is 32; mainnet's is 16.

For example, here are instructions for connecting your node to jtoomim's node, among others:

...
To connect to me: run_p2pool.py -n ml.toom.im:9333
...

You are also encouraged to publicly share your node details here, once you've set up your node. It would go a long way in helping jtoomim with the further testing of his fork.

If you want to contribute to the networked chain for share propagation testing, please clone https://github.com/jtoomim/p2pool/commits/1mb_hardforked, then configure your node to point to the previous poster's node (e.g. python run_p2pool.py -n previous_node), then list your node IP, what it's connected to, what type and speed of CPU you're using, how fat your pipe is, and whether you're using pypy or CPython (the regular python). Example, and to start us off:

Node IP: ml.toom.im (default ports)
Connected to: ml.toom.im:9334 and :9336 (or :9335 and :9337 for p2p ports)
To connect to me: run_p2pool.py -n ml.toom.im:9333
CPU: Core i7 4790k 4.0 GHz
Pipe: 100m/100m fiber
Using: pypy 2.4.0

[keke51]

Thank you very much, I bet Im loading shares. So:
Node IP - 141.136.115.230:9333 (standart port, 9332 - worker port)
Gear: macmini 2012 (i5 2.4ghz) MacOS:)
Located in Moscow, Russian Federation
Connected to ml.toom.im:9333
Pipe - 40mbs wire
to connect to me use run_p2pool.py -n 141.136.115.230:9333