Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 50. (Read 2591916 times)

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.

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.

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.

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.

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.

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.

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.

I am glad you feel better.

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???

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?

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.

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.

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.

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 When you feel your code is tested and ready do you plan to open a PR on the P2Pool Github?

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)

Hi Kavjlaeg

Im using your hard fork node at the moment from the UK so I can mine the new chain while I re-configure my node server and do a little maintenance.
Working OK from the UK.

Theres another guy using my node at ukp2pool.uk which is going to go down for a mod to the hardfork version.
Hope you got a backup pool configured .......

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..

Without being sure I suspect the problem your having is that the Avalon can not handle P2Pools frequent work restarts. Every time a share is found (~30 seconds) the pool tells your miner to throw away what's it's working on and start fresh on the next share. This happens much more often on P2Pool, and the Avalon may not be able to handle it.

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.

Hi.

Ive been working away for a week so im missing all the "hard fork" talk on here.
I see the pool hash has dropped and read a thread that the hard fork option now has the greater hash rate.
Is it time for me to jump to the new fork?

Yes im being very lazy not reading back through the post for which I apologize right now.
Im about to head out again for a weekend job away but this is playing on my mind now.

Actually, they do. Or at least, I've been under the impression that they do.

The specified difficulty value after the "/" tells the miner to send only shares above the specified "/" value to the sharechain. If the specified difficulty value after the "/" is lower than the current P2Pool minimum difficulty, then the "/" value is ignored. So, if a miner desires to have only high-difficulty shares in the sharechain, he or she may do so using the "/" function.

The specified difficulty value after the "+" tells P2Pool to send only work of the specified "+" difficulty value to the miner, i.e., the pseudo-shares.


I'm getting a little confused here. Do correct me if I'm wrong. From what I am able to understand from your suggestion, you are suggesting that a share's lifetime be limited to the current round of mining, i.e., the sharechain is reset after P2Pool finds a block?

If that's the case, then the payout system would be more along the lines of the "Proportional" payout system rather than P2Pool's current PPLNS system. If what you are suggesting is a "Proportional"-like system, then I think it would be unfair to long-term miners, since the "Proportional" payout system is susceptible to pool-hopping.

Then again, I'm probably misunderstanding the whole discussion. Some clarification would therefore be nice, and much appreciated.

What nreal is talking about is the p2pool pseudo-shares. The "+" and "/" options do not determine what shares get submitted to the p2pool share chain.

I think you are missing the point. Setting the share life to 1 block as I suggested would make things fairer for everyone to include renters by increasing the probably that anyone mining during the current round will get a payout by the time p2pool finds its next block, but it does not guarantee it. Making the share life higher than 1 block as you suggested only serves to benefit renters by lowering their risk and decreasing potential earnings for long-term p2pool miners. I do not think that arbitrarily decreasing renter risk at the expense of loyal long-term miners is the right answer. This very topic has been a source of contention for pools since their inception and in my opinion using a share life of 1 block seems to be the best compromise for everyone.