Hmm ok. As an aside, best share does show rejected shares or even shares not submitted if they're below the target. The reason for this is that there is no way of knowing what your best share is when you're solo mining.

Another issue that's bugging me is the effect vardiff has on share payment. It is totally reasonable that if the base diff is 10x higher then the value of diff 10 shares is different to diff 10 shares for diff 1 miners, but when the diff is above 10, the value of each share should actually converge (at some point, not sure where) from both diff 1 and diff 10 miners.

EDIT: (Yes I understand it's perfectly fair over an infinite time period and averages out to the same pps at whatever diff, but it would just be nice at diff 1 to be paid for finding a block as much as a diff 10 miner is paid for finding it. Nice, not logical, fair or reasonable. Just nice.)

New version: 2.10.2, 19th December 2012

Various bugfixes and minor feature improvements.


Human readable changelog:

Should have fixed the various ways stratum pools would go dead and not recover to be in use.
When unable to connect to a pool at startup, previously if it eventually connected the menus wouldn't work - fixed.
On stratum disconnect, cgminer now throws away all work from that pool and stops any of that work in progress since it is all invalid and can only lead to rejects.
The best share count could get corrupted on fast machines artificially showing a higher share than was ever found.
Scrypt stratum support.
Kano updated the MMQ code to be much better at handling overheats.
Update API features.
Updated miner.php


Full changelog:

- Stop all work from the current pool if it's a stratum pool once it is
disconnected since it will be invalid upon reconnecting.
- Discard all staged work from stratum pools as well as the shares upon
disconnection since all the work becomes invalid.
- Use correct cbreak after 15 second delay when no pool is found alive.
- MMQ missing firmware -> ERR not DEBUG
- Allow stratum to work with scrypt.
- MMQ ensure delta clock can never exceed limits
- MMQ lowercase new string constants
- MMQ add api pgaset for clock
- API V1.23 - new pgaset command, to be used soon
- Protect the best_share/best_diff values under control lock.
- MMQ style police
- MMQ count work check timeout failures
- MMQ allow partial work replies and count them
- Check a stratum pool hasn't gone dead while being a backup pool and missed
having its idle flag cleared.
- MMQ overheat: remove clockdown (doesn't help) + ensure no lost shares
- API-README grammar
- API-README explain custom page extensions in miner.php
- miner.php add a sample group pool report
- miner.php allow where,group,having on cumstom pages

That driver and that SDK are incompatible. It broke that SDK after the 12.3 driver.

No he's not. There was never any intention of making this much greater risk for the pool, only more fun for the miners. Higher variance but capping it would achieve that goal.

To be fair, what I had originally suggested with this scheme was to cap the maximum paid to that of the current block difficulty to prevent the ridiculously high difficulty share from bankrupting the pool.

As an aside, I'm disappointed they didn't adopt the name I chose for this payment scheme: Difficulty Extrapolated Reward Payment, aka DERP. Though I guess one could argue we're now hashing pot.

A lot of this idea came out of the fact that people feel cheated if they're the block finder and get no more than any other share for submitting it, and that now that cgminer scrolls difficulty, people constantly ask "so are the higher shares worth more?". It also acts as a disincentive to people acting maliciously performing what's known as a withholding attack by not submitting the block solve. It also adds an incentive to people mining on the fringe of profitability that they might actually make a profit if their hardware is the one that is lucky at that time. Ultimately, it's just gambling and over the very long term leads to the same rewards as PPS, but you never know your luck...

Here's an example:
[2012-12-18 22:52:10] Accepted 0000aa69 Diff 98.5K/1 GPU 1 pool 0
That share was worth 0.01435750 BTC where the current PPS rate is 0.00000712, meaning that one share was worth more than 2000 shares. On the other hand, diff 1 shares are worth 1/5th of what the going PPS rate is.

Note that in cgminer, up to and including version 2.10.2, the "best share" value may be wrong whereas the per-share statistic is accurate. This should be fixed from 2.10.3 onwards.

Hopefully these issues are now fixed in git.

And that helps too, thanks.

It's a problem with the balancing with plain non-rolltime getwork based pools in the current version. This can be alleviated with the failover-only option for the time being which can be enabled on the command line or via the menu under pools. You should hardly ever get share leakage or run out of work with the latest work scheduler anyway so I'm considering making failover only the default.

Roger those comments, that gives me something to work with. Yes there is no way to reconnect stratum (yet?) and submit shares you were working on last time you were connected unfortunately.

Firstly, the example data is contrived and demonstrates nicely the confusion between technology and application. The test data does not demonstrate the bandwidth data difference intrinsic between stratum getwork and gbt, but the application of said technologies within luke-Jr's software within the constraints of his particular test. The intrinsic bandwidth requirements of each protocol can easily be calculated, and then I implore users who care about bandwidth to test it for themselves - with cgminer. Either using traditional tools or using the cgminer API  to get the results as Kano suggested.

Second what Kano is talking about when he says "transaction times", I believe he is referring to how often a block template for GBT, or a set of merkle branches for stratum, based on current queued transactions is being received by the mining software. If said template is sent once every 30 seconds on average by stratum, and received every 120 seconds on average by GBT, there are potentially 90 seconds more worth of transactions that never make it into the next block solve, in the way it's implemented in luke's software. In cgminer I receive the template every 30 seconds with GBT to match that of stratum. Only when the protocols are "equal" in terms of their likelihood of perpetuating transactions (since this is what bitcoin is about) should the bandwidth be compared. Pretending the bandwidth doesn't matter when one implementation can use over 100MB per hour is just naive.

Third, there has still not been any valid explanation for how sending the miner all the transactions in their entirety actually improves the security of the network. Unless someone is running mining software and a local bitcoin node and is comparing the values from each, and then decides what transactions overlap, and what are valid transactions the pool has chosen to filter out, and then determined that the data is enough of the transaction list to be a true set of transactions, having the transactions does not serve any purpose. Pool security validity software should be developed that does this, and people should use said approach if they care to confirm the pool is behaving. luke's software does not remotely do this to verify the transactions. It simply grabs them and then if it doesn't get them claims the pool is doing something untoward if it doesn't match the template. The transactions could be anything. It also completely ignores the fact that the vast majority of miners run their mining software on machines that aren't actually running bitcoin nodes with which to check the transactions. While the main bitcoin devs might wish this to be the case, it's not remotely the reality and is not going to become it.

We have a very suspicious community that will continually check the pools' actions. Yes history has shown pools may do something untoward - though it's usually about scamming miners with get rich quick schemes and not about harming the bitcoin network. If security was to be forced upon the miners by bitcoin itself, then a valid non-pooled mining solution should exist within the client itself that does not require people to have at least 1% of the network to be feasible. Solo mining is pointless for any sole entity any more. Unless bitcoin devs decide that something resembling p2pool makes its way into bitcoind, allowing miners of any size to mine, then pooled mining is here to stay. If or until that is the case, pooled mining is a proven solution that the miners have embraced. P2pool is great in principle but the reality is it is far from a simple plug in the values and mine scenario that miners use pools for. Pretending mining should be dissociated from bitcoin development just makes it even more the job of the pools to find solutions to mining problems as they arise. GBT failed to provide a solution early enough and efficient enough in the aspects that miners care about and stratum came around that was much more miner focussed. You can pretend that GBT is somehow superior but there isn't a single aspect that makes it attractive to miners or pool ops, and people are voting with their feet as predicted.

See? Respect the man who admits when he's wrong. Might have to save this link for future use...

Woohoo 

Stratum on the hostile fork of cgminer uses approximately 100x (?1000x) the bandwidth of stratum on cgminer.

well it was the main reason for the updated version. Glad to see I finally resolved that annoying bug, and it was as expected deep within libcurl dll for windows managing raw sockets. I fixed one bug but there seem to be numerous others...

I need to investigate the dead pool issue. I haven't seen it happen myself.
As for leaking shares, stratum and gbt pools actually don't leak shares at all with or without failover-only mode. You only get leakage if the primary pool is getwork and you're not in failover only mode.

In that case, temporarily reduce the fee to stratum instead?

Make sure you at least have sdk2.6 as well, meaning the one that comes with driver 11.12 or later, and you need MORE SYSTEM RAM to mine ltc.