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

Just a thought, why aren't payouts split by straight valid hashpower between blocks? Is it too easily fudged? Too naive?

P2Pool already logs hash area, and I've been using that to dish out merged coin rewards, and while there might be a problem with that, I don't know what it is.

Thanks, nice post, good constructive feedback. I read that Kano now has a working driver for the s2 but I think he has yet to solve the p2pool issue. I'm sure he will.

He is one of our greatest allies in regards to hardware support via cgminer. I hope we can convince more people like him and/or hardware devs to build in p2pool support.

The problem is finding a dev who is familiar with python, bitcoin & the p2pool idea who doesn't want a large payout for doing the work. Trust me, I tried it a year or so ago here:  https://bitcointalk.org/index.php?topic=213051.0 - it ain't easy.

I actually found a dev who was willing to do it - but at a price, which I didn't have. I also had doubts about his ability & reasons for doing it.

The only difference between now & then is that now it seems that people are in agreement - back then when I dared to disagree & voice my concerns about the lack of development (over a year ago!) forrestv was considered some kind of demi-god, an untouchable, he could do no wrong. He also used to post every now and again back then......I was scorned - how dare I say such blasphemous things.....

Now look at us. Funny how things change eh?

The two biggest problems I see with p2pool are as follows:

1) Vertical scalability
2) Hardware support

By definition, p2pool does a fantastic job at scaling horizontally.  Just take a look at the latest guide and you can have p2pool, complete with merged-mining up and running with two commands.  Even if you don't follow that guide, and build everything from scratch, the amount of work to get a node up and running is pretty minimal.  Unfortunately, the failure is in the pool's ability to scale vertically.  As most pools grow in size, the variance the miners experience levels out.  Look at pools like GHash and you'll see that your payouts are pretty spot-on accurate with the "expected" payout calculators.  With p2pool, exactly the opposite happens.  The more the pool grows, the more variance the individual miner will experience.  Let's face it, as it stands now, you need to have at least 100GH/s to have an expectation of finding 1 share a day.  All of those people we are trying to convince to join the p2pool experience need to realize that the entry fee at this point is pretty much an Antminer S1.

The reason it fails to miserably at scaling vertically is due to the design of the pool's payout mechanism.  Essentially, as a miner on p2pool you are solving a block (we call it finding a share).  The structure of this block chain is very similar to the BTC block chain.  The primary difference is generation time.  The share chain is expected to find a "block" every 30 seconds, whereas Bitcoin is designed to find a block every 10 minutes.  Just like what happens to BTC difficulty every 2016 blocks, the same happens to the share chain (except more rapidly) to keep the average "block" time at that 30 second mark.  If we suddenly increase the hashing power to 1PH/s, 10PH/s, etc, the difficulty to find a share will increase correspondingly.  Then, the entry price of mining on p2pool will no longer be 100GH/s, it will be 1TH/s, 10TH/s, etc.

One possible way to address this problem is to introduce a concept of tiered nodes.  Just like the share chain is now kept to store miners/payouts/etc, we would introduce sub-chains.  Each of these sub-chains would have lower difficulty.  As miners submit shares, those shares would be evaluated against difficulty for that share chain, the one above it, and so on, right up to the BTC block chain.  Implementation would be tricky because miners would have to be restricted and directed properly to an appropriate share chain.  You wouldn't want a miner with 10TH/s hitting the share chain whose difficulty was set to handle miners with an average of 100GH/s.  Either the pool would have to dynamically adjust and put the miner on the appropriate chain based upon the miner's calculated hash rate, or it would have to outright reject the miner because of the calculated hash rate.  This is just one possible solution, and I need to think on it further to discover pros and cons of the approach, and if it would be feasible to introduce.  Comments and suggestions are most certainly welcomed.

As for hardware support, we are seeing a number of the newer manufacturers not building drivers into their hardware for p2pool mining.  A great example is the Antminer S2.  Point your S2 at a p2pool node and you'll be lucky to see 850-900GH/s.  Point that same S2 to Eligius, BTCGuild, GHash.io and you'll get the advertised 1TH/s.  Kano (one of the developers of cgminer) has been trying to build out a replacement cgminer for the S2... thus far unsuccessfully.  The last post from him was that when he pointed the latest version of his firmware to p2pool it exploded with all kinds of errors, both on the miner and on the p2pool node.  We need a developer who can work closely with ckolivas/kano/Luke-jr to ensure that p2pool is compatible with the new hardware releases.  As a hardware manufacturer, what is going to be my best bet?  Developing firmware for a pool that makes up a tiny portion of the network, or ensuring my hardware works well with pools that represent 80% of the network's total hash rate?  Those aren't trick questions... it's easy.  As a manufacturer, you work with the 80.

OK... that's my 2 satoshi.

Some people don't know this, It wasn't targeted at you.

IYFTech, yes I don't know, neither do you! so great! we agree, lets stick to fact.

Fact is we need some dev to push p2pool forward. What do we need and how can we best go about it. I think we can safely give up on forrestv.

mdude, thanks, that's a nice little purse pocket.

All, I think we should stop bickering between each other and complaining about forrestv and make something happen.

I'm trying to motivate you all to get a list of clear requirements together and find a way of getting it done. We need to go out and ask for help.

P.s. the guide I followed had a clear mention of the --give-author 0 option, I've had it configured since day one and I was very new to p2pool when I found it.

Yup  

Thank you for pointing out the blindingly obvious to a noob like me 

The author donate address is in the code, isn't it?  Last I looked it had received about 36 BTC since its inception. 

I may have the wrong address of course.

M

If any.....   Well, for a start, everyone who followed murdof's excellent guide (https://bitcointalksearch.org/topic/how-to-run-your-own-p2pool-in-ubuntu-1404-lts-with-merged-mining-651819) is unknowingly/knowingly donating to invisible-dev, because there is unfortunately no mention of how to switch it off. That's going back a week. Now, work out how many weeks p2pool has been active & that will give you a fairly good idea of how many users are unknowingly/knowingly donating to invisible-dev.

As for the rest of your statement - the reason you have to use words like "hypothetically", "assume", "pretend" & "I wonder" is because you don't know. The reason you don't know is because invisible-dev does not communicate with anyone whatsoever - nobody knows. That's why I prefer to go with facts - I go by what I see, and I haven't seen anything major happen with p2pool for over a year. That makes it stone age in software terms, and is why hardly any of the newer hardware coming out will work with it.

That is what needs to be put right, not add another insignificant alt-coin & disguise it as "development" in an effort to bump up dwindling donations by unsuspecting users.

https://github.com/forrestv/p2pool

you can follow dev going on here, there is a mailing list and a place to submit issues. code was updated 3 months ago.

Again, I'm calling for p2pool node users, owners and others to think this through logically and identify what exactly needs doing. then lets take control and reach out to find someone to help us with those requirements.
Let's work out a way to make it attractive for a dev to do some work on p2pool.

Question: What would you rather have?

a) The ability to mine BTC on p2pool with whatever hardware you have/choose without issue?

b) The ability to mine another coin that nobody really uses with a very limited selection of mining equipment with issues?

I'll take a.

I wonder how many nodes (if any) actually donate. Everyone seems to assume that forrestv is making a motza on donations but I fear it may be grossly overestimated.

Let's say, hypothetically, that no nodes (or a couple of very small ones) are donating. Let's assume this has been the way for some time now, I mean the setup guides all talk about being able to turn off donations.

Now lets pretend we are forrestv, we are taking no donations and every time we visit this thread someone is complaining about no dev going on.

I wonder how many people, in that situation, would feel like doing any dev work for p2pool.

What I am interested in is identifying the issues. Let's list them out and try to point out what part of the code or at least what part of the logic, the issue is in.
Like a list of requirements for p2pool v2.

Let's then try to get those requirements out, say by logging issues in github and then sharing it around as an active call for devs.

Now, lets try to formulate some kind of incentive for devs to do this. How can we attract devs to p2pool to do some work for us?

Maybe we take a donation drive with some kind of escrow that is a bounty for devs to complete the listed requests.

Can we start doing that? actually being constructive.

Let's make a list, what is the most pressing bug/issue/missing feature from p2pool?

The motivation is getting p2pool to be #1 & decentralising the network.

The reward is donations from users for development. No development=no donations & a tiny pool that struggles to find users.

Edit: I've been using a custom bitcoind data location for nearly 2 years. It's not new.

Talk about ungrateful, isn't this a change on the main branch? It allows a custom bitcoind data location. That seems useful to me!
I honestly don't blame devs for not working on p2pool. I mean what's the motivation, what's the reward?

No, it isn't better than nothing. It is nothing. Anyone with coding experience can add another coin - look at raven_pl's p2pool fork - it's got loads of coins. Adding another coin is not development - it's just another coin that people can't mine because of hardware incompatibility problems. Development is addressing issues, answering questions, posting findings/suggestions & communicating with the users of p2pool.

Adding another coin that has no major user base, following or general use - on a scale of 1 - 10 - is about #100 on the list of priorities.

Development my arse.

I'm probably the pool in the UAE. =) I run a public bitcoin node and a private p2pool instance on one of my boxes at home, mostly for my own miners.

Better than nothing, maybe some appreciation could motivate more to contribute and maybe even forrestv himself.

Are you kidding? Merging a 3 month old pull request by someone else can hardly be called development - more like invisible dev has noticed his donations have dropped........what a joke 

Does it get it from the current payout list? I think P2Pool pays out donations to people who would normally earn a share if a block was found now, based on their proportion of shares.

A minuscule, nothing change compared to what's needed.......10 months worth of donations to add a new coin........lol