Pools have different settings for the total size of transactions they will take in a block overall, and how much space is reserved for free transactions. And of course the amount of paid transactions varies over time, both in number and size.

There is no known way (yet) to change the data to make it easier to hash.

Luck goes up and down. It's been fairly average lately.

Variance has gone up. That's because the pool is a smaller part of the global hashpower now.

No, you can't improve your average luck by including certain transactions. Take a look at the sha-256 algorithm on wikipedia. See if you can find ways to predict how certain inputs will affect the output. Noone has been able to do it so far.

Bitminter client supports all BFL products so far except the upcoming Monarch. Hopefully I can add support for that too.

Difficulty adjustment happens every 2016 blocks. At difficulty adjustment it looks at how fast the blocks were found, not at the hashpower which is unknown to everyone including the bitcoin system itself.

Reward halving happens every 210 000 blocks. It's a separate process from difficulty adjustments. We've had the first reward halving from 50 BTC to 25 BTC per block already.

The goal with difficulty adjustments is that somewhere a block should be mined every 10 minutes on average, not exactly every 10 minutes. If you are lucky you find two blocks in a row in 1 second. And as long as hashpower keeps rising it will be more often than every 10 minutes - that's why the difficulty goes up.

The reward graph at Bitminter shows a single proof of work being worth less and less as the difficulty goes up. That's because the chance to create a block with one proof of work is 1 divided by the current difficulty. As difficulty goes up the work becomes less valuable because it is less likely to actually create a block. Put another way, the average amount of work needed to create a block goes up, so the value of work goes down. At the next reward halving the value of a proof of work will also be halved (if we ignore income from transaction fees).

I have no idea what the world will look like in 20 years.

At the moment I think only namecoin is worth anything (of the coins that support merged mining with bitcoin).

It was the slowest loading page on the website. Someone noticed this and started hammering it from an amazon cloud server.

I've been thinking of adding something else instead. Maybe show the 10 shifts that were used to calculate payments, with the same info that is on the shifts page today for each shift. Maybe add in some sort of summary of the shifts at the end, and show somewhere how much you got paid for that block.

That's just an idea so far. What kind of information would you like to see on the block page (which you get when clicking a block on the blocks list)?

Someone adding hashpower to the pool drops your payout per block, but gives you blocks more frequently. It doesn't affect your average payout, but lowers the variance. So you are not losing money when someone adds hashpower to the pool.

When the difficulty goes up, your average income goes down though. That happens after hashpower is added globally, to any pool.

Bitminter client v1.5.0 is out.

New:

• Add support for Antminer U1/U2, with overclocking and click-to-flash-LED
• Rewritten Red/Blue Fury support - should work much better now
• Bugfix: Chili ASIC would fail on first try and you'd need to start the device twice
• Bugfix: Fixed a memory leak that could happen when mining on BFL ASICs - would lead to sluggishness and eventually the client locking up completely
• Bugfix: Fixed a bug where scanning for devices could stop working until you restarted the client
• Bugfix: workaround for Java 6/7 bug that could cause security- or nullpointer-exception after the program had been running for a while was no longer working with the latest Java 7 releases
• Display approximate earnings per month rather than per day (per day was showing zero for slow miners, plus newbies were expecting to get that exact amount per day)

Try it now:


If you have a problem with 1.5.0 you can still load 1.4.3 from here: https://bitminter.com/client/1.4.3/bitminter.jnlp

Note: if you restart the client and still see 1.4.3 it's because Cloudflare's (our content delivery network) web interface is down and I can't flush their cache. Try again in a little while and you should see 1.5.0.

Thank you

Thanks for the support


Probably will.

Bitminter client v1.5.0 beta3 is ready for testing.

New:

• Bugfix: antminer would sometimes still be detected as icarus
• Bugfix: chili asic would run out of work after recovering from chili firmware problem
• Improved overclocking for antminer, enable entering 4-digit hex code directly
• Default to not setting a clock speed on new antminer devices (keep their current clock)
• Improved workaround for Java 6/7 bug that could cause security- or nullpointer-exception after the program had been running for a while

Please check it out:

New beta that fixes this is coming right up.

Basically that is correct, although the score is first calculated as score = proofs of work divided by difficulty, then the percentage is your share of the total score.

Your score goes down if pool hashrate goes up, and it goes up if your own hashrate goes up, that is correct.

http://bitcoin.stackexchange.com/questions/10731/mining-pool-hashrate-effect-on-a-miners-income

The live hashrates are measured over a shorter time than most pools, so it does jump up and down a bit. It's an estimate and not accurate. The shorter time we measure that over, the less accurate it will be. Also, if you set a minimum difficulty and set it very high then there will be more variance which will cause the hashrate to be less accurate. I'll think about changing the measured time frame for the live hashrates. I could show the shifts average hashrates as a graph in addition to as a table, but I guess it wouldn't really help much.

Click green arrow on Antminer to expand its display in the client, then click the wrench that appears.

Best option may be to try it for a couple weeks and see how you like it.

You get paid when blocks are found. We are a smaller part of the global hashpower now and find blocks less frequently than when you were mining previously. On average your payout is not affected by that, but there is higher variance. The difficulty is much higher than when you mined before though and that does affect everyone. Some additional info on how payouts work: https://bitcointalk.org/index.php?topic=27062.msg2769824#msg2769824

It doesn't actually send any commands to the devices if they are already running. But it does print "Executing scheduled action: Start automated devices" every time in the log which is annoying.

I have attempted to fix the problem with having to start Chili devices twice in the beta. Could you try that and see if it has worked? The beta is available under the "tools" menu on the website.


I did try once on the old (256 MB memory) Rasberry Pi and I think it took about 1 minute just to start Bitminter client. But after it was running it seemed to work ok. CPU mining wasn't very fast though. I haven't tested ASIC mining - not sure if it works or not. It might start faster on the later Raspberry Pi version with more memory (512 MB).

There's probably also a "too many errors, giving up", in the logs. Meaning it began consistently producing wrong nonces or timing out, without any valid results. Perhaps it got too hot?

And there are no errors about the Antminer producing wrong nonces or being disconnected?