# Difference between revisions of "Talk:Block"

m (Unsigned comment) |
|||

Line 7: | Line 7: | ||

== Each block contains all recent transactions, a nonce (random number), and the hash of the previous block. == | == Each block contains all recent transactions, a nonce (random number), and the hash of the previous block. == | ||

The nonce is a seed that starts at zero and is incremented until the block hashes below the target. | The nonce is a seed that starts at zero and is incremented until the block hashes below the target. | ||

− | Hence, it should not be called "random". | + | Hence, it should not be called "random". {{unsigned|Henrythefifth|10:28, 14 May 2011}} |

== What if I'm 1% towards calculating a block and...? == | == What if I'm 1% towards calculating a block and...? == |

## Revision as of 00:32, 15 August 2014

## Contents

## Proposed FAQ question and answer

#### Won't the reward be too small?

As the reward shrinks, it may become unprofitable for anyone to create a new block, but as indicated above, the difficulty of the math problem is adjusted every two weeks in order to maintain the rate at which blocks are created. Since it takes about four years to generate the 210,000 blocks and their corresponding bitcoin rewards, it is virtually impossible to ever get to 21 million. At any point in time, it will take about four years to get **halfway** from the number of bitcoin currently in existence to the 21 million count. It's an unreachable goal, barring a kind of catastrophically destructive cooperation between all bitcoin miners that is untenable.

Only, I don't know if my understanding is correct. Dscotese 19:04, 29 May 2012 (GMT)

## Each block contains all recent transactions, a nonce (random number), and the hash of the previous block.

The nonce is a seed that starts at zero and is incremented until the block hashes below the target. Hence, it should not be called "random". — Preceding unsigned comment added by Henrythefifth (talk • contribs) at 10:28, 14 May 2011

## What if I'm 1% towards calculating a block and...?

"There's no such thing as being 1% towards solving a block. You don't make progress towards solving it."

Is this true? I don't know if there's a nonce which will solve any given block, but for a block that is solvable, it's possible to be 1% of the way towards finding it. Supposing it takes 10 million attempts to 'solve' a block, then after 100,000 attempts you could say you were 1% towards solving it. You're certainly closer to solving it than you were before those 100,000 failed attempts, aren't you? Dooglus 05:05, 15 January 2011 (GMT)

- No one can know how many tries it will take to solve the block. After the fact you might say that at some point you had finished 1% of the necessary calculation for that block, but this was not really "progress".

- If you go back in time after completing a block and don't generate for one of the days that you did originally, then you could actually end up getting the block
*sooner*, as the work required is random. theymos 11:06, 15 January 2011 (GMT)

Probabilistically speaking, one can make a "best guess" for how long it will take to solve a block. A problem with probabilistic estimation, for example, is that it may say it will take 10 hours to solve the block, with a standard deviation of 15 hours. How much more work do you have when you've worked on it for 10 hours? The answer is that you have ~10 hours more work :).

But assuming all incorrect hashes are exhausted first, the maximal number of tries needed to solve the block is ~2^{256}. So, there exists an upper limit (albeit, it is an obscenely large one!) on the amount of work you can do. Progress is made, just very slowly. --Dlo 20:28, 11 April 2011 (GMT)

- That's not the maximum. You can't predict the hash outcome, so you could try forever and still get values above the target. You'd get repeat hash values from the same input. theymos 03:47, 18 April 2011 (GMT)
- I can predict the hash outcome by calculating SHA-256 with my mighty x86 processor. :) IMO "predicting" is irrelevant here. Dlo is assuming that the hash function is injective, therefore the number of incomes (giving outcome above the target) <= 2^256. But the hash function is not injective (by the cardinality argument: the set of incomes is infinite and the set of outcomes is finite). --Shrewdwatson 13:49, 23 April 2011 (GMT)