 Let me explain what the nonce is in mining. We have talked about cryptographic hash functions. What cryptographic hash functions do is produce a specific fingerprint from data, such that if you make a tiny change to the data just a single bit, no matter how big the data is or how small the data is, it will produce a radical change in the fingerprint, allowing you to determine that the data has changed. When you produce a hash, the hash is a completely different number, even if all you changed was one bit in the input. What hash functions are doing is taking all of the bits of your data, pouring them into a bucket, and then stirring them algorithmically. Effectively, a cryptographic hash algorithm just stirs up the bits. If you look at how the algorithm works, what it is doing inside is a lot of addition. It is adding up binary numbers, and it is doing those additions with a modulo, so that if you add up to more than 32 bits, it wraps around and starts again, which mixes those bits effectively. As well as binary shift operations, where the cryptographic hash algorithm will take a chunk of bits, and will shift them left or right, and then add them to other bits. Essentially, what it is doing is shuffling, so it is a bit like shuffling cards. You take the data that you put into the cryptographic hash algorithm, and you cut it into chunks, and then you mix those chunks together, and you keep mixing them until eventually you get a 256-bit number, which is the output of your cryptographic hash, which is the fingerprint. Any point in that mixing process, if one of the bits of the data is different, causes the mixing process to go down a completely different path, which produces a completely different fingerprint. Just changing one bit changes the cryptographic hash function. If you think about it, the cryptographic hash function is output. The number it produces, the fingerprint it produces, is effectively a random number. It is a random number in that you cannot predict what it is going to be, but it is also a deterministic number, meaning that if you put the same data in, every time to the same algorithm, you will get the exact same fingerprint, which means it is very easy for anyone to verify. If you take the data, put it through the fingerprint algorithm, you get the same fingerprint as everybody else who puts the data into the hash algorithm. This is a very interesting trick. You put a data in, if you change it even by a tiny bit, it seemingly produces a completely different random number, but if you present the same data to someone else, and they put it through the fingerprint function, it is going to produce the same fingerprint. What if, when you are trying to pick these random fingerprints that are coming out there, you set a target and you say, I want my fingerprint to start with zero. What are the chances that your fingerprint starts with zero? Well, if you are looking at it in binary, and the first digit can either be zero or one, then if you just keep throwing fingerprints out there, half of them are going to start with zero, half of them are going to start with one. You have about a 50-50 chance. What about both of the first binary digits being zero? In that case, you have a 25% chance, because only one in four of the results will have both of the first binary digits being zero. You keep throwing fingerprints and you keep hashing. One out of every four hashing results will start with two binary zero digits at the beginning. Then you can keep going with that. Every time you add the requirement for one more zero, you get half as many of the hashes fit that target. Now you have gotten to 30 zeros. Now only one in a quintillion hashes will actually have all 30 of the first binary digits be zero. In order to find that one, what you have to do is take your data, which is your block, modify it slightly, calculate the hash, see if it has 30 leading zeros. It won't. Try again, try again, try again a quintillion times, until by complete chance the one tiny little tweak you made to the input data produces a hash that starts with 30 zeros. What is the nonce? The nonce is the part of the block that you are changing. If you think about the block, the block header contains a timestamp, a block number, the Merkle route of transactions, which is like a fingerprint of all of the transactions. It contains the hash of the previous block. All of this information is fixed. For a valid block, all of this information can only be one thing. You can't really change it. You can change the timestamp a tiny bit by a few seconds here and there, but the rest of this data can't be changed. The previous block is always going to be the same number. The fingerprint of all of the transactions is always going to be the same in that candidate block that you've built. Well, there's a special part of block that's 32 bits that doesn't do anything in the block. It's just sitting there, and you can put any number you want in there. Why does that space exist? It exists to allow you to change something in the block header so that you can produce a different hash. We call that the nonce. Let's say you take this 32-bit number and you start it with all zeros, and you hash the block header and you get some kind of hash. Does it have the necessary number of zeros in the beginning to meet your target? No. Try again. Instead of zero, let's make that 32-bit number one, then two, then three, then four, five, six, seven, eight, nine, ten. As you keep incrementing that 32-bit number, every time you hash it, it produces a completely different fingerprint. You do that five quadrillion times, and eventually you produce a hash that starts with 30 zeros just by chance. When you do, what you can then tell everyone is, here's a block, and look what I found. If you put this nonce in, and this nonce is, oh, it just happens to be the number 6,475,322. If you put 6,475,322 into the block header, watch what happens. You hash that, and the hash by complete coincidence has 30 leading zeros. How do you know that it took me a lot of time to find that? You know that the only way I could do that was by plugging numbers into the nonce and hashing, and waiting to see if the result matched. That's what a nonce is. It's simply the space in the block that has no meaning, where you can just plug in a random number and keep trying in order to find a specific fingerprint, to produce a fingerprint. Once you tell everybody that random number, they can all plug it into that space in the block, where it does nothing, and when they produce the fingerprint for the block. It's this magical fingerprint that has this special pattern of zeros in the beginning, and they're like, oh, wow, it must have taken a lot of work to find that random number that you have to plug in the nonce. That is proof that you did the work, proof of work. That's how a nonce works. Now, there are some complications. 32-bits is not enough to do all of the hashing you need. Miners actually use some additional space in the coin base that doesn't do anything, for changing some bits there. They also use part of the timestamp, because they need to move a lot of bits in the input to produce that. The nonce isn't just in one place, but that's more of an implementation detail. A couple of follow-up questions on that, which I find interesting. Really good questions in the chat room today. Talking about nonces, Luke asks, Do the miners know the amount of zeros required for the next block? Yes, that's the target difficulty. The target difficulty is, how many zeros does the hash have to have? In simple terms, that means in binary, but you can just think of it as a number. If I say that a number starts with so many zeros, effectively what I'm saying is that that number is less than x. So, x is the target. In order for your hash to be within the difficulty target for the next block, it has to start with a certain number of zeros. It has to be a smaller number than the difficulty target. That difficulty target is known by every node on the network, because every node on the network calculates that difficulty target using the same formula. Every 2016 block, every node puts the same numbers into that formula and produces the same answer. The way they do it is they say, What was the difficulty target for the previous two-week period? How many blocks did we mine and how long did those blocks take? So, we're looking to mine 2016 blocks, and because we're looking to mine them in 10 minutes each, that would take, theoretically, 20,160 minutes to mine these 2016 blocks. Let's look, how long did it take? Oh, it actually took 10% longer than 20,160, which means that miners are not able to find blocks every 10 minutes. They're a bit slower, they're 10% slower, which means it's 10% too difficult, which means that the difficulty needs to be adjusted by exactly 10%. So, the difficulty is reduced by 10%. Because the number of blocks 2016 is fixed, the time it took to mine those 2016 blocks is the same. Everybody knows the answer to how long it took in minutes, because they counted the same way. Therefore, they can do this division and find exactly how much to adjust the target difficulty. Everybody has the same target difficulty for the previous round, and that way everybody knows. Okay, the next block is in a new difficulty period. I expect the difficulty target for the next block, based on my calculations, to be x. I will only accept blocks whose hash is less than x. Everybody comes up with the same answer for x, and therefore everybody is looking for miners to achieve the same amount of proof of work for the next block, based on that. That's the difficulty retargeting algorithm, which happens every two weeks, or more specifically every 2016 block, which allows everyone on the network to know exactly what the difficulty of the next block should be at any moment in time, and arrive at the same conclusion. It allows miners to know what they need to do to succeed. They have a target, and all they have to do is say, is the hash less than the target? Yes, it's a valid block. No, keep hashing. Try more nonces. See if you can figure it out. Another question is, I wonder if it's possible to guess the nonce on the first try. Yeah, it's absolutely possible. You might find it on the first try, you might find it on the fifth quintillion time. It doesn't matter. The probabilities are exactly the same. The probability of finding it in your first try is exactly the same as the probability of finding it in your second try, the third try, the fourth try. These are independent events, meaning that the probability of each event does not affect the previous or the next event. There's no link between them. Just like if I flip a coin, whether it comes up heads or tails, the chances of it coming up heads the next time I flip it is still 50%. Even if I flip it a hundred times and it comes up tails a hundred times, the hundred and first time the probability is 50% that it will come up heads, 50% that it will come up tails, the probability doesn't change. The same thing for picking a nonce. The chance that the very first nonce I plug in produces a hash below the difficulty level is exactly the same as the second nonce I try. I could try them randomly. I could try them in order. I could try them in decreasing order. I could start from any value of nonce randomly and then just add one and keep going. It doesn't matter. It makes no difference what you choose as the starting nonce and how you move from nonce to nonce. You could just choose them randomly. However, choosing them randomly involves doing some more computation, because you have to figure out random numbers. And there's no reason to do that. There's plenty of randomness in the cryptographic hash. So instead, you could just increment them by one. That's the fastest way to do it, because incrementing by one in binary is something computers can do very fast. So what you do is you just pick a starting point for your nonce, and you just increment by one. And you have exactly the same chances of finding a valid nonce as everybody else on the network. And here comes an interesting question, which this is difficult to understand, but it's a very important concept on how pools work with lower difficulty. Sergio asks, Why does a pool work with a lower difficulty level for its nodes to solve? If my node finds a nonce that gives a hash lower than the expected difficulty set by the pool, how does that relate to the difficulty set on the Bitcoin network for that block? This is a really, really great question. This takes a bit of more discussion to answer, so that you can really grasp what's happening. But it's a really neat trick. Let's say you have a room full of people, and they each hold two dice. And you have a team who are working together, and their goal is to throw dice below a certain number. And if they find below that certain number, they win. So the team wins. Let's call that the difficulty target. And that's the difficulty target for the blockchain, the whole game. That's the actual difficulty target. So you tell all your players, Listen everybody, we can throw between two and twelve. Our dice, either you get two ones, is the lowest number you can throw, or two sixes, twelve, is the highest number you can throw. We win if we roll less than five total between the two dice. So that means that 6 and 6 don't work, 6 and 5 doesn't work, 5 and 5 doesn't work, 5 and 4 doesn't work, 4 and 4 doesn't work, 4 and 3 doesn't work, 3 and 3 doesn't work, 3 and 2 works, 2 and 2 works, 1 and 2 works, 1 and 1 works. Any of those throws below three and two work, below five. That is the target for the whole game. Your team starts throwing dice. You want to reward the people who are throwing dice most often, because they are doing more of the work for the team. How do you count whether they are throwing dice often enough? You could just wait until one of them wins. But if you just wait until one of them wins and give them all the winnings, then it is not really a pool. That is the same as if they were competing by themselves. What you do is come up with a pool strategy that involves giving them a portion of the reward. No matter who in the team throws less than five, or five and below, the whole team wins. But then you want to split those winnings based on how much everybody contributed to all of this dice throwing... that made you a winner. How do you do that? You set a different difficulty target and you say, Every time you throw less than ten, I count one share of contribution to the work for you as a team member. The team members are throwing dice. Twelve doesn't count, eleven doesn't count, ten doesn't count, nine. That is below the team difficulty, but it is not below the game difficulty. I count one share because I am doing work, because I threw nine, and I keep throwing. Because the team difficulty is anything below ten, that will give us a pretty good metric as to who is doing the most work. The people who are doing the most work will tend to throw more nine and below dice. They are going to get more shares, so we will be able to allocate shares based on them throwing low numbers. That means they are throwing enough dice, because the probability is the same. But here is the thing, a winning dice throw that is below five is also below nine. As long as your people are throwing dice, the chances of them throwing below nine are the same as the chances for any single throw, as them throwing below five. They are not losing anything by announcing, we didn't win the game, but I did win the pool difficulty. They announced that the dice throw is still helping you get closer to winning the game, because they might have thrown less than five, but it gives you a way to track their performance, because they threw less than ten. By setting these two difficulty levels, you have the difficulty at which we win the game, and then you have the difficulty at which your contribution as a team member is recognized and you count a share of the work. But that is less difficult to throw, then everybody can start throwing their dice and trying to win the game as a pool, and then you can allocate the winnings correctly by counting their shares. That is how the pool difficulty works. I hope that was understood. If I have an ASIC miner and I get a reward, how is this technically linked to a wallet of mine? Can you explain the process I should follow? That is a great question, Scott. How does the network know who to pay when you win a block? It is really quite simple when you think about it. When you have an ASIC miner, you construct a candidate block that is the block you are going to try to find a proof of work for. That candidate block is made by your own computer, so your computer that is connected to the ASIC miner, that is collecting transactions and blocks off the network, is going to construct a candidate block by taking a whole bunch of transactions that are currently unconfirmed, stuffing them into a block so you can make some fees, and basically building the block. You are proposing a new block to the network. You don't show this to anyone until you have proof of work, because no one is interested in a block that doesn't have proof of work. You just send it to your ASIC miner. Within that block, there is a special transaction called the Coinbase transaction. That is the transaction that pays the mining reward. Who creates that transaction? Your computer creates it. When you are a miner, your computer creates the candidate block, and your computer creates the Coinbase transaction, which represents your $12.5 Bitcoin reward plus whatever fees from all of the transactions that are in there. Therefore, you decide who that transaction pays out to. Your computer puts your own wallet's destination address into that candidate block when you are mining. If you are mining as part of a pool, the pool operator does that. But if you are mining by yourself, for example, which you probably would only do if you had a lot of mining equipment, you would have your computer construct candidate blocks that already have a Coinbase transaction in them that pays you. So you write that transaction. Effectively, miners write a check to themselves to collect the reward. The key to understand here is that that check isn't valid unless the block in which it was written is valid. That only happens if they find proof of work. When a miner verifies and finds a proof-of-work solution for a block through mining, once they've created a valid block, then the blank check they wrote to themselves for $12.5 Bitcoin plus fees in the Coinbase is now a valid transaction. If that block is accepted by the rest of the network, then that transaction exists in everybody's blockchain. It shows clearly that this miner is being paid their reward. Of course, the reward needs to be the correct amount. It needs to be exactly the same as the fees and the block subsidy at this level. Everything in the block has to be valid, otherwise it's rejected. But if it is valid, then there you go. The miner has paid themselves by writing a check, putting it in a block, finding proof of work for that block, and then telling everybody else so that everybody else writes that block to the blockchain. At that point, 100 blocks later, the miner can now spend that transaction. There's a 100 block limit for Coinbase transactions. They can't be spent until 100 blocks have passed. Essentially, a miner's own Coinbase transaction has to have 100 confirmations before it's spent. This rule is to prevent miners from using chain reorganizations to double-spend their own rewards. David asks, when a miner creates a block, am I right in thinking that this block is then transmitted to all other nodes on the network and is available for any miner to validate? No, not exactly. It is transmitted, but only after the proof of work is found. A miner only transmits a block to other people once that miner has already validated and proven that block by finding a nonce that creates proof of work for that block within the difficulty target. Meaning that the miner has to do quadrillions and quadrillions of hashes in order to find a suitable nonce. Only once that block contains a correct nonce that produces a correct proof of work can the miner send it to the rest of the network. The reason is that when the miner sends that block, the very first node they send it to will validate that block. If it doesn't have proof of work, it will reject it and, in fact, disconnect from the miner that lied. Every node on the network validates every transaction in every block, which means that miners cannot propagate blocks until those blocks have been made valid. That means they have valid proof of work.