Hot answers tagged

14

A 2X rate with a 50% chance of missing a winning nonce is no advantage at all. Incrementing the nonce is the easiest mechanism of choosing the next nonce to try, so you try the most nonces per second that way. That's all that matters. Perhaps you are under the mistaken impression that everyone is trying to mine the same block. That is not so. If you are a ...


13

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.


13

This will not work, because a block's content includes the previous block's hash which means that a valid block can only be mined after the previous block is known. The dummy transactions would not yield a reward to the miner, because the transaction fees are just going from the miner's left pocket to the miner's right pocket. The miner will only gain the ...


11

Nonce is a 32 bit arbitrary random number that is typically used once. In Bitcoin's mining process, the goal is to find a hash below a target number which is calculated based on the difficulty. Proof of work in Bitcoin's mining takes an input consists of Merkle Root, timestamp, previous block hash and few other things plus a nonce which is completely random ...


8

I think that Tim S. may have the answer with his comment about endian-ness. Your observations about the nonce having its lowest byte zero (being a multiple of 256), are with respect to the little-endian byte order of the block itself. From the perspective of a big-endian machine, these are statements about the high byte of the nonce. So consider a miner ...


8

This mining simulator is a good visual of what is being hashed. http://www.yogh.io/#mine:last People are correct you don't have to change the Nonce it's just the fastest way to get a different hash output. You could very well keep the nonce at 1 and change the timestamp, or the list of included transactions, which would change the merkelroot. What's ...


8

There’s no such thing as a block without a coinbase transaction. Even if the block reward plus fees is zero, it is still a mandatory transaction at the start of every block, it just pays nothing.


7

First of all, when 1 second has passed, the miner can just increment the timestamp in the header. This already gives us 4 Ghash/s rather than 4 GHash/block. When this is not enough, and the nonce range is exhausted before a second has passed, the miner builds a new proposed block with a hash to search through. Specifically, the very first transaction in the ...


6

Yes, it is possible to not find a valid block for all 2^32 possible nonces, and that is indeed the typical case. I believe only at the minimum difficulty level, sometimes still used as basis for finding shares in pooled mining, would you even average(!) one valid block out of all possible nonce values. There is a timestamp field you can update, and there is ...


6

There were many good answers to this question. After reading through them, I'm going to take a stab at the answer as well. The coinbase field of the coinbase transaction (as it is called) is really just a scriptSig which doesn't have to pass any validation about its contents (except that it is less than 100 bytes, and the newer BIP34 requirements). Satoshi ...


6

It's not unevenly distributed. The reason it appears that way in the graphs above is because the x-axis is plotted in logarithmic units. Here's what it looks like in linear units:


6

The miner can change the block header hash several different ways: Change the timestamp. This is the least intrusive, but works just fine. If you can do more than 4 Th/s, this starts to become a problem. Add transactions. Adding any new transaction changes the Merkle root, so this gives you entirely new nonce spaces. Change the coinbase transaction. This is ...


6

They were never "waiting" in the first place. A miner is incrementing nonces and computing hashes continuously. As soon as a new transaction a2 arrives, it is added to the Merkle tree, the block header is regenerated, and hashing continues with the new block header. It's misleading to call this a "restart", since that implies there was some progress that ...


6

The block hash has to be below a certain value and the block hash depends (among others) on the nonce and on the Merkle root. The Merkle root depends on the sequence of transactions. Note that it's a sequence, not a set, meaning the order is important. Different miners choose many different lists of transactions. For every list of transactions with the ...


6

It's important to note that the block hash is over the entire block header, which contains: Block Version Nonce Previous block hash Timestamp Merkle Root nBits Of these, only the nBits and previous block hash are fixed - all of the others can be manipulated to alter the hashed data at will. Once all 32 bits of the nonce value have been exhausted (which ...


5

As you noted, the logarithmic scale skews it right, because the number of nonces within log(10, nonce) > 9 is 3 times larger than log(10, nonce) < 9 The other factor that might skew the nonces on your chart is that a pattern in the nonces on the blockchain doesn't necessarily mean that it's caused by a problem in the mining algorithm. As a trivial ...


5

You assume that there exists (exactly?) one block for each work unit. This is not true, there are many variables (timestamp, nonce, transactions in a block, extranonce inside the block's coinbase transaction, ...), and all of them influence the block's hash. Each hash has a chance (as of October 2013) of less than 1 in a billion billion (1.15*10^18 to be ...


5

Changing the timestamp is one way, but the more scalable method is to change the "extraNonce" field of the generation transaction, which changes the block header's Merkle root.


5

When the nonce range is exhausted, miners change the extraNonce field of the generation transaction. This changes the Merkle root in the header and allows a new range of nonces to be attempted. Since the Merkle root is 256 bits, this can be repeated indefinitely.


5

From the protocol rules, there is no such thing as an extra nonce. There is only a 32-bit nonce in the block header (which can be iterated over very quickly), and up to 100 arbitrary bytes in the coinbase input. The block generation code inside the reference client has traditionally put an 'extra nonce' in those arbitrary bytes, but the contents can be ...


5

The hashing function used in Bitcoin is deterministic, that is hashing the same input, i.e., block header, will always result in the same output. This is necessary so that others can also check that a Proof-of-Work is valid. This means that in order to compute a new hash the input to the hash function needs to be altered. The easiest way to alter the input ...


5

There's a difference between what is called a "golden nonce" in the context of the source and a valid block header hash. To reduce payout variance, miners group into pools and share their income proportionally to their hashpower. To determine each miner's hashpower, pools use a share system: when you are mining and find a block header of high difficulty (...


5

either I broke some rule, or the other person did; In this case, how does my client find a trusted peer Your client does not trust any peer. It fully validates the blockchain. In the event of multiple conflicting blocks at a given block height, your node will choose to go with the first block it hears of. However it will still retain and validate all of the ...


5

The tie is broken by the first of the two that gets extended with a child block. In practice, in case two conflicting blocks at the same height appear on the network, every node will pick the one they saw first as winner. Because communication across the earth happens at a finite speed, some miners may see one side of the fork first, and other miners may see ...


4

It doesn't matter where you start. The block you're hashing is unique because it's the only one that includes the mining bounty (new coins and transaction fees) being payed to your address. A timestamp is also included, so every second, you could start the nonce over at 0 and increment.


4

This is essentially like asking: "When buying a lottery ticket is it better to have a zero or a random number in my lottery number?" The reality is that it actually doesn't matter because it's an entirely random process, just like winning the lottery.


4

In Bitcoin v0.1.5 to v0.3.24, the coinbase scriptSig contained: txNew.vin[0].scriptSig << nBits << ++bnExtraNonce; In Bitcoin v0.4.0 to v0.5.3, it changed to: pblock->vtx[0].vin[0].scriptSig = CScript() << pblock->nTime << CBigNum(nExtraNonce); Bitcoin v0.6.0 to v0.6.3: pblock->vtx[0].vin[0].scriptSig = (CScript() <&...


4

My guess: It seems clear that Satoshi didn't expect pooled mining. In a world without pooled mining, you'd simply have each piece of mining hardware capable of up to 4 gigahashes per second (GH/s) use its own public key, guaranteeing that it produced a unique coinbase transaction output. The time field can be updated every second, so the nonce can be reset ...


4

It could have been done that way, at the cost of increasing the amount of space it takes to store and send block headers. It seems like block header storage was a big concern for Satoshi, (there's even a section in the whitepaper about it) but it's turned out to not matter very much. Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes? Yes,...


4

This effectively already happens on several levels, though without direct miner interaction. Both Bitcoin Core and the Bitcoin Relay Network have their own implementation of forward preparation for the validation of blocks with the intent of speeding up block propagation as much as possible. One focused on validation latency, one on bandwidth and latency. ...


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