Another payment sent.

Here is the list of transactions:

2/28/12 - http://blockchain.info/tx/7f5658c8cd2868cfc87e1ed921be74b80c06b0cb8c60b98fa709b0a23d971c31
2/29/12 - http://blockchain.info/tx/02cfe0ee7caa9342127b6c2255e22033c386bc9863da9e837e45c0e3bb7ddbca

All of the places you are talking about have "accounts" where people can log in and choose their preferred payout amount.  P2PMining, like Eligius, doesn't have accounts.  People just use their payment address as their username.  Probably the only safe way to let people specify their preferred payout amount (vs setting it to some reasonable default, which is what JayCoin has done thus far) is to create some web page where people can submit their preference digitally signed by their payout address's private key.

That's a fair amount of effort, would be not entirely obvious for people to understand, and has minimal benefit because IMHO the existing minimum is pretty reasonable (who want's to get paid one nickel at a time anyway?)

No, it will not generate any income, and I don't think it provides any practical help to the p2pool network.  At the same time, it doesn't really hurt anything, either.

I don't know (ask forrest), but it does.  I just looked at the HTTP header it returns and it says 10 seconds.

All of your reasons for why it doesn't matter are correct but you are wrong that it isn't supported.  But, p2pool does use RollNTime (with a 10 second expiration).

Several people asked, so I enabled p2pool sig and avatar image generation for p2pool miners at btcstats.net.  Just go to http://btcstats.net?p2pool and enter your payment address to get your sig or avatar image URL.

Please note, that the hashrate shown is highly imprecise (just like the one at p2pool.info -- its really the same data source). The hashrate show is an estimation based on the number of high-difficulty shares you have found in the past 24 hours.  For most miners, variance will cause the estimated hashrate to vary significantly.

Also note that you can't use the sig image here because bitcointalk.org has disabled adding images to sigs.  You can, however, use the avatar image here.

If you believe that to be true, please present some math to explain it.  I believe it doesn't make a difference. I may be wrong but you aren't convincing me without a more detailed explanation of your concern.

Here are two scenarios.  In both, I am mining and you are mining. In a given period of time, I am mining at 4 GH/s and find 1000 shares.  You are mining at 8 GH/s and find 2000 shares.

Scenario 1 : P2Pool (9% of shares are stale)

Of the 1000 shares I found, 90 were stale.  So I found 910 valid shares.
Of the 2000 shares you found, 180 were stale.  So you found 1820 valid shares.

I found 910 out of (910 + 1820) total shares.  That is 910/2730 or 33.333% of shares and so I will get 33.333% of each block payment.  That is, not coincidentally, the same as the the percentage of my hashrate (4 GH/s) vs the overall pool hashrate (12 GH/s).

Scenario 2: Normal Pool (let's say 0.1% of shares are stale)

Of the 1000 shares I found, 1 was stale.  So I found 999 valid shares.
Of the 2000 shares you found, 2 were stale.  So you found 1998 valid shares.

I found 999 out of (999 + 1998) total shares.  That is 999/2997 or 33.333% of shares and so I will get 33.333% of each block payment.  That is, not coincidentally, the same as the the percentage of my hashrate (4 GH/s) vs the overall pool hashrate (12 GH/s).

Conclusion

Rate of stales doesn't matter as long as everyone is getting them with the same frequency and as long as the frequency of blocks being found is not reduced (which you agree isn't a concern in the p2pool case).

Well, the p2pool.info page pretty clearly said that any donations to that address would be redistributed in this way, so it's not that generous (since the person who made the original donation expected this to happen).

In case people want to donate to p2pool.info directly, I'll add a separate address for that on the page.

Someone made a donation to the address I list on p2pool.info.  Over the next few days, I will be sending it to the p2pool miners using the patron_sendmany algorithm.  

Here is the list of transactions:

2/28/12 - http://blockchain.info/tx/7f5658c8cd2868cfc87e1ed921be74b80c06b0cb8c60b98fa709b0a23d971c31
2/29/12 - http://blockchain.info/tx/02cfe0ee7caa9342127b6c2255e22033c386bc9863da9e837e45c0e3bb7ddbca

Someone made a donation to the address I list on p2pool.info.  Over the next few days, I will be sending it to the p2pool miners using the patron_sendmany algorithm.  

Here is the list of transactions:

2/28/12 - http://blockchain.info/tx/7f5658c8cd2868cfc87e1ed921be74b80c06b0cb8c60b98fa709b0a23d971c31
2/29/12 - http://blockchain.info/tx/02cfe0ee7caa9342127b6c2255e22033c386bc9863da9e837e45c0e3bb7ddbca

One interesting difference from a normal pool is that he can successfully be a small/tiny pool but without the normal small/tiny pool variance and long intervals between blocks.  The 4GH/s of miners are dividing up 1 BTC a couple times per day instead of dividing up 50 BTC every couple weeks.

Having a massive pool that just points at p2pool doesn't make much sense (and is counter to the point of p2pool), but having a bunch of small pools all doing this doesn't seem like a bad thing.

It also affects people who have bitcoin with a crappy network connection, because if all the blocks you find end up being orphaned because of a poor bitcoin configuration, you will not get the block finder bonus you were due.

Keep in mind that it's not an "extra payment" (as "bonus" might imply) since is taken out of the available 50 BTC for the block.  In other words, every non-block finder gets a little less than they would normally have if the entire block was being split.  Because blocks are found (over time) proportionally to the hashrate of the miners, it ends up being a wash in the long term.  You make a little less in the blocks you don't find, but you make more for any blocks you find, and the two offset each other over time.

So it ends up being neutral for people who are doing everything correctly and it is a penalty for anyone who is not doing things correctly (either bad bitcoin setup or intentionally withholding blocks).

The 2.0 version of my stats page is now live.  Here are the changes:

• It is now running on a healthy web server (btcstats.net was acting funny) and I gave it its own domain.
• The backed is now based on bitcoind directly (with a patch to get full block details) instead of being dependent on blockchain.info and blockexplorer.com.  Eventually, I will add those two back in as transparent fallback options, though.
• The issue with active user count being too low is fixed.  Active users now includes anyone who submitted a valid share in the past 24 hours instead of just in the past 2 hours.
• It now display the current payouts.  You can star your own address so that it is easier to find in the list.
• It now display a list of the active users and their hashrates.  Note, hashrates are very iffy as they are based on the shares each has found over the past 24 hours.  The jury is still out on if these estimates are reasonably close to accurate.  I spot checked a few and they seemed to be within 10%, though.
• Orphaned blocks are now shown greyed out, if the site knows about them.  Sometimes an orphaned share will never make it to my site, so they may not all show up.  But if they do, they are now indicated as orphaned.
• You can now disable the audio alert when a block is found (see Settings in the upper right).  Note that this setting is per browser.

I just pushed the button to switch over to the new site and so I'm considering it beta for the next 24 hours.  It has been working well for me, but I did rewrite a lot of it in the last couple days so I may have broken something that used to be working.  Let me know if you see issues.

http://p2pool.info

That's normal.  Blocks that happen to be stale shares (because they were found after someone else found a share but they happen to have been found before the bitcoin network found a new block) are transmitted over the bitcoin network (so that everyone get's paid), but are not included in the p2pool share chain and are not transmitted throughout the entire p2pool peer to peer network, so the announcements only appear on the node that found the block and on that node's immediate neighbors.

To get the full list of blocks you can check your own bitcoin transaction logs (assuming your hashrate is high enough to ensure you have at least 1 share in all blocks) or look on blockexplorer or blockchain.info for at the donation address 1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4.

I also maintain a list of found blocks at http://btcstats.net/p2pool/ that has recently been updated to redundantly utilize all these sources of information to create as comprehensive of a list of blocks as possible.

Sorry to hear about the recent struggles.

I noticed that transaction timestamps are not accurate for some transactions.  I assume this is related to the downtime.  

For example, these three transactions appear to be at the same time (10:55:56 UTC) which I assume is the time that the servers came back up:

http://blockchain.info/tx/ee110ffd1d9ae7147694ce541321d21f060cacf44ed88bebc80c483fd00c5684
http://blockchain.info/tx/d45c56dd94bc644c3f15a45c5760516353a0c345043dc46ac4733e086e4c82c0
http://blockchain.info/tx/dd16af39e22ec4d6cd3653000b134ca979df55f4f91130066ba39a25514a3d23

I assume you aren't planning to backload more accurate timestamps (e.g. the time from the block header) and that I should work around this myself?  

I confirmed that everything is working as designed but that the design was flawed.  The number of users in the graph accuratly replicates what p2pool reports.  The problem with using that statistic is that the http://localhost:9332/users page only shows people that have submitted at least 1 share in the past 2 hours.  Small miners may not always find a share that often, and so aren't getting recognized.  I'll have to consider alternate approaches to approximating the number of users...

Stay tuned...

This site does not use RRD.  It takes the output of http://myp2poolserver:9332/users and parses it to determine the number of users.  It does this once every 5 minutes.  That said, it could be broken.  I'll review it tonight to see if it is counting wrong.

I think it was added to make debugging miners easier.  instead of having to wait ages for your miner to find shares just to see if your miner is working correctly, you can see pretty quickly if your miner is working because it is finding shares at a fairly normal pace.  it doesn't cost p2pool much processing power to just filter those low difficulty shares out when they get submitted.

It also made it possible for p2pool to report and graph a reasonably accurate local hashrate with lower variance.

All that said, I agree with you that a front to p2pool for smaller miners would be useful.  But to not completely defeat the purpose of p2pool it would be better if there were many dozens of these that get setup instead of only a few large ones.  Otherwise, we just end up with what we have today--a handful of large centralized pools.

Have you successfully mined with that computer with other pools?  Or is this behavior specific to p2pool. On the surface that hardware looks sick (lots of hardware errors (HW)).

Note, the frequent long polls are normal.

I think it was added relatively recently.  Maybe 3-4 weeks ago?