An actual quantitative correlation? I ask only because I'd like to know how you calculated it.

Maybe my language was a little too strong. From my personal observation over the last 14 months of mining, I've seen correlation in that the price of bitcoin effects what happens with the difficulty. There is also significant lag between price movement and the difficulty following.

I suspect that if the price falls any further, mining will become unprofitable for some and difficulty will decrease. This may be offset a bit with miners starting to realize that we are in the final month of 50 btc blocks.

An actual quantitative correlation? I ask only because I'd like to know how you calculated it.

Maybe my language was a little too strong. From my personal observation over the last 14 months of mining, I've seen correlation in that the price of bitcoin effects what happens with the difficulty. There is also significant lag between price movement and the difficulty following.

I suspect that if the price falls any further, mining will become unprofitable for some and difficulty will decrease. This may be offset a bit with miners starting to realize that we are in the final month of 50 btc blocks.

I don't disagree with you and what you write makes sense, but there must be some kind of simple correlation analysis that can be done. If you (or anyone else) can save me a bit of google-time to tell me what it is I'd be grateful.

An actual quantitative correlation? I ask only because I'd like to know how you calculated it.

Maybe my language was a little too strong. From my personal observation over the last 14 months of mining, I've seen correlation in that the price of bitcoin effects what happens with the difficulty. There is also significant lag between price movement and the difficulty following.

I suspect that if the price falls any further, mining will become unprofitable for some and difficulty will decrease. This may be offset a bit with miners starting to realize that we are in the final month of 50 btc blocks.

I don't disagree with you and what you write makes sense, but there must be some kind of simple correlation analysis that can be done. If you (or anyone else) can save me a bit of google-time to tell me what it is I'd be grateful.

You can already see the positive-linear relationship in the graph. For some reason Google spreadsheet does not allow you to add a trendline so I threw it into excel and got a linear equation of:

y = 5E-06x - 2.1471And an r-squared coefficient ofR² = 0.8541

Which means there is a pretty substantial, positive correlation between the difficulty and the market value of a bitcoin.

Thanks for the good work, abeaulieu. It does look like a good correlation, there. It inspired me to look a little further back and I got the following plots, the first linear and the second log-log. They are quite interesting, yes? I won't go further off-topic here discussing covariance and correlation coefficients, perhaps we should start a thread in the mining speculation board? (it's late for me and I don't have time to write an introductory piece).

Suffice it to say that the correlation seems to be less strong if you include the pre-bubble data, so I'd be cautious relying on such a correlation for future planning. My guess is that there might be a more stable correlation between log(diff(BTCUSD)) and log(diff(Difficulty)), with a time lag.

Testing is up on port 9000 again. This time testing dynamic difficulty (aka var diff or variable difficulty).

Please help testing: mint.bitminter.com port 9000

Difficulty is from 1 to 128 (powers of 2). The default is diff 2 unless your miner sends X-Mining-Hashrate in which case the default is based off of that. After this the diff updates every minute based on your hashrate.

The target is set to 15 proofs of work per minute. That's one result sent in every 4 seconds. The server will adjust the difficulty of your work to get you as close to the target rate as possible. You will need a couple GH/s to get over diff 1. No luck for me with 1.3 GH/s

When mining at diff X you get credited X accepted work for each valid result sent in. So mining at diff 4 means your "accepted" numbers will go up by 4 for each valid result.

Like last time the livestats won't show your hashrate on the test port. But you can look at the "workers" page on the website, mine for a bit, then refresh and see that the accepted work goes up. Note that those stats are a few seconds delayed. The livestats will work better once proper multi-server support is finished on the server side.

You can't use BitMinter client for this yet, sorry, multi-server support is still on its TODO list.

Difficulty is from 1 to 128 (powers of 2). The default is diff 2 unless your miner sends X-Mining-Hashrate in which case the default is based off of that. After this the diff updates every minute based on your hashrate.

Can you please explain how you decide what diff to server with X-Mining-Hashrate?

The target is set to 15 proofs of work per minute. That's one result sent in every 4 seconds. The server will adjust the difficulty of your work to get you as close to the target rate as possible. You will need a couple GH/s to get over diff 1. No luck for me with 1.3 GH/s

Difficulty is from 1 to 128 (powers of 2). The default is diff 2 unless your miner sends X-Mining-Hashrate in which case the default is based off of that. After this the diff updates every minute based on your hashrate.

Can you please explain how you decide what diff to server with X-Mining-Hashrate?

Normally your measured hashrate is used. X-Mining-Hashrate, if available, is only used in the beginning when the server has not yet measured your hashrate.

The target is set to 15 proofs of work per minute. That's one result sent in every 4 seconds. The server will adjust the difficulty of your work to get you as close to the target rate as possible. You will need a couple GH/s to get over diff 1. No luck for me with 1.3 GH/s

Is there any way to keep using X-Mining-Hashrate after the initial go? This would allow larger miners to have 1 worker but not suffer from higher share variance for the entire farm.

The problem with X-Mining-Hashrate is that you can make your computer(s) send whatever value you wish.

There's a conflict of interest here. Lower difficulty means less daily variance for the miner, which most miners prefer. But lower difficulty also means higher load on the server. If all miners could choose their own difficulty then most would choose diff 1 and the pool would need many more servers, which would be rather expensive. We are doing fine on 1 server right now with difficulty 1 for everyone. But that will no longer work once ASICs are out.

I think the HHTT pool is on to something. At that pool the lower difficulty you choose the more you must pay to the pool. That said, they do look a bit expensive and it makes no sense for small miners (choose between huge fees or huge variance).

I am considering adding a perk that gives you half the difficulty you would otherwise have. It could be a very cheap one. I also thought about a perk that would allow you to choose the difficulty freely, but then a single big miner could perhaps take down a server by choosing diff 1.

I guess it comes down to; how much load can the server handle and how much variance is acceptable for the miners? Any opinions on the variance part?

And yes, you can reduce difficulty by using multiple worker accounts. And if I make change it to be per user account rather than worker account, then you can just create many user accounts. I would prefer to avoid this. So I would want the "normal usage" to give a variance that is good enough. I would also prefer for small miners to be able to mine without choosing between huge fees or huge variance.

I am considering adding a perk that gives you half the difficulty you would otherwise have. It could be a very cheap one. I also thought about a perk that would allow you to choose the difficulty freely, but then a single big miner could perhaps take down a server by choosing diff 1.

I like this idea. Just get Stratum enabled and the big miners won't be a problem.

Stratum and GBT will be better at getting work than getwork with rollntime. Rollntime was already a big improvement, Stratum and GBT will improve this a little further. But that is all.

The server already spends most of its time verifying proofs of work from miners. Unfortunately Stratum and GBT will have zero impact on this.

So we will need variable difficulty whether it is over getwork, getblocktemplate (GBT) or Stratum.

For big ASIC miners you need two things:

More efficient work generation: rollntime (OK), GBT or Stratum (better)

More effiicient proofs of work: higher difficulty

Next up after var diff now is GBT and Stratum. I'll probably add GBT first. I know a lot of you are using cgminer which only supports Stratum. But GBT is so much easier to add when you already have a well-tuned engine for getwork with JSON-RPC over HTTP. It makes sense to grab the low hanging fruit first.