Fixing it now.  I had a power failure and when the computers restarted, the wrong version of bitcoind started up which caused problems with the p2pool.info block detection code.

I have explained it in great detail at least twice in this thread.  Please search for the the answer.

I don't believe the luck calculations are wrong, and no one who has looked at it has found any errors. I have also compared the calculated luck to my actual earnings and they are consistent.  I believe we really have found only 90% of the blocks that a "perfectly neutral luck" pool would have over the past several months. 

I don't know if it is just bad luck or if there is something else going on (someone withholding block solutions, etc), but I don't think it is an error in how luck is being calculated or displayed.

I'm assuming you're letting p2pool auto-pick an address for you instead of just telling it what address you want it to use.  If so, then when p2pool starts up, it displays the payment address it auto-picked for you.

Yes, that is the reverse of what I did to get the totalRoundShares in the first place.  I take a weighted average of the hashrate data points (taken every 5 minutes) and use that with round duration to calculate the round shares.  If you are looking for the hashrate, it would be easier to just get them directly from http://p2pool.info/stats instead of reverse engineering them from the block data

Round duration = Timestamp of the block that was just found - Timestamp of the block before that

As previously discussed "round shares" is actually a calculated value that is derived from the round duration and hashrate during that round.

Block timestamps are not precise.  First, they are based on miner's clocks which may not be accurate.  Second, with ntime rolling, they may have been arbitrarily adjusted.  Sometimes when a block that comes very shortly after another block ends up having a timestamp earlier than the block it came after.  When both blocks happen to be p2pool blocks, that makes the round duration (and therefore, also the round shares) negative.

The p2pool.info UI just hides this oddity.  

The small variations in block timestamp go both ways.  Sometimes a block's timestamp will be a little bit ahead and sometimes it will be a little bit behind.  So these small variations average out in the long term.  They are left in the raw data so that the luck calculations will be unaffected.  For example, some rounds will be 100 shares to high while other rounds will be 100 shares too low.  Since luck is basically "SUM(shares in some rounds) / SUM(expected shares for those rounds)" it doesn't matter if the rounds are 105 + 95 or 100 + 100.  As long as the average variation in timestamp is "0", it doesn't affect luck calculations.

And yes, as has been suggested in the past, it would be more accurate to count the actual hashes in the share chain to know exactly how many hashes went into finding a block.  But there are a number of technical challenges to making that work and the improvement in accuracy isn't enough to make it worth it to me to do that work.

Another alternative to the suggestions already made is to go create a wallet at blockchain.info.  Then add your payment address to that wallet.  You can add it as a public-key-only address and just have blockchain.info monitor the address for transactions without it worrying about having it fully enabled with the private key.  They have an email notification system that can notify you when you receive a payment at that address.

Historically, not all blocks get announced in every p2pool node with a message like you listed there.  That has recently changed, in theory.  Once you have the block hash, you can get details of the block either from bitcoind using the getblock RPC call or from blockchain.info's or blockexplorer.com's JSON APIs.

Also, you don't need to scrape p2pool.info to get the list of p2pool block.  There is a JSON API you can just call to get the raw data if you want it:  http://p2pool.info/blocks  Of course you have to do some post processing if you are wanting to confirm that your address was paid in any given block.

I had exactly the same problem on one of my units (it was at the stock firmware).  The symptom was that, only under linux, it would die when it throttled.  I sent it back to BFL but they never found a root cause as far as I know.  Under Windows, it was stable (it just slowed down when it throttled instead of dying).

Also, it's random (with a probability equal to the percentage you set) that any given share will be redirected to your node's address.  So you'll not necessarily get exactly 5 out of the first 1000.  It'll end up averaging that in the long term, though.

Stupid question, but is someone mining at your node and passing in their own bitcoin address as the miner username?  That's the only time you're going to see a fee taken out.  If no one is mining, there is no fee.  If they are mining, but not overriding the payment address with their username, then they are essentially giving 100% of their mining to you (to the default payment address).

Sorry, you are right.  I shouldn't answer questions early in the morning right after I wake up.

Use a different username for each rig or gpu and then look at the graphs.  There will be a separate graph for each username and you can see individual stale statistics for each.

Without connecting to it?  I might guess it was p2pool if the port was 9332 since that is not commonly used for other bitcoin pools.

If I can connect to it, then p2pool includes a "X-Is-P2Pool: true" HTTP header in its response to a getwork request.

It's wouldn't call it buggy since it's doing exactly what it was designed to do:  when a peer announces a block, p2pool passes it on to the local bitcoin node.  It's apparently just simplistic and doesn't attempt to keep track of blocks that it already told the local node about. 

Also, the recent update just made p2pool more agressive about telling peers about blocks and so maybe you're seeing more messages about them.  I don't think it hurts anything and I wouldn't change it since agressive distribution of blocks is a good thing in order to reduce orphaned blocks (which we have had more than our fair share of).

Yes!

I quietly added support for ozcoin to http://btcstats.net and just didn't tell anyone

You're welcome to use that until Graet makes something awesomer:

http://btcstats.net/?ozcoin

For example:





Obviously, you can't effectively use the sig version anymore, but it is there in case people are using other, non-broken, forums as well.

This wasn't about unplugging and plugging a device in.  It was about crashes.  If the BFL unit fails at some point (as is happening with one of mine), it used to just die and be dead forever.  Now, it goes into a disabled state and you can attempt to restart it from the API without having to completely restart cgminer.

I don't think anything has changed with hotplug support (i.e. it's still not supported).

It's certainly possible, but I wanted to add that p2pool.info now also asks blockchain.info for a list of all blocks (including orphaned blocks) that include the p2pool donation address.  I trust that blockchain.info is much more likely to have seen all orphaned blocks (excluding the recent downtime) given that they connect to almost every publicly accessible node.  I think the likelyhood of unnoticed  orphaned blocks is very low at this point.


I believe forrest just commited this change to the git tree last night.

There have been on and off discussions of if the p2pool.info luck calculations are somehow wrong (i.e. too low) because of some error in the estimated hashrate, etc.

I did an experiment with independent data to see how it compared and here are the results.

Instead of looking at anything from p2pool, I looked at my payments over the past 30 days.  My personal p2pool hashrate has been unchanged during the past 30 days and I have a detailed record of every share I have found, so I am certain what my hashrate was during that duration.  Note, I did happen to be the block finder for one of our blocks in the past 30 days, and so I did even receive a bonus payment to counter balance all the other blocks where I didn't receive the bonus payment, so that effect is mostly washed out.

Taking the difficulty changes into account, I calculated what my expected payment should have been over the past 30 days given my hashrate.  I compared that with what I was actually paid.  Over the past 30 days, I received 78% of amount that I was expected to have received given my hashrate.  The luck calculation from p2pool.info (which is based on average pool hashrate and blocks found) calculates that the past 30 day luck is 77%.

77% global luck vs 78% personal luck.

That makes me pretty comfortable that the p2pool.info luck calculation approach is not fundamentally broken and off by 10% or something. 

If anyone else sees a different pattern in their own personal payouts, that would be interesting.

I also have a unit that is less tolerant of higher than supported ambient temperatures.  The room is 75 instead of 72 and one of my singles throttles regularly while the other never does. Until I can try EasyMiner's tuning, I have been trying to improve airflow in hopes that I can reduce throttling as much as possible. 

To that end, last night I removed the U-shaped cover piece to the unit that was throttling (the piece that wraps around the sides and the front) to expose the heatsinks and fans.   With that piece removed, the device stopped throttling in the 75 degree ambient temperature.  Note, I do have a room fan pointed at the table these are sitting on and so my assumption is that with the case removed, that room fan is providing enough additional circulation to offset the increased ambient temperature.

So it's something you might want to try.  Note, to remove this easily, you only want to remove the 4 small screws on the sides (2 per side).  The "back" is the side with the USB and power connections.  There are 4 small screws there you want to leave alone.

Side note: I hope EasyMiner's speed adjustments will be persisted in nvram or something?  So, if it is a windows-only app, I can make the adjustment and then move the Single back to my linux rig?  If not, please make the protocol for adjusting the speed public so that the cgminer developers can add this feature directly.