There are features already implemented which will make the recent heist a nightmare of the past. The problem is they can't be deployed before the majority of hashing power agrees.

I am not vouching for a particular one - just trying to convince you that you should start mining at a pool supporting any of the solutions.

Unfortunately Deepbit is currently supporting NONE of them.


http://blockchain.info/p2sh

[Latest miner]

Latest miner

poclbm_py2exe_20120920

mirror


Sources for poclbm are at http://github.com/m0mchil/poclbm


GUI

Created by Kiv, see http://bitcointalk.org/index.php?topic=3878.0


Guides

Windows - http://www.newslobster.com/random/how-to-get-started-using-your-gpu-to-mine-for-bitcoins-on-windows

Ubuntu - http://bitcointalk.org/index.php?topic=2636

Mac - http://forum.bitcoin.org/index.php?topic=12360


Known best settings
(please PM better/best settings for your platform)

AMD 5xxx and up
use '-v -w 128'


Frequently asked questions

Q: Does my video card / driver supports OpenCL?

AMD - 4xxx and up. Nvidia - 8xxx and up. On Windows you can use 'GPU Caps Viewer' or similar.


Q: I am seeing 'pyopencl.LogicError: clGetPlatformIDs failed', what is this?
Q: It says 'ImportError: DLL load failed: The specified module could not be found'?
Q: Or 'ImportError: DLL load failed: The specified procedure could not be found'?

You don't have proper OpenCL support. The reasons may vary. Be sure to remove any old drivers and SDK from different vendors you may have used. Use web search to see how to make it work for your combination of GPU and OS.


Q: When I try to run it with the following parameters: '--host=http://mining.bitcoin.cz:8332' miner errors out with  'nonnumeric port'

Remove 'http://', it's intended for browsers (becames '--host=mining.bitcoin.cz'). Use '--port' to specify port (default is 8332 so you don't need to specify it if the pool you use is at same port).


Q: Why it uses 100% CPU?

You probably selected the CPU as OpenCL device. Or you are using it on Linux with AMD Stream SDK 2.2. Use 2.1 instead.


Q: What does 'invalid or stale' means?

The block last submitted was either invalid or stale.


Q: How a block becomes stale?

You submited solution for a block which was just solved by someone else.


Q: Why a block is invalid?

Don't overclock too much. And switch crossfire off. Or may be I screwed the search again? It's good if you see more 'accepted's than 'invalid's.


When I try to run the miner a new CMD window flashes on my screen too rapidly to read anything, or even see if it says anything.

It's console application. You use that ugly black thing called 'Command Prompt' to run it.

This is a patch against SVN 159 that allows external RPC clients to ask for unsolved block data and eventually submit back a solution.

It opens the way for external bitcoin miners. If non-local RPC is used it also enables multiple-miners-to-client arrangement.

EDIT:

theymos is expressing some concerns regarding extraNonce here

There are actually many components of a block that change its hash. Let's assume the block contains only the initial (award) transaction. The hash will change if either:

     - transactions merkle hash - if you change txOUT publicKey, txIN difficulty or extraNonce
     - block time - 4 bytes that are updated every n seconds in the original client
     - block's nonce

Bitcoin is giving by default each mining thread it's unique extraNonce (to ensure different hash space). However if there are new transactions after at least 60 seconds merkle hash will change. This patch rebuilds merkle hash at each request for work because of the new extraNonce it assigns. If there are new transactions it should rebuild merkle hash anyway so I don't think this is much of a problem. Also, the external miner may change it's block time if needed - it will get back and processed/verified accordingly.

I made some tests with difficulty of 1 and generation rate was equal to the expected values.

[new, fresh data folder]

I know it's not the smartest move to name my user account using non-latin characters. Anyway, 0.2 has no problems with this.

Verified as follows... created a 'normal' new user and 0.3 opened the data folder. Created new, fresh data folder and copied it to the non-standard user - 0.3 fails with DB_RUN_RECOVERY.

Am I the only one seeing minuscule generation lately? It was decent until around 20:00 GMT February 21st, but after that my machine (4 core I7) produced only one block for entire >12 hours. And there isn't even a clue for new difficulty hike in the debug log.

Here are my possible scenarios:

1. Some big BC bot came along.

2. Someone is trying some kind of DoSing the system.

3. Someone built a bitcoin mod with GPGPU (CUDA or sorts) support.

4. Some kind of growth problem (i.g. we reached first of a kind network size and there is problem with that).

Ideas?

I am just seeking your opinion on some thoughts I had recently. NLS states that he/she calculates how much energy is spent for daily BC production. If more and more BC users are involved in generation, the number of BC NLS produces will go down, for the same amount of energy spent. Hence, the price is bound to go up.

I mean, NLS methodology is wrong