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

[Duce]

So normal CGminer has submit stale on by default correct?
I know CK provided a fix for the S3, what do we do about the S5? (Assuming we need corrective action)
Is it safe to say that Spondoolies did this the correct way, that is submit stale is on by default?

[1713271808]

1713271808

[1713271808]

1713271808

[1713271808]

1713271808

[1713271808]

1713271808

[idonothave]

If someone has added himself to p2pool 3 days before 344101 block was found he would get paid the same amount as if he added himself 4 or 5 days before it?

[-ck]

So normal CGminer has submit stale on by default correct?
I know CK provided a fix for the S3, what do we do about the S5? (Assuming we need corrective action)
Is it safe to say that Spondoolies did this the correct way, that is submit stale is on by default?

S5 binary also available here (antminer's fork binaries still screw this up):
http://ck.kolivas.org/apps/cgminer/antminer/

Spondoolies do the right thing here.

[PatMan]

So normal CGminer has submit stale on by default correct?
I know CK provided a fix for the S3, what do we do about the S5? (Assuming we need corrective action)
Is it safe to say that Spondoolies did this the correct way, that is submit stale is on by default?

S5 binary also available here (antminer's fork binaries still screw this up):
http://ck.kolivas.org/apps/cgminer/antminer/

Spondoolies do the right thing here.

@ck:  Am I right in saying that this has to be applied after every reboot - or is there a way to make it permanent:

Code:

cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

[nreal]

So normal CGminer has submit stale on by default correct?
I know CK provided a fix for the S3, what do we do about the S5? (Assuming we need corrective action)
Is it safe to say that Spondoolies did this the correct way, that is submit stale is on by default?

S5 binary also available here (antminer's fork binaries still screw this up):
http://ck.kolivas.org/apps/cgminer/antminer/

Spondoolies do the right thing here.

@ck:  Am I right in saying that this has to be applied after every reboot - or is there a way to make it permanent:

Code:

cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

Replacing cgminer binary is permanent, after firmware update one should do it again

[PatMan]

Replacing cgminer binary is permanent, after firmware update one should do it again

I'm not so sure about that, according to ck:

Here's a quick binary for the S5 based on bitmain's existing code which will ignore any queue parameter, not discard stales, should be able to ramp up smoothly if you find yourself on a very low diff pool, and use a little less CPU:

http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer

Binaries will only be temporary so will not survive a machine reboot.

The following will change the cgminer binary for you (set the appropriate IP address), the default root password is "admin":

Code:

ssh 192.168.1.x -l root
cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

There should be a more comprehensive merge in the future into mainline cgminer, hopefully by Kano. Bitmaintech has provided us both with S5s to support cgminer development.

As far as I know the merge didn't happen yet, cos if it had we wouldn't have to download this binary.

[mdude77]

If someone has added himself to p2pool 3 days before 344101 block was found he would get paid the same amount as if he added himself 4 or 5 days before it?

Theoretically speaking, yes.  It depends largely on your individual luck.

M

[aurel57]

So normal CGminer has submit stale on by default correct?
I know CK provided a fix for the S3, what do we do about the S5? (Assuming we need corrective action)
Is it safe to say that Spondoolies did this the correct way, that is submit stale is on by default?

S5 binary also available here (antminer's fork binaries still screw this up):
http://ck.kolivas.org/apps/cgminer/antminer/

Spondoolies do the right thing here.

@ck:  Am I right in saying that this has to be applied after every reboot - or is there a way to make it permanent:

Code:

cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

This seems like a problem if you rent hash?

[jedimstr]

This seems like a problem if you rent hash?

Best bet for renting hash for use with p2pool is to stick to renters who advertise using Spondoolies boxes. You'll get less problems with the rental that way since they're great on p2pool.

[jcumins]

CK  your last cgminer binary will not work with the Jan 2015 Bitmain S3 firmware.  the cgminer that is part of the Jan 2015 firmware is version 4.70  not 4.6.  Do you know if this has the fix in it.

 

[Songminer]

I'm running an s5 with the January firmware.

Is there anything I should do to improve performance on the P2Pool?

[PatMan]

I'm running an s5 with the January firmware.

Is there anything I should do to improve performance on the P2Pool?

Change the queue setting to 0 or 1 - whatever gives you the lowest DOA/reject rate 

[-ck]

CK  your last cgminer binary will not work with the Jan 2015 Bitmain S3 firmware.  the cgminer that is part of the Jan 2015 firmware is version 4.70  not 4.6.  Do you know if this has the fix in it.

 

No it doesn't.

[jcumins]

So what version of firmware will your cgminer work with I can always back rev and update the cgminer

[jcumins]

I will update my s5 tomorrow with yck latest cgminer tomorrow when i install them in the data center

[jtoomim]

It looks like about 41% of all p2pool miners are now running on the Toomim Brothers datacenter's nodes, since most of the rest fled.

Node 1: 298 TH/s
Node 2: 60 TH/s
p2pool total: 864 TH/s

I'm amused, but also a bit disappointed. Can't you guys bring your hashrate back?

If you are running your own node and want to add us to your hardcoded IP list, please only add one of our nodes, since adding both would result in shares and transactions being sent twice over our internet connection instead of once over the 'net and then forwarded once over our LAN. Also, both of our nodes are a bit stressed in terms of CPU cycles (especially the big :9334 node), and each connection adds CPU load. Also keep in mind that those nodes are not currently on a static IP address, and their IP may change once every few months. (The IP has changed once so far since August.)

By the way, my guess is that the previous block took as long as it did in large part because a bunch of hashrate left p2pool several days ago, and the p2pool total hashrate estimates are slow to update. The estimates are based on the last 8640 shares submitted (right?). The default share difficulty is based on the estimated pool hashrate, so when the hashrate decreases rapidly, 8640 shares can encompass a time period significantly longer than 3 days, since those 8640 shares are at a higher (older) difficulty.

[mdude77]

It looks like about 41% of all p2pool miners are now running on the Toomim Brothers datacenter's nodes, since most of the rest fled.

Node 1: 298 TH/s
Node 2: 60 TH/s
p2pool total: 864 TH/s

I'm amused, but also a bit disappointed. Can't you guys bring your hashrate back?

If you are running your own node and want to add us to your hardcoded IP list, please only add one of our nodes, since adding both would result in shares and transactions being sent twice over our internet connection instead of once over the 'net and then forwarded once over our LAN. Also, both of our nodes are a bit stressed in terms of CPU cycles (especially the big :9334 node), and each connection adds CPU load. Also keep in mind that those nodes are not currently on a static IP address, and their IP may change once every few months. (The IP has changed once so far since August.)

By the way, my guess is that the previous block took as long as it did in large part because a bunch of hashrate left p2pool several days ago, and the p2pool total hashrate estimates are slow to update. The estimates are based on the last 8640 shares submitted (right?). The default share difficulty is based on the estimated pool hashrate, so when the hashrate decreases rapidly, 8640 shares can encompass a time period significantly longer than 3 days, since those 8640 shares are at a higher (older) difficulty.

I've seen the hashrate jump around a lot in a very short period of time.  I don't think it's based upon the last 8640 shares.  What it is based upon I don't know.  In order to keep the target at approx one share every 30 seconds, I'd think it'd have to recalculate pretty often and look at a pretty small window.  Otherwise someone could add 1 PH/s and the share difficulty would take quite some time to increase.

M

[jtoomim]

Cross-post from the Spondoolies thread, more relevant here:

centralization incoming

If only everyone used p2pool.......

If everyone did, the share difficulty would be through the roof.  2,222,770,798 if I understand it right..

p2pool is not the answer.

a rewrite perhaps.  but not in its current incarnation.

M

I was thinking about this the other day, actually, and I think I got a good solution to the problem.

p2pool uses a share chain much like the block chain for its reward allocation. This means that if you're mining on a share that isn't the most recent, your work is wasted. The blockchain was designed to solve the timestamping problem for creating a distributed ledger system for transactions, which is why the blockchain has to be serialized. With p2pool, there is no such requirement for timestamping and serializing the shares, so the shares do not necessarily need to be arranged in a chain. The fact that they are was probably mostly just a programming convenience in being able to reuse the bitcoin blockchain data structures. I think a better structure for p3pool shares would be a share tree, where each share references at least one parent share instead of exactly one parent share. That way, work done on shares that would end up marked as stale on the current p2pool (i.e. branching shares) could still be incorporated into the p3pool share tree. Add in a small reward to the miner who found the share for each parent share that's referenced for the first time, and everybody's shares should get incorporated as long as the share is based on the most recent block.

Since miners no longer would need to abandon work immediately when someone on p3pool finds a share, p3pool could target much higher share frequencies, such as 1 per second or faster. This would decrease share variance and allow for small miners to use p2pool effectively, and it would also allow p3pool to grow larger while keeping individual share targets reasonable.

[organofcorti]

Cross-post from the Spondoolies thread, more relevant here:

centralization incoming

If only everyone used p2pool.......

If everyone did, the share difficulty would be through the roof.  2,222,770,798 if I understand it right..

p2pool is not the answer.

a rewrite perhaps.  but not in its current incarnation.

M

I was thinking about this the other day, actually, and I think I got a good solution to the problem.

p2pool uses a share chain much like the block chain for its reward allocation. This means that if you're mining on a share that isn't the most recent, your work is wasted. The blockchain was designed to solve the timestamping problem for creating a distributed ledger system for transactions, which is why the blockchain has to be serialized. With p2pool, there is no such requirement for timestamping and serializing the shares, so the shares do not necessarily need to be arranged in a chain. The fact that they are was probably mostly just a programming convenience in being able to reuse the bitcoin blockchain data structures. I think a better structure for p3pool shares would be a share tree, where each share references at least one parent share instead of exactly one parent share. That way, work done on shares that would end up marked as stale on the current p2pool (i.e. branching shares) could still be incorporated into the p3pool share tree. Add in a small reward to the miner who found the share for each parent share that's referenced for the first time, and everybody's shares should get incorporated as long as the share is based on the most recent block.

Since miners no longer would need to abandon work immediately when someone on p3pool finds a share, p3pool could target much higher share frequencies, such as 1 per second or faster. This would decrease share variance and allow for small miners to use p2pool effectively, and it would also allow p3pool to grow larger while keeping individual share targets reasonable.

That sounds like it would end up being a proportional reward method, yes?

[jtoomim]

That sounds like it would end up being a proportional reward method, yes?

I was thinking of it as being PPLNS like the current p2pool, but with the option for a larger number of shares in the LNS window than the 8640 of p2pool. However, the algorithm used to determine the rewards per miner or per share is partially independent of the share tree data structure, so it should be possible to make many different types of p2pool clones with different reward algorithms.