p2pool - Decentralized, Absolutely DoS-Proof, Pool Hopping-Proof Pool [archival]

[forrestv]

New release! 1b128eb

Important changes:

• Status display greatly improved
• Workarounds that get all miners tested at least mostly working - see first post - cgminer is the only known stock miner that is now completely compatible

Windows py2exe binary on the first post has been updated.

[1715642728]

1715642728

[1715642728]

1715642728

[1715642728]

1715642728

[1715642728]

1715642728

[Operations]

If I'm using cgminer (version 1.5.1) then i see a lot of:

...
[2011-07-27 18:13:25] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:13:25] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:13:38] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:13:38] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:13:38] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:13:41] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:13:41] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:13:41] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:13:47] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:13:47] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:13:47] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:14:05] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:05] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:05] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:20] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:20] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:20] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:14:22] LONGPOLL received after new block already detected
[2011-07-27 18:14:22] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:14:22] LONGPOLL received after new block already detected
[2011-07-27 18:14:22] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:14:22] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:14:49] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:49] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:49] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:14:53] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:53] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:53] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:14:58] Accepted 3d22e40b GPU 0 thread 0
[2011-07-27 18:14:58] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:58] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:14:58] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:15:34] Accepted 1f24ab65 GPU 0 thread 0
[2011-07-27 18:15:34] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:15:34] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:15:34] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:15:46] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:15:46] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:15:46] New block detected on network before longpoll, waiting on fresh work
...

[hawks5999]

hmm... that looks like deepbit's solving speed lately...

[forrestv]

If I'm using cgminer (version 1.5.1) then i see a lot of:

...
[2011-07-27 18:13:25] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:13:25] New block detected on network before longpoll, waiting on fresh work
[2011-07-27 18:13:38] LONGPOLL detected new block on network, waiting on fresh work
[2011-07-27 18:13:38] LONGPOLL detected new block on network, waiting on fresh work
...

That's completely normal. P2Pool blocks happen at a rate of one every five seconds on average, and that work is being pushed to the miners.

[forrestv]

New release! a07e25c

Changes:

• Memory reduction - p2pool now takes 40% less memory!
• p2pool now adjusts to the specific miner daemon using its User-Agent header - less stales
• Share downloading is smarter - faster, more robust sharechain downloads
• p2pool doesn't distribute work until the sharechain is downloaded - elimination of those confusing stales you get when p2pool is starting
• Some minor interface changes: exception reporting, share notification lines

[burp]

Throwing away current work every 5 seconds doesn't seem very efficient to me. What about increasing the block rate? By using p2pool I'm basically wasting more than 30% of my hashing power. ( Reject ratio: 28.7 )

[forrestv]

Throwing away current work every 5 seconds doesn't seem very efficient to me. What about increasing the block rate? By using p2pool I'm basically wasting more than 30% of my hashing power. ( Reject ratio: 28.7 )

What miner and p2pool version are you using? Did you look at the updated information about miners on the first post? By using that I've consistently been able to get <10% stales with all the different miners.

I'm currently working on improving p2pool and the patches to the miners to decrease the reject ratio ... should have some new results in about an hour to further reduce it.

[burp]

Throwing away current work every 5 seconds doesn't seem very efficient to me. What about increasing the block rate? By using p2pool I'm basically wasting more than 30% of my hashing power. ( Reject ratio: 28.7 )

What miner and p2pool version are you using? Did you look at the updated information about miners on the first post? By using that I've consistently been able to get <10% stales with all the different miners.

I'm currently working on improving p2pool and the patches to the miners to decrease the reject ratio ... should have some new results in about an hour to further reduce it.

Latest cgminer and p2pool. It's not about the stale number that p2pool displays, that is ok. But because of the frequent new blocks much work is wasted and the rejection percentage of cgminer is about ~30%.

EDIT: OK, for everyone else that might think like me. Forrestv just made something clear to me in IRC: Work is not really "wasted", because these mini blocks serve as a method for calculating the payout. And submitted results that qualify as a real block solution give still payout to everyone using p2pool even if it's stale.

[gigica viteazu`]

this is great, i intend to switch my 2.5Gmh/s to p2pool soon

[forrestv]

New important release! - please upgrade! 9037c07

• New best-share selection strategy - will reduce stales, but everyone needs to upgrade!
• Worker interface improvements that should also reduce stales (including added information about several additional miner daemons)
• Miscellaneous interface improvements and code cleanups

Please upgrade to keep the p2pool network healthy! The Windows EXE on the first post has been updated.

EDIT: I'm getting ~5% stales on the miner using poclbm with the patch on the first post:

Code:

./poclbm.py http://9dfa:ada@127.0.0.1:9332 --verbose -d1 -f 100 -w 128 -v
...
127.0.0.1:9332 29/07/2011 05:23:49, [395.838 MH/s (~319 MH/s)] [Rej: 5/134 (3.73%)]

[gigica viteazu`]

last update gives me 50 rejects from 60 submited shares using cgminer

[forrestv]

last update gives me 50 rejects from 60 submited shares using cgminer

Hm ... there might have been a regression, though I'm testing cgminer right now, and while it does worse than poclbm (~15% stales), it's nowhere near what you report. Are you talking about the stales that cgminer tells you or the stales that p2pool reports?

Can you paste a few lines from both cgminer and p2pool? And try running p2pool with '--debug' for a while and then upload the 'debug.log' file somewhere?

Thanks, sorry!

EDIT: Are you using multiple pools? burp_ reports that that can cause problems with cgminer and long polling.

Also, cgminer doesn't check shares against the actual target, it just submits all difficulty-1 shares, so getting up to half rejected on the miner and lots of 'Invalid share' messages in p2pool is normal for it. You're not losing any work.

Want to get on IRC? #p2pool on freenode if you're interested ...

[forrestv]

Everyone interested in participating or already participating: Post a pledge for mining power on http://forum.bitcoin.org/index.php?topic=32882.0

[forrestv]

New release! fbedaf9

Major changes:

• Miners can connect with a Bitcoin address as the username to direct payouts to that address - set up a public node and invite people to mine on it!
• Drawing of share chain - use option --charts and go to http://127.0.0.1:9332/chain_img
• UPnP support - automatic port forwarding to help the P2P network
• IP transactions work
• Peer count displayed on status line
• Forward compatibility for merged mining
• Two new bootstrap nodes
• Better version detection
• Reduced CPU usage

Binaries are on the first post.

EDIT: If you have multiple mining clients make sure they have unique usernames. p2pool internally tracks the state of miners by their usernames, and you will get a lot more stales if they are confused.

[LightRider]

This is a great idea and I hope it catches on. I think a p2p strategy in all aspects of BTC is a good one. Well done!

[twmz]

EDIT: If you have multiple mining clients make sure they have unique usernames. p2pool internally tracks the state of miners by their usernames, and you will get a lot more stales if they are confused.

I assume you're accounting for the fact that some miners (cgminer, diablominer) use a single miner instance with many threads (2 per GPU, usually) that all use the same credentials.  This is equivalent to multiple miners all sharing the same usernames.  I don't think it is reasonable to forbid this behavior (or punish it with high stale rates).

[forrestv]

New version! fbedaf9 Windows binary: http://u.forre.st/u/weclcaad/p2pool_win32_b324a68.zip
See first post and the wiki for instructions.

Major changes:

• Namecoin and Ixcoin support! Use --net=namecoin or --net=ixcoin
• Dropping of old shares - p2pool's memory usage no longer grows slowly over time
• Caching of shares and block headers on disk - after starting p2pool, it's ready to mine in less than a minute
• Display of median stale rate for users and individual efficiency - no more worrying about stales
• Improved communication with miners - less stales
• Removed resource leaks and huge bandwidth usage under some configurations due to UPnP
• Work isn't given to miners if bitcoind dies
• Miscellaneous memory and speed improvements
• Reopens debug.log on SIGUSR1 for log rotation

Join the #p2pool channel on Freenode for discussion!

[rdponticelli]

Hi. I'm trying p2pool and I have some doubts. Last night I left it working on a server, with a couple of client miners, and this morning I found it was frozen. It seems that it got frozen after 12 hours of being running, or something like that...

Somebody else has experienced this kind of problem?

There was no logs useful for tracing the problem. It was just hanged somewhere on the normal loop, and I have had to SIGKILL the process and launch it again.

Another doubt is: what happens with all of yesterday's work? It's remembered by the network and will be payed if a block is found, or it's wasted?

And last. When the logs says: "Payout if block: x BTC"

That amount is what will be payed if my node finds the block or it's the payment without counting the subsidy?

Thank you.

[forrestv]

Hi. I'm trying p2pool and I have some doubts. Last night I left it working on a server, with a couple of client miners, and this morning I found it was frozen. It seems that it got frozen after 12 hours of being running, or something like that...

Somebody else has experienced this kind of problem?

There was no logs useful for tracing the problem. It was just hanged somewhere on the normal loop, and I have had to SIGKILL the process and launch it again.

I'm guessing you're on Windows? I haven't been able to reproduce this problem. However, if you run p2pool with --debug, it will produce a lot more messages and log them all to debug.log, which might be useful.

Another doubt is: what happens with all of yesterday's work? It's remembered by the network and will be payed if a block is found, or it's wasted?

It's forgotten. p2pool pays the last N shares (PPLNS payout method, used by several other pools too), which is provably fair and invulnerable to pool hopping. It does seem kind of unfair now, but once p2pool grows to get one block per day, all work will get a payout.

And last. When the logs says: "Payout if block: x BTC"

That amount is what will be payed if my node finds the block or it's the payment without counting the subsidy?

That exact amount would be paid to you if the pool found a block at this moment.

[rdponticelli]

Hi. I'm trying p2pool and I have some doubts. Last night I left it working on a server, with a couple of client miners, and this morning I found it was frozen. It seems that it got frozen after 12 hours of being running, or something like that...

Somebody else has experienced this kind of problem?

There was no logs useful for tracing the problem. It was just hanged somewhere on the normal loop, and I have had to SIGKILL the process and launch it again.

I'm guessing you're on Windows? I haven't been able to reproduce this problem. However, if you run p2pool with --debug, it will produce a lot more messages and log them all to debug.log, which might be useful.

No. It's a Debian server. Anyway, I'll let you know if the problem shows up again. I'm now running the git from yesterday.

Another doubt is: what happens with all of yesterday's work? It's remembered by the network and will be payed if a block is found, or it's wasted?

It's forgotten. p2pool pays the last N shares (PPLNS payout method, used by several other pools too), which is provably fair and invulnerable to pool hopping. It does seem kind of unfair now, but once p2pool grows to get one block per day, all work will get a payout.

So everytime I stop the pool -let's say to launch the latest git version, or to change the payment address- I lose all work of every worker? I think that this has to be worked out. I understand PPLNS, and let's say that I agree with its fairness. Anyway, downtimes will always happens, and I think that that work shouldn't be wasted.

And last. When the logs says: "Payout if block: x BTC"

That amount is what will be payed if my node finds the block or it's the payment without counting the subsidy?

That exact amount would be paid to you if the pool found a block at this moment.

Thank you. Great work.