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

[windpath]

I'm not sure, but why don't we raise funds for the development team that can do this (maybe it's a bad idea).
I think we should act more active rather than passively wait for volunteers.

This has also been discussed many times in the past, but finding a coder willing to step up (huge task) as well as people who are willing to donate has proven impossible unfortunately. I've read through this thread many times & it seems some users think that either there is no need for development because it's perfect already, or that it is some kind of crime to even think about it - so nothing happens & miners go elsewhere.

**waits for torrent of abuse**

I'm not sure this is the case.

There are qualified developers who I have spoken with that are willing to work on P2Pool, and Forrest is still around, if there was a viable proposed solution I would certainly contribute.

The real problem is solving P2Pool's scaleability challenges, and they are hard problems to solve that require inventing a solution.

I've been waiting for almost 2 years to bump my head in the shower and come up with it, but not there yet

If 100 PH/s was pointed to P2Pool today most (if not all) of the existing miners would see a huge spike in variance, and a large reduction in payout.

Share difficulty would skyrocket, and keeping a share on the chain would become very difficult for most of us.

The share chain has a finite amount of space and there is a threshold to prevent dust payments that would not even constitute a transaction fee.

You can only split the 25BTC reward so many ways in a decentralized trust-less environment, and smaller miners will always get squeezed out.

I believe that the solution may lie with sidechains and micro payments where a miner could accrue shares in some type of trust-less sidechain that would be paid out in BTC once a given threshold amount is reached.

This would allow us to increase the size of the share-chain while eliminating dust payouts from the generation transaction.

This technology does not yet exist, but perhaps we are getting closer....

[1714923378]

1714923378

[1714923378]

1714923378

[1714923378]

1714923378

[1714923378]

1714923378

[1714923378]

1714923378

[p3yot33at3r]

It's a tough nut to crack.......

[jonnybravo0311]

I'm not sure, but why don't we raise funds for the development team that can do this (maybe it's a bad idea).
I think we should act more active rather than passively wait for volunteers.

This has also been discussed many times in the past, but finding a coder willing to step up (huge task) as well as people who are willing to donate has proven impossible unfortunately. I've read through this thread many times & it seems some users think that either there is no need for development because it's perfect already, or that it is some kind of crime to even think about it - so nothing happens & miners go elsewhere.

**waits for torrent of abuse**

I'm not sure this is the case.

There are qualified developers who I have spoken with that are willing to work on P2Pool, and Forrest is still around, if there was a viable proposed solution I would certainly contribute.

The real problem is solving P2Pool's scaleability challenges, and they are hard problems to solve that require inventing a solution.

I've been waiting for almost 2 years to bump my head in the shower and come up with it, but not there yet

If 100 PH/s was pointed to P2Pool today most (if not all) of the existing miners would see a huge spike in variance, and a large reduction in payout.

Share difficulty would skyrocket, and keeping a share on the chain would become very difficult for most of us.

The share chain has a finite amount of space and there is a threshold to prevent dust payments that would not even constitute a transaction fee.

You can only split the 25BTC reward so many ways in a decentralized trust-less environment, and smaller miners will always get squeezed out.

I believe that the solution may lie with sidechains and micro payments where a miner could accrue shares in some type of trust-less sidechain that would be paid out in BTC once a given threshold amount is reached.

This would allow us to increase the size of the share-chain while eliminating dust payouts from the generation transaction.

This technology does not yet exist, but perhaps we are getting closer....

We actually had this discussion almost word for word previously .  I'm right there with you... all I've gotten is a few lumps on the head from bumping it so many times.  The idea of a side chain is interesting, but nobody's been able to come up with a way to implement it.  OgNasty and Nonnakip have done the closest thing to a solution with their NastyPoP method (ckpool combined with p2pool).  It's a decent workaround, but it's not ideal.  I've been mining on it for a year now, and have my thread comparing the results of it to standard p2pool nodes.  The biggest problem with their solution is that you lose the decentralized nature of p2pool.  Of course, if they expanded their operations from just their two current nodes, so that anyone could operate their own NastyPoP node, then we'd have something workable.

I definitely like what they've done, or I wouldn't have dedicated a year's worth of mining and time to them .

[OgNasty]

could this be the cause of the recent bad luck?

No.

[OgNasty]

Nonnakip has done the closest thing to a solution with his NastyPoP method (ckpool combined with p2pool).  It's a decent workaround, but it's not ideal.  I've been mining on it for a year now, and have my thread comparing the results of it to standard p2pool nodes.  The biggest problem with their solution is that you lose the decentralized nature of p2pool.  Of course, if they expanded their operations from just their two current nodes, so that anyone could operate their own NastyPoP node, then we'd have something workable.

I definitely like what they've done, or I wouldn't have dedicated a year's worth of mining and time to them .

The ckpool implementation was actually turned off because it was unstable with our implementation (our use of it wasn't what it was intended for and required a LOT of customization to the code).  We will hopefully be able to stabilize it for our use and implement it again in the future.  There is just a LOT of things nonnakip is working on for NastyFans and the lack of community support on NastyPool has put that project a bit on the back burner.  If more people were interested in it and wanted to participate it might be a different story.  Perhaps if it ever is stable with the ckpool implementation we could open it up to anyone who wants to run a node.  I actually approached the Toomim bros to see if they were interested in hosting a node but I think the centralized nature of our payout system is a bit of a turn off for some folks.  I had hoped that my reputation and only having 1 week of earnings on the line would be enough to ease community concerns, but it appears that it is not.

[jonnybravo0311]

...but I think the centralized nature of our payout system is a bit of a turn off for some folks.  I had hoped that my reputation and only having 1 week of earnings on the line would be enough to ease community concerns, but it appears that it is not.

I hear you.  And yet, people have no problems throwing their hash at the most centralized pools out there (Ant, Discus, etc).  It really strikes me as paradoxical.  We want decentralization, but we will gladly centralize all of our mining power to get it.  Oh well... I look forward to the stuff Nonnakip is doing.  Keep on fighting the good fight .

[-ck]

Repeating this for the maybe 20th time:

I could rewrite it in c but it would cost you a fortune to pay me since I have no interest in doing it for free as I see it as a futile task and would only do it for paid work. The reason is - rewriting p2pool in c would fix its scalability issues but would do nothing for the design of the pool having variance opposite to that of other pools - the larger the pool the MORE the variance instead of what happens at other pools. Unless someone has a design solution for this it would be a waste of time - many many many people have talked and waved their hands lots about this but come up with nothing.

[jonnybravo0311]

I was kind of referring to you -ck when I made my statements above about simply translating from Python to C not solving the inherent problem of the pool.  Sure, a node will be faster and more scalable... heck you'd probably even do something like using multiple threads ... but as you, me, and most everyone else has stated, the real problem is the variance.  Throw 100PH/s on p2pool and see how the share difficulty skyrockets and nobody with under 500TH/s mining is going to have a prayer of getting a share on the chain with any regularity.

Until that is solved, what's the point.  By the way... what is your magic number?  You state, "...it would cost you a fortune to pay me...".  Define fortune .

[-ck]

By the way... what is your magic number?  You state, "...it would cost you a fortune to pay me...".  Define fortune .

Writing in c is very labour intensive (compared to python) so it's a lot of hours work. I charge less for free software than private software since I like to encourage free software use as much as possible. At current exchange rates I charge .29 btc/hr for free soft and .38 for private software. A rough estimate of the time required to rewrite p2pool in c (properly) would be 500 hours work. That's around 150 BTC.

EDIT: By the way this would be a total and utter massive waste of money. Even if all the scalability problems were addressed AND a solution was found for the variance problem, there are no miners left to attract. The sad truth is personal miners are an increasingly irrelevant entity and what little hashrate they have cannot save any small pool. Only farms are relevant today.

[kano]

could this be the cause of the recent bad luck?

No.

His question was 'could'
The answer is 'Yes'

Any lost blocks will attribute to a lower 'pool luck'.
It's a lost block, it affects what is (incorrectly) referred to as 'pool luck'
So if there have been any (which no one will actually know) then it would have effected the 'p2pool luck'

[OgNasty]

could this be the cause of the recent bad luck?

No.

His question was 'could'
The answer is 'Yes'

Any lost blocks will attribute to a lower 'pool luck'.
It's a lost block, it affects what is (incorrectly) referred to as 'pool luck'
So if there have been any (which no one will actually know) then it would have effected the 'p2pool luck'

Well, I 'could' manually solve the next two blocks in a row by typing in hashes.  However, I wouldn't go around saying that to people who might not understand the odds.

[wariner]

Well, I 'could' manually solve the next two blocks in a row by typing in hashes.  However, I wouldn't go around saying that to people who might not understand the odds.

I know the odds, but here the problem is the antminer software and need to solve it.

could this be the cause of the recent bad luck?

No.

Can you explain please

By the way... what is your magic number?  You state, "...it would cost you a fortune to pay me...".  Define fortune .

Writing in c is very labour intensive (compared to python) so it's a lot of hours work. I charge less for free software than private software since I like to encourage free software use as much as possible. At current exchange rates I charge .29 btc/hr for free soft and .38 for private software. A rough estimate of the time required to rewrite p2pool in c (properly) would be 500 hours work. That's around 150 BTC.

EDIT: By the way this would be a total and utter massive waste of money. Even if all the scalability problems were addressed AND a solution was found for the variance problem, there are no miners left to attract. The sad truth is personal miners are an increasingly irrelevant entity and what little hashrate they have cannot save any small pool. Only farms are relevant today.

I am a small miner (3x s5) what should I do? abandon p2pool??!! I hope for a solution ... I will offer 0.29btc for one of your hours when and if it will be necessary, p2pool must not die..

[kano]

could this be the cause of the recent bad luck?

No.

His question was 'could'
The answer is 'Yes'

Any lost blocks will attribute to a lower 'pool luck'.
It's a lost block, it affects what is (incorrectly) referred to as 'pool luck'
So if there have been any (which no one will actually know) then it would have effected the 'p2pool luck'

Well, I 'could' manually solve the next two blocks in a row by typing in hashes.  However, I wouldn't go around saying that to people who might not understand the odds.

Any lost blocks affects 'pool luck'.
Mining with Bitmain firmware versions can lose blocks on p2pool.
Anyone mining with such hardware with this problem is risking losing blocks on p2pool.

Now, if instead you are implying that losing such blocks is rare ... you are mistaken.
95% of stale share blocks on p2pool are valid bitcoin network blocks.
That is the reason why forrestv changed p2pool to submit stale share blocks to bitcoind when we pointed out the problem to him.

How often do these stale share blocks occur?
At least as often as any p2pool blocks that don't appear in the p2pool share chain (Edit: these are the stale share blocks)
The actual number is higher, since as I stated, 95% of stale p2pool share blocks are valid bitcoin network blocks.
It would be even higher if people were mining with bitmain firmware versions throwing away these stale share blocks that are valid bitcoin blocks.

[OgNasty]

You honestly believe the 'Thirty Day' luck of 46.84% is due to S7 firmware?

I think spreading that opinion is damaging to the p2pool project.  Not sure why you would perpetuate that as a realistic cause.  I am not sticking up for Bitmain and I would like to see improved firmware as much as the next guy (submitting stales is obviously an improvement and I believe you are the best person for the job).  I also believe they should be sending you and -ck free units of any hardware that takes advantage of cgminer.  Same goes for Avalon and any others as well.  However, let's be honest.  Stale shares are not the cause for a >50% reduction of luck over the last 30 days.

EDIT:

could this be the cause of the recent bad luck?

The answer is 'Yes'

See what statements like that lead people to believe:

You honestly believe the 'Thirty Day' luck of 46.84% is due to S7 firmware?

not only S7 but all antminer which is not changed with "ck cgminer".

[wariner]

You honestly believe the 'Thirty Day' luck of 46.84% is due to S7 firmware?

not only S7 but all antminer which is not changed with "ck cgminer".

However, let's be honest.  Stale shares are not the cause for a >50% reduction of luck over the last 30 days.

Do you have other ideas?

[kano]

You honestly believe the 'Thirty Day' luck of 46.84% is due to S7 firmware?
...

Where did I say that?

[notbatman]

Submitting stale shares can only improve hash rate by 2-3% at most. Can't see that causing the current run of bad luck.

If I had to guess I'd say its team XT and their memory abusing spam attack on core causing orphaned blocks. That combined with increasing difficulty.

[BlInK311]

could this be the cause of the recent bad luck?

No.

His question was 'could'
The answer is 'Yes'

Any lost blocks will attribute to a lower 'pool luck'.
It's a lost block, it affects what is (incorrectly) referred to as 'pool luck'
So if there have been any (which no one will actually know) then it would have effected the 'p2pool luck'

Well, I 'could' manually solve the next two blocks in a row by typing in hashes.  However, I wouldn't go around saying that to people who might not understand the odds.

How/where can I submit manual hashes?  That sounds like fun.  After 3 submissions I'm sure I'd give up.

[-ck]

Can you explain please

By the way... what is your magic number?  You state, "...it would cost you a fortune to pay me...".  Define fortune .

Writing in c is very labour intensive (compared to python) so it's a lot of hours work. I charge less for free software than private software since I like to encourage free software use as much as possible. At current exchange rates I charge .29 btc/hr for free soft and .38 for private software. A rough estimate of the time required to rewrite p2pool in c (properly) would be 500 hours work. That's around 150 BTC.

EDIT: By the way this would be a total and utter massive waste of money. Even if all the scalability problems were addressed AND a solution was found for the variance problem, there are no miners left to attract. The sad truth is personal miners are an increasingly irrelevant entity and what little hashrate they have cannot save any small pool. Only farms are relevant today.

I am a small miner (3x s5) what should I do? abandon p2pool??!! I hope for a solution ... I will offer 0.29btc for one of your hours when and if it will be necessary, p2pool must not die..

I did not say to abandon p2pool in its current form, I just do not see it changing from what it currently is. It is also not my place to recommend you do something else on the p2pool thread.

[kano]

You honestly believe the 'Thirty Day' luck of 46.84% is due to S7 firmware?

I think spreading that opinion is damaging to the p2pool project.  Not sure why you would perpetuate that as a realistic cause.  I am not sticking up for Bitmain and I would like to see improved firmware as much as the next guy (submitting stales is obviously an improvement and I believe you are the best person for the job).  I also believe they should be sending you and -ck free units of any hardware that takes advantage of cgminer.  Same goes for Avalon and any others as well.  However, let's be honest.  Stale shares are not the cause for a >50% reduction of luck over the last 30 days.

EDIT:

could this be the cause of the recent bad luck?

The answer is 'Yes'

See what statements like that lead people to believe:

You honestly believe the 'Thirty Day' luck of 46.84% is due to S7 firmware?

not only S7 but all antminer which is not changed with "ck cgminer".

The point of my comment is that indeed using the S7 with crappy firmware can lose blocks and reduce the luck (and payouts)
wariner's comment is correct also - all antminers with crappy firmware versions can lose p2pool blocks and reduce the luck.
Obviously that's "next to" (but not completely) impossible to be the cause of all of the 50% lost luck.
Obviously, however, it can and will affect the luck if lots of people mine with said problematic hardware.