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

[CartmanSPC]

The number of nodes isn't a problem, and really never has been.  Plenty of people put up and run publicly accessible p2pool nodes.  Heck, I was one of them for 2 years.

Ideally, if you're interested in p2pool, you'd run your own node.  That's the ultimate design of it - to be completely decentralized.  It's a fantastic concept.  As I pointed out, not everybody does so.  So, if there are plenty of nodes from which people can choose, why aren't more people here?  Well, that leads back to the part of my post you didn't quote.

The variance here is twofold.  First, is getting shares onto the chain.  Share difficulty is currently 1360000.  So what does that mean for expectations?

• Antminer S1 would expect to land a share every 9 hours or so
• Antminer S3 would expect to land a share every 3.5 hours or so
• Antminer S5 would expect to land a share every 1.4 hours or so
• Antminer S7 would expect to land a share every half an hour or so

So, the price of entry is pretty steep.  And, it only gets worse as more hashing power is added to the pool because the share difficulty rises in conjunction with the added hash.  That's the ultimate problem to be solved: how do you keep miners from suffering more and more variance even as the pool gains hash and solves more blocks?

I keep coming back to the idea of increasing the maximum p2pool share difficulty from the current 30 time the minimum. I believe this would help decrease the minimum p2pool share difficulty and provide more shares for smaller miner in turn lowering variance. Currently the maximum share diff is 40800000 based on the min being 1360000. I believe p2pool automatically increases the share difficulty on each node based on how much hash rate it has in comparison to the rest of the pool.

[note to self: post code where this is done]

For an S7 if the miner set's his share diff to be the current max he would get a share every ~15 hours (based on the example in the quote). I don't have an S7 to see if it is automatically increasing it's difficulty and by how much. If nodes are not increasing difficulty then we need to figure out why...but I think they are.

Found an old post from roy7 that goes into more detail:
https://bitcointalk.org/index.php?topic=18313.msg5950880;topicseen#msg5950880

[note to self: post code where the 30 times the minimum share difficulty is done]

For example...this miner with 22 TH/s is currently using the minimum share diff of 1430391. ETA to share is about 5 minutes. They should be running with the max share diff not min. By running with the min they are taking away shares that smaller miners could use to get in the share chain and also increasing the min share diff for everyone. If they set themselves to use the current max share diff it would give them a share every 2.5 hours instead of 5 minutes which is more than reasonable. They will make the same amount and help out smaller miners and the entire pool as a whole... including themselves.

http://minefast.coincadence.com/miner.php?id=1Nhx4RU5bbUiHEXJLFEdQaewwHYnpSNAvD

This example shows that p2pool may not be automatically increasing the share diff at the node level...or, more likely, the miner explicitly set his diff to be low. It's been a while since I looked at the code but I think it was last set to if a node has more then 5% of the hashrate increase. The node where this miner is at is about 45 TH out of 600 TH so a little over 5%.

Edit: it's actually 1.3% now so that node should definitely be increasing their miners share diff. The miner most likely is overriding it though.

Code:

bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167)) # limit to 1.67% of pool shares by modulating share difficulty 

https://github.com/p2pool/p2pool/blob/482f410b0f48696901ae2a732450d02a27c0edc6/p2pool/work.py#L290

Was lowered from 5% on 11-04-2013 in this commit: https://github.com/p2pool/p2pool/commit/69d7300919e0f9b23ec81c1d01c0bf12cdb1ebc5

Maybe time to lower even more?

[1713938250]

1713938250

[kano]

So ... if p2pool was 10% of the network, the pool would be ... 86PH ... yeah consider that in your calculations ...

... and reducing share time means more lost shares.

Of course there's the other problem that happened recently when someone easily 51% p2pool ... and no one seemed to care or even notice

[CartmanSPC]

So ... if p2pool was 10% of the network, the pool would be ... 86PH ... yeah consider that in your calculations ...

... and reducing share time means more lost shares.

Of course there's the other problem that happened recently when someone easily 51% p2pool ... and no one seemed to care or even notice

Well, yea...ultimately p2pool it is flawed in that it is not scalable among other things.

...and I am suggesting to increase share times (for larger miners) not decrease.

[nicklello]

The number of nodes isn't a problem, and really never has been.  Plenty of people put up and run publicly accessible p2pool nodes.  Heck, I was one of them for 2 years.

Ideally, if you're interested in p2pool, you'd run your own node.  That's the ultimate design of it - to be completely decentralized.  It's a fantastic concept.  As I pointed out, not everybody does so.  So, if there are plenty of nodes from which people can choose, why aren't more people here?  Well, that leads back to the part of my post you didn't quote.

The variance here is twofold.  First, is getting shares onto the chain.  Share difficulty is currently 1360000.  So what does that mean for expectations?

• Antminer S1 would expect to land a share every 9 hours or so
• Antminer S3 would expect to land a share every 3.5 hours or so
• Antminer S5 would expect to land a share every 1.4 hours or so
• Antminer S7 would expect to land a share every half an hour or so

So, the price of entry is pretty steep.  And, it only gets worse as more hashing power is added to the pool because the share difficulty rises in conjunction with the added hash.  That's the ultimate problem to be solved: how do you keep miners from suffering more and more variance even as the pool gains hash and solves more blocks?

I keep coming back to the idea of increasing the maximum p2pool share difficulty from the current 30 time the minimum. I believe this would help decrease the minimum p2pool share difficulty and provide more shares for smaller miner in turn lowering variance. Currently the maximum share diff is 40800000 based on the min being 1360000. I believe p2pool automatically increases the share difficulty on each node based on how much hash rate it has in comparison to the rest of the pool.

[note to self: post code where this is done]

For an S7 if the miner set's his share diff to be the current max he would get a share every ~15 hours (based on the example in the quote). I don't have an S7 to see if it is automatically increasing it's difficulty and by how much. If nodes are not increasing difficulty then we need to figure out why...but I think they are.

Found an old post from roy7 that goes into more detail:
https://bitcointalk.org/index.php?topic=18313.msg5950880;topicseen#msg5950880

[note to self: post code where the 30 times the minimum share difficulty is done]

For example...this miner with 22 TH/s is currently using the minimum share diff of 1430391. ETA to share is about 5 minutes. They should be running with the max share diff not min. By running with the min they are taking away shares that smaller miners could use to get in the share chain and also increasing the min share diff for everyone. If they set themselves to use the current max share diff it would give them a share every 2.5 hours instead of 5 minutes which is more than reasonable. They will make the same amount and help out smaller miners and the entire pool as a whole... including themselves.

http://minefast.coincadence.com/miner.php?id=1Nhx4RU5bbUiHEXJLFEdQaewwHYnpSNAvD

This example shows that p2pool may not be automatically increasing the share diff at the node level...or, more likely, the miner explicitly set his diff to be low. It's been a while since I looked at the code but I think it was last set to if a node has more then 5% of the hashrate increase. The node where this miner is at is about 45 TH out of 600 TH so a little over 5%.

Edit: it's actually 1.3% now so that node should definitely be increasing their miners share diff. The miner most likely is overriding it though.

Code:

bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167)) # limit to 1.67% of pool shares by modulating share difficulty 

https://github.com/p2pool/p2pool/blob/482f410b0f48696901ae2a732450d02a27c0edc6/p2pool/work.py#L290

Was lowered from 5% on 11-04-2013 in this commit: https://github.com/p2pool/p2pool/commit/69d7300919e0f9b23ec81c1d01c0bf12cdb1ebc5

Maybe time to lower even more?

Are you suggesting that the ability to set your miner's difficulty to a value lower than the p2pool node would otherwise set is in fact causing this issue with shares ?

Would a way forward be to disable the miner abiility to set difficulty ?

[Polyatomic]

Wait up can someone please tell me again,

`` bitcoinaddresshere/1 `` is that always submit shares at the target and higher?.
`` bitcoinaddresshere/2 `` is that always submit shares double the target and higher?.

Say the sharechain target is 4 000 000 How does one submit only, shares double
that and higher.

Lets grep the source yeah

Code:

milton@milton:~/temp/p2pool$ git grep share_target
p2pool/bitcoin/getwork.py:    def __init__(self, version, previous_block, merkle_root, timestamp, bits, share_target):
p2pool/bitcoin/getwork.py:        self.version, self.previous_block, self.merkle_root, self.timestamp, self.bits, self.share_target = version, previous_block, merkle_root, timestamp, bits, share_target
p2pool/bitcoin/getwork.py:        return hash((self.version, self.previous_block, self.merkle_root, self.timestamp, self.bits, self.share_target))
p2pool/bitcoin/getwork.py:            'target': pack.IntType(256).pack(self.share_target).encode('hex'),
p2pool/bitcoin/getwork.py:            share_target=pack.IntType(256).unpack(getwork['target'].decode('hex')),
p2pool/bitcoin/stratum.py:        self.other.svc_mining.rpc_set_difficulty(bitcoin_data.target_to_difficulty(x['share_target'])).addErrback(lambda err: None)
p2pool/bitcoin/worker_interface.py:            share_target=x['share_target'],
p2pool/main.py:                    my_shares_per_s = sum(datum['work']/dt/bitcoin_data.target_to_average_attempts(datum['share_target']) for datum in datums)
p2pool/work.py:        desired_pseudoshare_target = None
p2pool/work.py:        desired_share_target = None
p2pool/work.py:                    desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
p2pool/work.py:                    desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
p2pool/work.py:        return user, pubkey_hash, desired_share_target, desired_pseudoshare_target
p2pool/work.py:        user, pubkey_hash, desired_share_target, desired_pseudoshare_target = self.get_user_details(user)
p2pool/work.py:        return pubkey_hash, desired_share_target, desired_pseudoshare_target
p2pool/work.py:    def get_work(self, pubkey_hash, desired_share_target, desired_pseudoshare_target):
p2pool/work.py:        if desired_share_target is None:
p2pool/work.py:            desired_share_target = 2**256-1

That looks interesting lets try a bit of pickaxe

Code:

milton@milton:~/temp/p2pool$ git log -Sshare_target --pretty=raw --abbrev-commit p2pool/work.py
commit c345d54
tree 02354ed885c4c302aae09e5689d6f7f6ccd79064
parent 29493ba726ab40f78574361fdeabec075a8a685f
author Forrest Voight <forrest@forre.st> 1372869213 -0400
committer Forrest Voight <forrest@forre.st> 1372873668 -0400

    dynamically adjust share difficulty to prevent payouts below dust threshold

commit 819f0e3
tree eab5343ad18bc2fa0e0b46b8fc7d9913243259f1
parent d2941ed60b7e65683ecaa8774c0e5e9e7dad2d4b
author Forrest Voight <forrest@forre.st> 1372439913 -0400
committer Forrest Voight <forrest@forre.st> 1372443960 -0400

    modulate share difficulty to prevent any node from producing more than 5% of shares

commit 80c9591
tree 4b573ac22ff8ec5c7fc8d7a3144517da90e36075
parent 70d337b9024ff6564fcbebae114c95b91422aed3
author Forrest Voight <forrest@forre.st> 1340553333 -0400
committer Forrest Voight <forrest@forre.st> 1340555939 -0400

    moved WorkerBridge to p2pool.work

p2pool/work.py:                desired_share_target = min(desired_share_target,
p2pool/work.py:                    desired_share_target = min(desired_share_target,
p2pool/work.py:                desired_target=desired_share_target,
p2pool/work.py:        if desired_pseudoshare_target is None:
p2pool/work.py:            target = desired_pseudoshare_target
p2pool/work.py:            share_target=target,
p2pool/work.py:                self.local_rate_monitor.add_datum(dict(work=bitcoin_data.target_to_average_attempts(target), dead=not on_time, user=user, share_target=share_info['bits'].target))

Ah k there

Code:

milton@milton:~/temp/p2pool$ git show 819f0e3
diff --git a/p2pool/work.py b/p2pool/work.py
index 40a1a30..346db56 100644
--- a/p2pool/work.py
+++ b/p2pool/work.py
@@ -142,18 +142,20 @@ class WorkerBridge(worker_interface.WorkerBridge):
         user, contents2 = contents[0], contents[1:]
         
         desired_pseudoshare_target = None
-        desired_share_target = 2**256 - 1
+        desired_share_target = None
         for symbol, parameter in zip(contents2[::2], contents2[1::2]):
             if symbol == '+':
                 try:
                     desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
                 except:
-                    pass
+                    if p2pool.DEBUG:
+                        log.err()
             elif symbol == '/':
                 try:
                     desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
                 except:
-                    pass
+                    if p2pool.DEBUG:
+                        log.err()

I can't tell what a miner is supposed to put in front of the / ?
It also says in the commit message of 819f0e3e3ab9460fe60606c3f1e9c562d40361c7

Code:

modulate share difficulty to prevent any node from producing more than 5% of shares

I'm curious now, what actually happens to large miners with enough hashrate to trigger that?.
Take it easy guys and maybe I'll see ya round. I'll delete if this post is too noisy.
=^)

Edit: Sun Jan 31 14:45:56 ACDT 2016
Cheers CartmanSPC

[CartmanSPC]

Wait up can someone please tell me again,
`` bitcoinaddresshere/1 `` is that always submit shares at the target and higher.
`` bitcoinaddresshere/2 `` is that always submit shares double the target and higher.

Not sure where you got this but it is wrong.

Anything after the '/' lower than the current min diff of 1570000 will give you the minimum share diff.
Anything higher up to the current max of 47100000 will give you shares less often but of higher value.

I think you people should target about 1 share every 6-12 hours to allow smaller miners a chance.

Code:

modulate share difficulty to prevent any node from producing more than 5% of shares

I'm curious now, what actually happens to large miners with enough hashrate to trigger that?.

This is now 1.3%. It is on a per node basis and is supposed to increase the share diff for everyone on a node that has more than 1.3% of the p2pool hashrate. It can be overrode by using 'address/number'.

[OgNasty]

Any way to do fractional shares, perhaps?

We split rewards evenly based on hashes instead of shares to help smooth out variance for the little guys.
https://bitcointalk.org/index.php?topic=306611.0

[organofcorti]

Any way to do fractional shares, perhaps?

We split rewards evenly based on hashes instead of shares to help smooth out variance for the little guys.
https://bitcointalk.org/index.php?topic=306611.0

That thread doesn't explain how the reward method works though -- what does Prop-on-PPLNS mean? Clearly, you're not going to get miners to send you every single hash they make, so how do you pay "by hash"?

[OgNasty]

Any way to do fractional shares, perhaps?

We split rewards evenly based on hashes instead of shares to help smooth out variance for the little guys.
https://bitcointalk.org/index.php?topic=306611.0

That thread doesn't explain how the reward method works though -- what does Prop-on-PPLNS mean? Clearly, you're not going to get miners to send you every single hash they make, so how do you pay "by hash"?

This probably isn't the proper thread to discuss specifics relating to our payout method.  However, it's pretty simple.  Rewards earned by NastyPool (p2pool node) are split evenly among the -PoP miners based on their average reported hashrate during the week period.

[p3yot33at3r]

Well, an advantage of having a low hash rate is the nice, big, juicy block! payouts 

[OgNasty]

Well, an advantage of having a low hash rate is the nice, big, juicy block! payouts 

Yes, it just sucks if it takes you a long time to submit an accepted share and then your work falls off the chain and you never receive anything.

[p3yot33at3r]

Well, an advantage of having a low hash rate is the nice, big, juicy block! payouts 

Yes, it just sucks if it takes you a long time to submit an accepted share and then your work falls off the chain and you never receive anything.

Amen to that.

[dog1965]

can someone please help I JUST STARTED MY OWN NODE its running fine except I keep getting these messages when I start up and occasionally when its running looks like I am missing a plug in or something ?

exceptions.AssertionError: tried to broadcast share without knowing all its new transactions


 Error while processing Event callbacks:
2016-02-01 10:45:02.816000 > Traceback (most recent call last):
2016-02-01 10:45:02.816000 >   File "p2pool\node.pyc", line 135, in download_shares
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.816000 >   File "p2pool\node.pyc", line 48, in handle_shares
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.816000 >   File "p2pool\node.pyc", line 297, in set_best_share
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.816000 >   File "p2pool\util\variable.pyc", line 74, in set
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.831000 > --- <exception caught here> ---
2016-02-01 10:45:02.831000 >   File "p2pool\util\variable.pyc", line 42, in happened
2016-02-01 10:45:02.831000 >
2016-02-01 10:45:02.831000 >   File "p2pool\node.pyc", line 96, in broadcast_share
2016-02-01 10:45:02.831000 >
2016-02-01 10:45:02.831000 >   File "p2pool\p2p.pyc", line 317, in sendShares
2016-02-01 10:45:02.831000 >
2016-02-01 10:45:02.831000 > exceptions.AssertionError: tried to broadcast share without knowing all its new transactions

P2Pool: 17470 shares in chain (17474 verified/17474 total) Peers: 7 (0 incoming)
2016-02-01 13:36:07.455000  Local: 5764GH/s in last 10.0 minutes Local dead on arrival: ~2.4% (1-5%) Expected time to share: 30.0 minutes
2016-02-01 13:36:07.455000  Shares: 6 (1 orphan, 0 dead) Stale rate: ~16.7% (3-57%) Efficiency: ~93.8% (49-110%) Current payout: (0.1734)=0.1734 BTC
2016-02-01 13:36:07.455000  Pool: 882TH/s Stale rate: 11.1% Expected time to block: 6.8 days
2016-02-01 13:36:10.065000 > Unhandled error in Deferred:
2016-02-01 13:36:10.065000 > Unhandled Error
2016-02-01 13:36:10.065000 > Traceback (most recent call last):
2016-02-01 13:36:10.065000 > Failure: twisted.internet.defer.TimeoutError: in ReplyMatcher


Peer 188.138.106.130:9333 misbehaving, will drop and ban. Reason: peer too old
2016-02-01 14:50:07.081000 Bad peer banned: (u'188.138.106.130', 9333)
2016-02-01 14:50:07.081000 Peer 188.138.106.130:9333 misbehaving, will drop and ban. Reason: first message was not version message
2016-02-01 14:50:07.097000 Bad peer banned: (u'188.138.106.130', 9333)
2016-02-01 14:50:07.097000 Peer 188.138.106.130:9333 misbehaving, will drop and ban. Reason: first message was not version message
2016-02-01 14:50:07.097000 Bad peer banned: (u'188.138.106.130', 9333)
2016-02-01 14:50:07.097000 Peer 188.138.106.130:9333 misbehaving, will drop and ban. Reason: first message was not version message
2016-02-01 14:50:07.097000 Bad peer banned: (u'188.138.106.130', 9333)

Computer I am running it on is a INTEL I7 4930k overclocking to 4.6 GHZ stable.
                                                RAM: 16GB corsair dominator 4GB sticks 4 sticks.
                                                MOBO: MSI BIG BANG-XPOWER II LGA2011
                                                HDD: 6TB raid configuration "two 3tb"
                                                         8tb raid configuration  "four 2tb drives"
                                                 stupid verizom 100MB/s router 100 up/down

                                                  miners: antminer s5 and antminer S7 which both don't show up in the p2pool dos command windows when I run the node only combined hash rate speed shows up those are my miners which I am mining on my own pool. question I am using a different bitcoin address then my pool's BTC address do they have to be the same ? also I am mining to a online wallet.

I don't want to ask a million questions I am new at running a node but if anyone can answer them its much appreciated. I just want to stay focused on what's causing the errors a pasted above and how to fix it ?

 

[windpath]

Welcome to P2Pool!

To see your miners open up http://P2POOL_HOST:PORT/static typically http://127.0.0.1:9332/static then click on the "graphs" link, each payout address with an active miner will have its own graph.

The payout address does not need to be the same as the address set when starting P2Pool. It will be whatever the miners user name is set to, if the username is a valid address. If the miners user name is not a valid address it will mine to the node default address (this can allow a node owner to name workers and track them individually in the graphs).

I'd strongly suggest not mining to an online wallet, most will not handle coinbase transactions properly.

The error you were seeing is thrown here:

https://github.com/p2pool/p2pool/blob/5090bf5ccd615735b92e55710394ba92d2efcc54/p2pool/p2p.py#L311

Looks like it was caused by a misbehaving peer (to old) that was subsequently banned.

Hope this helps!

[dog1965]

what the hell is this error cant figure out for the life of me what the hell this is or how to fix it ?  


 Error while processing Event callbacks:
2016-02-01 10:45:02.816000 > Traceback (most recent call last):
2016-02-01 10:45:02.816000 >   File "p2pool\node.pyc", line 135, in download_shares
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.816000 >   File "p2pool\node.pyc", line 48, in handle_shares
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.816000 >   File "p2pool\node.pyc", line 297, in set_best_share
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.816000 >   File "p2pool\util\variable.pyc", line 74, in set
2016-02-01 10:45:02.816000 >


also second question what do I put into the antminer S7 and S5 as far as username/?+?  you know the difficulty stuff here is my config line for the s7

???NaahqHpLiZt9GPXUkFoPkQmz4dMH.ant1/2055000 was using the + to but took it out.

[M8BWNNRFMNdak68c]

Important update for users of http://minefast.coincadence.com

Whether you use it as a backup node or primarily mine on minefast.coincadence.com please update your miners today!

We have an exciting announcement coming in the next few days, all I can say at this point is that the domain name will change.

To keep mining uninterrupted please update your miners to use the IP address of the server rather then the domain, the IP will remain the same during the switch and you will not have any downtime.

Set your miners pool URL to:

stratum+tcp://54.235.94.19:9332

Everything else remains unchanged.

so what what about the exiting news you spoke 14 days ago?

at the moment ( through the last day )  i only see a broken website ( no more live date, no miner tables ) and a offline pool ( yes, 54.235.94.19:9332 and not the old url )

is this just another important service leaving the sinking P2Pool-Ship?

[windpath]

Important update for users of http://minefast.coincadence.com

Whether you use it as a backup node or primarily mine on minefast.coincadence.com please update your miners today!

We have an exciting announcement coming in the next few days, all I can say at this point is that the domain name will change.

To keep mining uninterrupted please update your miners to use the IP address of the server rather then the domain, the IP will remain the same during the switch and you will not have any downtime.

Set your miners pool URL to:

stratum+tcp://54.235.94.19:9332

Everything else remains unchanged.

so what what about the exiting news you spoke 14 days ago?

at the moment ( through the last day )  i only see a broken website ( no more live date, no miner tables ) and a offline pool ( yes, 54.235.94.19:9332 and not the old url )

is this just another important service leaving the sinking P2Pool-Ship?

The news is still coming, there is a delay, but it will come Worked out better then initially planned because people have had plenty of time to update their URLs...

As far as the service goes, we're not going anywhere, bitcoind crashed, needed to be restarted, that was all.

[windpath]

...

also second question what do I put into the antminer S7 and S5 as far as username/?+?  you know the difficulty stuff here is my config line for the s7

???NaahqHpLiZt9GPXUkFoPkQmz4dMH.ant1/2055000 was using the + to but took it out.

Short complete P2Pool difficulty guide:

There are 2 allowed switches that you can include after your address/username in P2Pool.

They are defined in work.py starting on line 167.

The "+" = desired_pseudoshare_target

Pseudoshare Target instructs the pool node to provide your miners with work at a FALSELY low difficulty, a difficulty lower then the actual share difficulty. This is beneficial because it allows the graphs on the front end to smooth out instead of just showing spikes, and allows the node to more accurately guess your true hash rate.

The "/" = desired_share_target

Share Target actually sets the real share difficulty for your miners. Any share target below the current P2Pool minimum target is ignored and the minimum P2Pool target difficulty is used, currently 2,180,000

These are the only 2 allowed switches, adding anything else may break your payout address.

Example:

YOUR_BTC_ADDRESS/SHARE_TARGET+PSEUDOSHARE_TARGET

Note: NastyPool had added custom switches to facilitate their PoP payout method, this is specific to their node only.

[Meuh6879]

Yes, it just sucks if it takes you a long time to submit an accepted share and then your work falls off the chain and you never receive anything.

  do the maths :

receive nothing ... and big on P2Pool.
receive a little every days ... on others pools.

result = same reward after 3 months.

many mining owners ... don't wait and want money now.

[Meuh6879]

Of course there's the other problem that happened recently when someone easily 51% p2pool ... and no one seemed to care or even notice

When P2Pool reach the 6PH/s on a short period, it solve 2 blocks per day.
P2Pool is not a proprietary pool ... the software can not be constrain to create a new blockchain.

Because ... like the node of Bitcoin Core, Software of P2Pool not "mutate" by a magic automated and hidded update (like apple device   ).