In experimenting with bitpenny and p2pool which both set work unit target difficulty to something other than 1, it is apparent that cgminer does not honor the target that is include in the getwork response and instead submits every share that passes difficulty 1 even if the actual target difficulty is higher.  For example, on bitpenny, shares are all difficulty 8.  This leads to most shares being rejected because they are not valid difficulty 8 shares.  In the grand scheme of things, this doesn't hurt anything, except it makes the stats and output of cgminer fairly broken because the reject rate is very high and the log is filled with mostly rejected invalid shares.

I understand that the kernels appear to return any share that looks like it passes the difficulty 1 target.  Instead of changing the kernels (which probably would slow them down), you could just double-check the returned hash to see if it is truely valid before submitting it.  This appears to be what phoenix and the latest version of luke's (and maybe the mainline) poclbm do.

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).

You'll have to define what you mean by broadcast, then.  A transaction (assuming it isn't a spam transaction) is transmitted to all other nodes through the p2p network almost instantly by the standard client.  However, it won't get a confirmation and it won't show up in blockexplorer until it is included in a block by a miner.  That delay has nothing to do with the client (i.e. no other client can possibly make that go faster).  That is just how bitcoin works.  You can ensure that your transaction gets included in a block as fast as possible by including an appropriate transaction fee.  Zero fee transactions take longer.

You can also see unconfirmed transactions almost immediatly (those that have been transmitted but not yet included in a block) at http://bitcoincharts.com/bitcoin/.   Search for either the destination address or for the amount you sent (assuming it was a fairly unique amount and not 1.0).

He is probably talking about 0/offline.  If your blockchain is out of date, you can't send transactions to the network.  The client makes you wait until your copy of the blockchain is caught up.

I have been pointing some miners to bitpenny for the last day or so and I can say it has been working well.  My effective hashrate (based on found shares) has been a bit more spikey with difficulty 8 work units, but that is to be expected.  My 24 hour averages are right where they should be and my % stales are as low as on any pool I've used (~0.3%).

The closed source binary isn't ideal, but doesn't bother me all that much.   I do hope that the daemon will be opened up at some point, but I wouldn't review it line by line even if it was, so it makes little difference to me, personally.  I have it installed on an isolated mining rig that has no wallet or other data to steal (not that I have any reason to believe it would try).

I hope others will find bitpenny appealing and the combined hash rate will increase to a sustainable level (15 GH/s is not enough, IMHO, given the current difficulty).  I also wish the fee was 1% instead of 3%, but I understand that until the pool grows large, it may not be possible to cover costs with only 1% fees.

I like the concept of pools like bitpenny and p2pool which allow people to pool their efforts without putting the network at risk by centralizing too much power over the blockchain.

I made a purchase from Trader Steve last week.  He was very helpful and the product arrived in good shape and earlier than expected.

FYI, the current code appears to have lost the ability to call RPCs (at least from the command line).  I get:

My interest would be in these two things (in priority order):

• Integrate wallet encryption (is done in core, just needs GUI)
• Print/import/export private keys (is done in core with pull request, just needs GUI)

And for that matter, I would be fine with import/export only being available from the command line and not in the GUI at least initially.

FYI, the current requirement enforced by the satoshi client (aka the official client) is 0.0005, not 0.005.  And the official client only requires 0.0001 to relay "spam" transactions.  Free transactions that don't trigger the spam detection rules are still and always have been permitted with no transaction fees (you just can't send create 0 fee transactions with the official client).

You risk losing money that way.  If a transaction looks like spam but doesn't have the required fee on it, not only will it not be included in blocks by the standard client, but it will also not be relayed through the P2P network by the standard clients.

Just pay the fee (0.0005).

Yes.  

Regarding Proportional / Pay Per Share isn't it the case that once the pool is in a round that has taken it into the negative, that there is no incentive to stay at the pool.  i.e. As long as there is at least one other pool somewhere that is not in the same situation, it makes sense to hop to them because staying at Eligius when the pool's funds are exhausted means getting paid possibly significantly below "normal reward per share" with no counterbalance mechanism in future rounds.  

It's not as obvious in the sample graphs because the unlucky streaks are mostly at the end and the graphs don't show what happens if those 14 days were followed by 2-3 days of better than average luck.  All of the schemes other than Prop/PPS would have shot back up and gotten close to the overall theoretical PPS line, but Prop/PPS would have stayed 1.5 BTC below that line forever.

Bailing on a Prop/PPS pool when it goes negative is a different kind of hopping than 43% hopping that doesn't harm the other miners on the pool by taking earnings out of their pockets.  That said, if everyone does it, then the pool shrivels up and dies if even a 3-4 day long bad luck streak ever happens.  What am I missing?  I feel like I must be missing something since so many people are voting for it.

Any thoughts on recoding the payout system as part of this? 

Knowing if payouts would still be exclusively via ~50 BTC generate txs or if you are looking at mixing in (or otherwise using in some automated way) sendmany txs will make a difference in which reward methods I would vote for.

I think it is extremely useful.  There is a lot of misinformation floating around and having a thorough and transparent analysis of the various methods will help clear the fog.

That's not what he meant.  He meant your argument was B.S. (and I agree with him):  http://en.wikipedia.org/wiki/Straw_man

Correct.  Things won't be an worse for you than they have been in the past.  

Besides increasing efficiency (which really only matters directly to pool operators or to those with super tight bandwidth or high bandwidth costs), ntime rolling helps protect miners from communication delays on the pool they are using.

Miners incrementing the timestamp (aka ntime rolling) are not as dependent on the pool being able to respond promptly to requests for new work units every 10-20 seconds.  If a pool is stressed due to load or if there are network problems, a non-ntime-rolling miner will become idle occasionally (you may have seen warning messages about this from time to time).  In contrast, with the same load or network problems, an ntime-rolling miner will just happily increment the timestamp and keep looking for additional shares.  

So if you mine at a pool that routinely is overloaded or has network problems, you'll find more shares per hour (on average) with an ntime rolling miner which will translate into you getting paid more.

Looking good so far.  Looking forward to sections 3-5 as those are the the most interesting parts to me.

I changed it so that visited links are no longer in a different color.  Instead, you can "star" any addresses that you want to track and they will be highlighted if they appear in the payout queue for all future visits.  Note, the addresses you care about are stored only in a cookie and so this setting is per-browser.  If you use multiple browsers/computers, you'll need to star your favorited addresses once on each of your browsers/computers.

Visited links are now a distinctive color of red.  That said, I usually just Ctrl-F and search for the first 4 letters of my address (which is usually enough to find a unique match).

Can you clarify what they are doing that is incompatible?  Is it just that they don't actually verify a share against the given target?  I "fixed" that by modifying my proxy to check a submitted share against the target and silently drop them when they are not valid so that p2pool never sees them.

I only care because DiabloMiner now uses a kernel that is not compatible with my GPU on OS X (basically, any phatk-like kernel fails and only a poclbm-like kernel works).

Done: http://eligius.st/~twmz/