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

[nreal]

Anyone using mining_proxy with p2pool, doesnt work here - Im doing something wrong maybe. It keeps connecting and closing.

They don't work with p2pool - never have. One of the many........

Oh, thats bad..

[1714211164]

1714211164

[1714211164]

1714211164

[1714211164]

1714211164

[1714211164]

1714211164

[1714211164]

1714211164

[bitpop]

I hope the knc Neptune works, about to try it

[bitpop]

Anyone using mining_proxy with p2pool, doesnt work here - Im doing something wrong maybe. It keeps connecting and closing.

They don't work with p2pool - never have. One of the many........

Oh, thats bad..

It's usually the hardware fault because it doesn't poll quickly

[nreal]

He does if he wants people to switch on donations again. Anyway, if we can't ensure that future mining hardware is usable with p2pool - it will die - simple as that. The hash rate drop since his spectacular fail of a "statement/moan/bribery attempt" shows which way p2pool is going, it will only get worse as everyone gradually switches off their S1's.......

Copy/Paste of my last received email from Bitmain:

"Hi,
Thanks for the info.
Please kindly provide us compared version of screenshot showing that the different speed when you use the p2pool and other pools. we need to provide more details to engineers to investigate it.
Thanks for your help in advance.

Best Regards

BITMAIN"

As my node is no longer online (stripped down) I am unable to provide these - can anyone chime in with these?

Peace.

Tell them to install one node and test themselves... It isnt too hard i think, for them..

[-ck]

A fork is good too

If forrestv doesn't show up - a fork will be a required necessity........

Forking it will only serve a purpose if you have a set of planned changes. If you have a set of planned changes then you're better off in the long run just pushing code to p2pool itself. Frustration with the current development process does not make the code/changes magically appear.

[forrestv]

I am currently in email conversation with Bitmain regarding the issues with the S2 (& soon to be released S3) & p2pool firmware/driver incompatibility issues. Bitmain have requested more info from me regarding the issues, however the type of info they require is a few levels above my paygrade/capability - so can someone either post here or PM me the exact problem & I will relay it to Bitmain.

This is an opportunity for the p2pool community to help increase the hardware availability for p2pool, something that so far has been severely lacking for the last year, and is especially important for the upcoming S3's - let's not miss out on this chance.

How can I help? I don't have any S1/S2 hardware to test with (if I did, P2Pool would probably work with it by now...) and haven't really gotten any concrete bug reports. I gather that they have high DoA rates, which I assume is due to high latency responding to pushed new work or high latency sending results.

The main things P2Pool needs in a miner are:

• Don't have arbitrary limits on the coinbase transaction size or the placement of the Stratum nonce within the coinbase (late generation Avalon miners are guilty of this).
• Send results/good nonces as soon as possible after they are discovered (ideally within 1 second).
• Start working on pushed new work as quickly as possible (ideally within 1 second). Also, don't drop good nonces if new work comes in (equivalent to cgminer's --submit-stales option)

If I am correct in assuming that the problem is latency, no simple solution will help existing devices. The parallel sharechains idea (which is my top priority) would alleviate this issue by moving away from the linear sharechain/30 seconds per share paradigm to one where latency matters far less.

[norgan]

this http://www.norgzpool.net.au/antminer.html essentially fixes the issues with the S1 but that's with Kano's fix. 

[jdot007]

************URGENT**********
@forrestv - This is your chance to prove to p2pool users that you actually care - I & every user here would like to see some input from you regarding this - please provide any info you can.....

BIG +1, S2's and upcoming S3's are ciritical to our success.


I'd like to start a bounty for forrestv to complete this.

I will start it with a BTC0.50 bounty offered to forrestv for a working solution for p2pool/anitminer S2 & S3 compatibility with the Ants achieving expected hashrate and shares.

Anyone is welcome to contribute to the donation address, bounty is paid to forrestv (or his designee) upon a working, distributed solution or returned in full in 30 days, I will pay return tx fees for any donation over BTC0.001, if your donation is less, consider it donated.

Bounty Address: 1Ft1DZ4EcpH1jFttDoPwsFbe11a6diyZ1H

https://blockchain.info/address/1Ft1DZ4EcpH1jFttDoPwsFbe11a6diyZ1H

Signed message:

Code:

forrestv p2pool antminer s2 and s3 compatibility fix.

Message signature:

Code:

G7zuvJ7/LPv7LpZveAsQWet1gAR42bnwFRVPB7NsnGqPnWkN8bqSSN1UwR+NnfDs/8LkruqZcVsTTdfcy5pcNj4=

Please contribute.


Edit: Any additional donations (over BTC0.001) will be returned to donation address or paid to Forrest or his designee on or before July 25th, 2014.

My hope is to pay Forrest for work done, lets make the bounty worthwhile.

Donated

7f9e8ad8756685ef911f3cbb2a0c4ae74b3851dbfa0f1b312154fdf689ee6b11

[norgan]

hmm my node hasn't picked up a share in over 5 hours. hashing at 700gh/s+ and usually a share comes up every couple of hours. anyone else seeing this?

[jonnybravo0311]

I am currently in email conversation with Bitmain regarding the issues with the S2 (& soon to be released S3) & p2pool firmware/driver incompatibility issues. Bitmain have requested more info from me regarding the issues, however the type of info they require is a few levels above my paygrade/capability - so can someone either post here or PM me the exact problem & I will relay it to Bitmain.

This is an opportunity for the p2pool community to help increase the hardware availability for p2pool, something that so far has been severely lacking for the last year, and is especially important for the upcoming S3's - let's not miss out on this chance.

How can I help? I don't have any S1/S2 hardware to test with (if I did, P2Pool would probably work with it by now...) and haven't really gotten any concrete bug reports. I gather that they have high DoA rates, which I assume is due to high latency responding to pushed new work or high latency sending results.

The main things P2Pool needs in a miner are:

• Don't have arbitrary limits on the coinbase transaction size or the placement of the Stratum nonce within the coinbase (late generation Avalon miners are guilty of this).
• Send results/good nonces as soon as possible after they are discovered (ideally within 1 second).
• Start working on pushed new work as quickly as possible (ideally within 1 second). Also, don't drop good nonces if new work comes in (equivalent to cgminer's --submit-stales option)

If I am correct in assuming that the problem is latency, no simple solution will help existing devices. The parallel sharechains idea (which is my top priority) would alleviate this issue by moving away from the linear sharechain/30 seconds per share paradigm to one where latency matters far less.

Hey forrestv,

I wish I could give you details, but unfortunately I'm half a world away from my S2.  What I can tell you is that when I point my S2 at my p2pool node (or any p2pool node for that matter) it will max out at 850-900GH/s.  I point it to another pool and it hits 1TH/s without issue.

I'd ask that you contact mdude77 and kano.  They have more details regarding what's going on with the S2.

By the way, the S1 works just fine with p2pool.

[zvs]

I did - but not as pissed as most of the p2pool users are with him. This is his chance to actually participate - let's see  

But he has no reason to participate

So then I guess you're assuming that if he actually was active on the project, then it wouldn't affect donations?

in any case, I had my donations set to 0% but I'm fairly certain I sent at least 1% directly to that p2pool donation address, from people with invalid names submitting shares

on the next update, maybe he should make it possible to not input a default address, so then ppl with messed up names end up donating their bitcoins, and you can still have it set to 0% for everyone else

[jonnybravo0311]

hmm my node hasn't picked up a share in over 5 hours. hashing at 700gh/s+ and usually a share comes up every couple of hours. anyone else seeing this?

That's just variance for you... my SP10 has gone for over 6 hours without finding a share.  I've had my S1s go for 22 hours and more without finding shares.  It happens.

[norgan]

hmm my node hasn't picked up a share in over 5 hours. hashing at 700gh/s+ and usually a share comes up every couple of hours. anyone else seeing this?

That's just variance for you... my SP10 has gone for over 6 hours without finding a share.  I've had my S1s go for 22 hours and more without finding shares.  It happens.

cool cheers, yeah I figured that was the case but it seems out of the ordinary with nearly 1th/s to have so much time between shares. All good, still learning the nuances of variation and p2pool.

[jonnybravo0311]

hmm my node hasn't picked up a share in over 5 hours. hashing at 700gh/s+ and usually a share comes up every couple of hours. anyone else seeing this?

That's just variance for you... my SP10 has gone for over 6 hours without finding a share.  I've had my S1s go for 22 hours and more without finding shares.  It happens.

cool cheers, yeah I figured that was the case but it seems out of the ordinary with nearly 1th/s to have so much time between shares. All good, still learning the nuances of variation and p2pool.

I know what you mean... I'm always thinking something has gone wrong.  Unfortunately, I'm usually on the other side of the planet when these things happen.  Whenever I'm home they seem to behave properly for the most part.  I think they're afraid I'll unplug them

I've learned that those "Expected time to..." values are not worth looking at unless you want to get ulcers and stress headaches trying to tweak things into oblivion.  As long as your node's efficiency rating/range has 100% in it, you're pretty much right on target.

[Collider]

You could always manually adjust the share difficulty to get lower variances afaik.

[norgan]

You could always manually adjust the share difficulty to get lower variances afaik.

you mean lower the diff?

[jonnybravo0311]

You could always manually adjust the share difficulty to get lower variances afaik.

you mean lower the diff?

pseudo diff only makes graphs look pretty.  You still need to submit a share of X difficulty to land on the chain.  Yeah, you could do something like this:

MYBTCADDRESS/1+1

But all that will do is flood the node with difficulty 1 shares from your miner.

[norgan]

You could always manually adjust the share difficulty to get lower variances afaik.

you mean lower the diff?

pseudo diff only makes graphs look pretty.  You still need to submit a share of X difficulty to land on the chain.  Yeah, you could do something like this:

MYBTCADDRESS/1+1

But all that will do is flood the node with difficulty 1 shares from your miner.

my understanding is it ensures your lower hash rate doesn't get lost in the higher hash rate of other miners on your node. If you are the only one on your node it shouldn't matter.

btw a bock! yay!

[mdude77]

fwiw, a while back I also emailed bitmain about p2pool.  I also asked that they work with Kano ... and give him the code to their S2 so he can figure things out.  I got the same response, about forwarding info to their engineers.

The symptoms are as others described: they max out around 920-930gh/s upon startup, and slowly decline over time from there.

I agree with what others have said: all bitmain has to do is setup their own node and point an S2 to it to see what's going on. 

M

[jonnybravo0311]

You could always manually adjust the share difficulty to get lower variances afaik.

you mean lower the diff?

pseudo diff only makes graphs look pretty.  You still need to submit a share of X difficulty to land on the chain.  Yeah, you could do something like this:

MYBTCADDRESS/1+1

But all that will do is flood the node with difficulty 1 shares from your miner.

my understanding is it ensures your lower hash rate doesn't get lost in the higher hash rate of other miners on your node. If you are the only one on your node it shouldn't matter.

btw a bock! yay!

Yes... a block.  Let's knock a few more out today

As for the difficulty, I'm not really sure how setting it would have any effect on low hash rate miners.  Your miner must find a share that satisfies the difficulty requirements of the share chain, regardless of whether or not you have 1GH/s or 1TH/s.  Currently, that is about 1.2M.  Setting your pseudo difficulty (by using the +xxx after your BTC address) doesn't have any effect on the actual share difficulty.  All it does is make graphs look nicer.  The lower you set it, the smoother the graph is - at the price of flooding the node with shares that have no chance of ever being accepted.  By default, the node will dynamically adjust the pseudo-share difficulty to get 1 share per second:

Code:

target = min(target, bitcoin_data.average_attempts_to_target(local_hash_rate * 1))

I think setting the difficulty (using the /xxx after your BTC address) is really more for the miners with exceptionally high hash rates compared to others.  I'm not sure anyone actually uses this.  However, like with setting pseudo-difficulty, the node dynamically adjusts your difficulty to limit you to 1.67% of the pool's shares:

Code:

desired_share_target = min(desired_share_target, bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167))