I think there's a problem with the diff10 server and NMC I just noticed I have been receiving less as well. I think I found the bug and it should be fixed now going forward, I am sorry about that.

With regards to transaction fees, I will look into that when it becomes a significant issue. Right, it averages about .1 BTC per block, perhaps a bit less, so it's one of the ways I can keep from having to charge a fee. Between that and donations, the pool gets around 0.4% of each block, but when it starts becoming significant and impacting miner income noticeably, I will probably switch over to paying some portion, if not all of the transaction fees, yes.

If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.

Inuba, do you mind posting on the first page ALL the different servers. I noticed pacific rim isn't on the list. It took me HOURS of trolling thru the forums to find it. my connections to the server has been heaps better since I've been using it.

The Bitcoin Museum is back under my control, but I still need to go through all the code. DO NOT PURCHASE ANYTHING FROM IT

PACRIM and EU both currently point to one of the US servers (I can't recall which off the top of my head). I plan on putting up a new PACRIM server in Japan or such, I just haven't gotten around to it as of yet with everything else going on. I want to get the variable difficulty in place and working flawlessly then I will put up the new PACRIM and EU servers, no sense in doing the work twice.

If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.

The current difficulty is 2440643 so I would expect any block with shares less than 2440643 to display a luck above 50%. Taking block 197059 above as an example, that block had only 2170260 shares (i.e. less than difficulty). It was thus a bit 'luckier' than average. So its luck value should be above 50%, yet the website shows it as 41.1%.

Also, taking a look at the 2nd example above (block 197045), it shows its luck as being only 50.99% ... yet it only had 1643689 shares ... its luck value should be significantly higher than 50%.

It almost appears as if the luck calculation is being based on a lower difficulty than the current 2440643, perhaps something around 1650000. Unless I'm misunderstanding something here (which is quite possible).

Luck is defined as "What percentage of blocks are longer than this one."

It used to be defined as "Percentage of shares from the target," but people convinced me to change it wayyy back in the double digit pages. I'm open to other suggestions, of course, but that's what everyone agreed at the time was the best measure of luck.

If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.

Luck is defined as "What percentage of blocks are longer than this one."

It used to be defined as "Percentage of shares from the target," but people convinced me to change it wayyy back in the double digit pages. I'm open to other suggestions, of course, but that's what everyone agreed at the time was the best measure of luck.

Yes, the above has been my understanding as well. Thinking this through again, I was going by the false assumption at exactly 1/2 of the blocks would be smaller than 'difficulty' (2440643), and 1/2 would be larger, which was my mistake. It makes sense now, thanks.

Ok, so I have a variable difficulty server up and running. Before I make it public, though, I want to ask everyone what they think:

Currently, on the my workers page, it lists the actual number of shares submitted. That's fine on a static difficulty, where, for example, a 10diff share is worth approximately 10 1diff shares... so it makes sense. But on the new server, and going forward, as you mine your difficulty is adjusted dynamically... so over the course of an hour you might send in 10 2diff shares, 7 5.4423diff shares, 25 6.44321343diff shares, etc... So it makes a direct comparison meaningless.

Since EMC is the first to implement this, we can effectively define the de facto standard on how to display this. That said, my first thought is to just take everything to the lowest common denominator and display everything as 1diff shares and effectively ignore the number of shares submitted at a given difficulty. That would be used strictly behind the scenes, but for all intents and purposes, all display GUI information would be quoted in 1diff.

Who's got comments? Let me hear them!

If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.

Right now, I have it set to target 8 getworks per minute returned. So if you submit more, you are bumped up in difficulty. I do like the average diff over time idea, I will have to figure out how to make that happen.

If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.

I like the sound of diffculty 1 equivilents of DOE. It is a good common ground for compairison. If you went variable by the lowest common denominator it is possible that people disconnecting would alter the equivelence. So I would say Difficulty 1 for now and some static equivilent later if needed.

As per cgminer and the cgminer API, yep Diff1 is of course the most sensible base to use so comparisons can be made.The WU: number on cgminer is Diff1 Work done per minute (it also includes all work, not just accepted shares)The API has 'Diff1 Work' - only pools currently show it, but the next version will show it for devices also(2.7.5 and before says 'Diff1 Shares' but I've changed that to 'Diff1 Work' for the next release since it includes all work)

Next thing I want to do is actually tally pool getworks under 3 headings: DiffA, DiffB, DiffOtherSo you can see what the first 2 difficulties used were and also pool getwork totals for those and all others.This will allow you to see what most of the work you are doing is for each pool.I've no idea if keeping it in 3 groups like that is best or not, but that's just the idea.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLUFreeNode IRC: irc.freenode.net channel #kano.isMajority developer of the ckpool codeHelp keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!

That sounds good to me, Kano. What do you think about difficulty being doled out... should it be variable as it is now, or variable as powers of 2? Do you think it matters?

Right now I have the difficulty being adjusted every 3 minutes based on the getworks received in that time frame, with a target of 8 per minute. I'm not sure this is optimal yet, but I'm open to suggestions.

Dave3: Those look in line with my testing. Your speed reads a little high, but it's hard to gauge with only 15 minutes of testing. How does it look after a couple hours? What is your time estimation window set at?

If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.

At wat speed would you think or recommend miners be mining at for trying out the variable difficulty server. Is a higher possible variance the only negative drawback in higher difficulty shares, from a miners perspective? (A slow 1gh/s miner perspective)

Seems like less than a week ago they were still stickied. Am I safe in assuming this is directly related to EMC's growing popularity and the soon to be added Variable Difficulty Shares(or similar shortened version) to EMC's subject title?

Seems like less than a week ago they were still stickied. Am I safe in assuming this is directly related to EMC's growing popularity and the soon to be added Variable Difficulty Shares(or similar shortened version) to EMC's subject title?