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

[twmz]

Anyone know what is wrong with the pool over the past day or so?  I don't see anything in the recent code changes, but the pool seems to be finding way more blocks that it is supposed to, so something is apparently wrong...

[1713886347]

1713886347

[1713886347]

1713886347

[1713886347]

1713886347

[Red Emerald]

Anyone know what is wrong with the pool over the past day or so?  I don't see anything in the recent code changes, but the pool seems to be finding way more blocks that it is supposed to, so something is apparently wrong...

lol. "We are making to much money! Something is wrong guys!"

It's called luck.

[forrestv]

Anyone know what is wrong with the pool over the past day or so?  I don't see anything in the recent code changes, but the pool seems to be finding way more blocks that it is supposed to, so something is apparently wrong...

lol. "We are making to much money! Something is wrong guys!"

It's called luck.

Whoooosh.

[stevegee58]

One does not even imply mentioning the L word. Even indirectly. Silence.

FTFY

[twmz]

Anyone know what is wrong with the pool over the past day or so?  I don't see anything in the recent code changes, but the pool seems to be finding way more blocks that it is supposed to, so something is apparently wrong...

lol. "We are making to much money! Something is wrong guys!"

It's called luck.

Since bad luck is almost often blamed on the pool being broken, I felt like it was important that someone question the proper functioning of the pool when we have good luck to keep things fair and balanced.  (in other words, it was sarcasm)

[PatMan]

Nothing like a bit of luck to break the silence eh?

I'm genuinely happy for you all, really. But for my setup it still isn't worth switching back just yet, I'll wait until the wee bugs in stratum & memleak have been ironed out first I think, as I'm still earning consistently at ozcoin to be honest, suits my setup much better at the moment. Never had such a low reject rate - currently @ 986% efficiency on stratum - I just don't get that here.......yet

Besides, one good day in 60 isn't enough to sway me over, but I'll keep an eye on how you're doing here, and when it's ready, I'll be back......

Enjoy the coinage. Viva p2p.

[Aseras]

Of course as usual someone had to mention luck and kill it.

[forrestv]

I believe the memory leak is fixed in git. Can everyone who can pull and notify me if memory is still leaking?

[rav3n_pl]

I believe the memory leak is fixed in git. Can everyone who can pull and notify me if memory is still leaking?

Share chain files need to be deleted.
If not it spikes to 500MB and holds there.
After delete files it holds on 300MB.
Ubuntu x64 4GB

[cabin]

On windows 7 mine holds at 190MB

[Balthazar]

p2pool's main problem is being penalized for including transactions.

P2pool miners are protecting the network against >50% attacks. That is a HUGE benefit for the bitcoin network.

GBT and BlkPrep users are protecting network against >50% attacks. In fact, P2Pool users are really doing nothing in comparison with them (300-400GH/s vs. 2-3 Thash/s). For now.

[forrestv]

p2pool's main problem is being penalized for including transactions.

P2pool miners are protecting the network against >50% attacks. That is a HUGE benefit for the bitcoin network.

GBT and BlkPrep users are protecting network against >50% attacks. In fact, P2Pool users are really doing nothing in comparison with them (300-400GH/s vs. 2-3 Thash/s). For now.

What's your source for 2-3 TH/s?

[lenny_]

I believe the memory leak is fixed in git. Can everyone who can pull and notify me if memory is still leaking?

Please check my node:
http://lenny.dnsd.me:9332

Code:

Version: 11.1-5-g0e325a4
Node uptime: 0.486 days Peers: 6 out, 2 in

Not yet 12 hours uptime and already 671MB usage, according to Memory Usage details on Graph tab. I am running out of memory now as I have 1GB RAM on this machine. Soon I will have to turn it off - there is no change in memory usage since December 2012. It's still very high and unusable for me.
Current stats (I wrote simple script to print this information)

Code:

17269 pioruns   20   0  811m 639m 1776 S    4 64.6 275:51.43 python                                                                                          
17436 pioruns   20   0  601m  91m 7752 S   20  9.3  44:15.31 bitcoind                                                                                        
Linux 2.6.32-5-amd64 x86_64 GNU/Linux
Description:	Debian GNU/Linux 6.0.6 (squeeze)
Python 2.6.6

Current p2pool version: 11.1-5-g0e325a4
commit 0e325a45dc1c1d40eabcf066c3b52a381ece569a

Current version: Bitcoin version v0.7.1-404-g0d3d609-beta
commit 0d3d6094faf0da252c581d58454ecc4be91aacb9

EDIT: As I finish editing this post and checking posts, it's already 681 MB on graph menu and 648 MB in top (was 639 about 15 minutes ago) ...

forrestv, what I can do for you to help debugging?

[twmz]

FYI, I broke something with one of the servers that sit behind p2pool.info this weekend and the result was it was mis-reporting some blocks as orphaned (that weren't really orphaned).  It's being fixed now...

[cabin]

Regarding this message: Punishing share for 'not all txs present'!

Does this mean that nodes that don't include all transactions will have their shares punished and therefore more likely to be orphaned?

[forrestv]

forrestv, what I can do for you to help debugging?

Lenny, simply upgrading to the most recent commit in git will help. I think that 11.1-6-g19bf4ea solves the leak.

Regarding this message: Punishing share for 'not all txs present'!

Does this mean that nodes that don't include all transactions will have their shares punished and therefore more likely to be orphaned?

No, the "not all txs present" punishment is for when a share isn't accompanied by all the transactions it says it contains (as opposed to all the transactions it could possibly contain). Are you seeing it a lot? That message should be very rare.

[cabin]

Ok thanks that makes sense. No I don't see it often at all.. maybe just a few times right after I start p2pool.

forrestv, what I can do for you to help debugging?

Lenny, simply upgrading to the most recent commit in git will help. I think that 11.1-6-g19bf4ea solves the leak.

Regarding this message: Punishing share for 'not all txs present'!

Does this mean that nodes that don't include all transactions will have their shares punished and therefore more likely to be orphaned?

No, the "not all txs present" punishment is for when a share isn't accompanied by all the transactions it says it contains (as opposed to all the transactions it could possibly contain). Are you seeing it a lot? That message should be very rare.

[Rogue Star]

Lenny, simply upgrading to the most recent commit in git will help. I think that 11.1-6-g19bf4ea solves the leak.

I'm still seeing the leak on my node on the latest code, so you might want to check that out when you get a chance. Another odd thing I noticed on the stats page is it is showing solved blocks >24 hours old

[rav3n_pl]

I believe the memory leak is fixed in git. Can everyone who can pull and notify me if memory is still leaking?

Version: 11.1-6-g19bf4ea
Ubuntu 64bit 4GB
When I run it on "old" sharechain (over 24hrs offline) it bumps to about 520MB
When I delete share chain and allow to re download, it walks to about 300MB and holds there.

There is still something wrong in chain handling imo (maybe txes are not cleared?).
Maybe add a check - if node starts over 12hrs after last share in chain delete it completely and redownload?

Also I still thinks, that txes should be sent on demand, not to all connected nodes. "Peer sent entire transaction..." is seen too many times in log...

[K1773R]

I believe the memory leak is fixed in git. Can everyone who can pull and notify me if memory is still leaking?

Version: 11.1-6-g19bf4ea
Ubuntu 64bit 4GB
When I run it on "old" sharechain (over 24hrs offline) it bumps to about 520MB
When I delete share chain and allow to re download, it walks to about 300MB and holds there.

There is still something wrong in chain handling imo (maybe txes are not cleared?).
Maybe add a check - if node starts over 12hrs after last share in chain delete it completely and redownload?

Also I still thinks, that txes should be sent on demand, not to all connected nodes. "Peer sent entire transaction..." is seen too many times in log...

on demand -> ask if he knows the TX, if he says no send the TX to him.