Hot answers tagged

10

This really helped me understand it: A solo miner increments Nonce until it overflows. Then it increments extraNonce and resets Nonce. extraNonce is located in the coinbase transaction, so changing it alters the Merkle root. extraNonce is reset based on the time.


9

extraNonce gets put into the input of the generation transaction. getwork clients can't see transactions, so they can't update extraNonce. Some miners instead modify nTime slightly to give them more nonce space. extraNonce is used by bitcoind, but it's not part of the protocol. There is no extraNonce field in blocks or transactions.


9

Stratum: the server gives the client templates that the client can use to generate its own work. Only the block header and first transaction (generation transaction) are included. Stratum uses the least bandwidth of all the protocols. Stratum also makes it very fast and efficient to switch to new work data when there is a block change, which can help keep ...


7

The -gen flag actually started a CPU miner process in older versions of the Bitcoin client, before CPU mining became obsolete. What you're probably thinking was more like bitcoind -server or `bitcoind -server -RPCALLOWIP=192.168.1.* -RPCPORT=8333 which would start a listening Bitcoin server from which a proper miner could obtain getworks. Since namecoind is ...


6

hash1 is a uint256 zero, padded to a multiple of 64 bytes by FormatHashBlocks() in main.cpp, and then reversed in 4 byte chunks. FormatHashBlocks() puts a 0x80 right after the 32 zero bytes, and a 4 byte bit count at the end (00 00 01 00, meaning 256 bits). the uint256 zero is: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 it's ...


6

When there were no pools, all of the first mining clients interfaced directly with Bitcoin. They connected to Bitcoin's JSON-RPC interface and used the getwork RPC method to get the required work. Getting work from a pool is the same as getting work from Bitcoin. The client connects to the pool over HTTP, often using the same HTTP authentication that Bitcoin'...


6

getwork is for all intents, completely deprecated due to it's inefficiency. At this point a single ASIC device can completely swamp a bitcoind with requests as they're able to exhaust the 32bit nonce in a fraction of a second. The situation is severe enough that pools like BTC Guild have extraordinary large (6%+) fees on clients using getwork in order to get ...


5

My understanding of the mining mechanism is this: The miner connects to a Bitcoin client (or pool) and submits a getwork request The client (or pool) responds with a chunk of data containing the block data, including the randomized bits, and the nonce (the bit which the miner changes) The miner increments the nonce multiple times until it either finds a ...


5

The miner you are using does not support the stratum protocol. Instead you must use a pool that uses the old and now obsolete getwork protocol If I see it correctly BTCGuild still offers the getwork access with the following URL: minerd.exe -o http://btcguild.com:8332 -u username_1 -p password -a sha256d -R 2


4

The number of transactions in the header is always zero, per the specification. The -gen option has no effect on the getwork RPC call. I'm not sure what you think is wrong with that information, but if it's just the zero transaction count, that's always that way. If it's the fact that you only get the headers you need to hash, it's always that way. Of ...


4

Yes, the miner can increment the time stamp by a limited amount, but only if the pool advertises X-Roll-NTime as a feature. DiabloMiner and CGMiner both support this. See the official spec for more information.


3

This question is a complicated one, but I'll see what I can do to answer it. Also, I won't try tackling the issue of endianness, as in the case of Bitcoin it gives me a headache... First, lets see what we have in a block header given to us by getwork. Lets take the Genesis Block for an example. 01000000 - version ...


3

The standard getwork protocol forces the miner to send a new request every second. This means that if a miner takes longer than 1 second to check all nonces in a given getwork (2^32), it will be making a new request before it checks all values in a given request, thus giving you 1 getwork request per second regardless of the hashrate. If the miner can solve ...


3

If you mean a miner as in a computer that only does mining, it should be generally as resistant to DOS attacks as any casual computer on the network - it doesn't open its ports. If you are worried about a standard client being flooded with many blocks and having to store it - the developers did think of that and they put in the checkpoint system. Basically, ...


3

The JSON-RPC protocol is very simple. You POST to the mining pool (or the bitcoind client): {"method": "getwork", "params": [], "id": "anything"} and get back: {"result": {"data": "hex bytes....", "target": "hex bytes...", ...}, ... } You just need the first 80 bytes from result.data - you change the last 4 bytes (nonce) and compute the hashes. Then, ...


3

The GetWork request includes only the block header, containing exactly the fields shown here and no others. This is all the miner ever sees. Notice that the transactions are not in the block header -- just their (Merkle) hash. The miner doesn't actually know what transactions it is mining. The pool checks that the block header of the submitted work ...


3

You can run as few or as many Bitcoin clients as you want. You can have them all pull from the same client, or you can have each miner pull from its own client. Just remember, the mined coins will go to the wallet of the client the miner pulled the work unit from.


3

By default a bitcoin node does not hand out duplicate getworks. Neither do any of the mining pools. So you don't need to do anything special, just point your miners at some source of work units, either a pool or your own instance of bitcoin, and off you go.


3

On testnet I get the following dump: Miner -> bitcoind POST / HTTP/1.1 Authorization: Basic Y2RlY2tlcjphYmMxMjM= Host: localhost:18332 Accept: */* Accept-Encoding: deflate, gzip Content-type: application/json X-Mining-Extensions: longpoll midstate rollntime submitold X-Mining-Hashrate: 583000000 Content-Length: 45 User-Agent: cgminer 2.8.1 {"method": "...


3

Most miners now use Stratum, but the old getwork protocol isn't completely gone yet. The URL is the root path (/) of the server usually at port 8332, for instance http://mint.bitminter.com:8332. You can see what the data looks like here: How can I code a Bitcoin JSON-RPC "getwork" request in Java? No, this is JSON-RPC. It's an RPC-style interface, ...


3

The getwork RPC call was removed from Bitcoin Core. It was deprecated and then superceded by the getblocktemplate RPC call. It looks like the pool that you are using uses an unspecified protocol. It's just a tcp connection where you are sending JSON formatted strings and receiving JSON formatted strings from the pool server. I figured this out by digging ...


2

Jeff Garzik wrote a binary protocol for pushpool originally. BitPenny uses a proprietary protocol to get p2pool-like benefits.


2

There is no advantage to "pooling" solo miners. Simply install the client and a miner on each machine. Point the miner at the local client and start mining. While you can have all the machines pointed to a single client (just give the miner the machine-name or LAN IP address of machine w/ bitcoind/wallet) doing so introduces a single point of failure. If ...


2

Most pools define their target value (minimum value required to earn a "share"), as: T = 2 ** (256 - 32) - 1 = 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff The Bitcoin protocol defines a difficulty of 1 as a target of: D = 0xffff * 2**208 = 0x00000000ffff0000000000000000000000000000000000000000000000000000 They are nearly equal: T/...


2

bitcoind will act on the block you submit immediately. But there is no "right after that". Anything can happen between two requests to bitcoind. The responses you get from bitcoind represent a snapshot in time. In between two requests there could be a block reorganization causing not only your new block to be orphaned, but several blocks back in the chain ...


2

Bitcoin won't wait for its peers: your block will be considered the latest block in the chain once it has been processed. I'm not sure whether it's safe to say that the second RPC call will always reflect the existence of the new block, though, since Bitcoin is threaded and things might not be done in the exact order you expect.


2

1) Yes, it is correct. 2) It is deprecated. Generally, it is used to write the result of the mining over to be sent to the pool. This is to ensure the result is of correct length and adheres to some rules. In practice, it is always the same trailing string of numbers.


2

Pools don't measure mining rate by how many times a client calls GetWork. They measure mining rate by how many shares are submitted. A share is just like a normal block solution, except that it is million times easier to find. If you don't mine, you don't find shares. Related.


2

The advantage of getblocktemplate is that work units from it last longer, because you can change the extraNonce field. That's nice if you're writing an fpga miner, because it saves bandwidth. getwork will probably never go away. It's useful and not very hard to maintain. Note that that's a personal opinion; I'm not one of the Bitcoin developers. Edit: ...


2

An answer can be found on bitcoin talk https://bitcointalk.org/index.php?topic=177855.msg1852355#msg1852355 Quote from deepceleron on bitcoin talk This is your GPU returning invalid hashes from it's kernel. This is because new drivers are crap for older cards. Uninstall AMD APP SDK Uninstall AMD Catalyst Install manager: choose "uninstall ...


Only top voted, non community-wiki answers of a minimum length are eligible