 Are the miners simultaneously verifying the solution of the previous block's cryptographic function while competing to find the puzzle solution for the next new block? Yes, they are. It takes about 15 to 20 seconds, at least, to validate a block. Depending on how complicated the block is, how complicated the scripts in the block are, some blocks may take less than a second, some blocks may take a lot longer, because they may contain a lot of complex scripts in them, a lot of signature operations, etc. While miners are validating the block, they generally start mining immediately, validation-less mining, as it's called. They mine the next block, they start mining the next block without validation. However, in order to do that, they must start by mining a new block that is empty. The reason for that is because they're going to be expending all of this energy, trying to find proof of work. They can't include any transactions in the new block, because they haven't yet validated the previous block, and therefore they don't know which transactions may have already been included, and which ones have still to be included. If they mine a block with a transaction in it, and there's a possibility that transaction was already included in the previous block, and if that block is valid, then all the energy they put into mining the new block is wasted, because that block is a double-spent, and therefore invalid. The safest way to ensure that the block they're mining, while they're still validating the previous block, is to make it an empty block, which is why you see empty blocks being mined. Now, because this is a probabilistic game, it doesn't make any difference if you change the block you're mining halfway through, or 30 seconds into it. Usually what would happen for a miner strategy is, while they're validating the previous block, they mine an empty block. As soon as the previous block has been validated, and the mempool has been cleared out and reconciled with what transactions are still available, then they can create a new candidate block that contains transactions, so they can get the extra profit from the fees, and then start mining against that, and continue putting energy in. It doesn't make any difference, because each attempt to find a hash is probabilistically distinct. It has exactly the same probability as the previous event, whether you change the underlying block or not, whether you started the proof-of-work nonce from the beginning or not. It doesn't make any difference. You have just as much chance at finding valid proof-of-work in the very next hash as you did in the previous one. The probability doesn't change. Therefore, miners will start mining an empty block, and then 30 seconds in, once they validate the previous block, now they can add some transactions, they're going to just switch to mining a block with transactions in it, and continue their proof-of-work. How do you stop miners from creating empty blocks when they create a regular one? Well, you don't, and in fact, you don't want to. There's no reason to stop miners from creating empty blocks. If a miner creates an empty block, that doesn't reduce the capacity of the network. That's really, really important to understand. If a miner creates an empty block, that doesn't reduce for anybody else the probability of somebody else finding a block immediately afterwards. And so it increases the security of the network for every block mined, regardless of whether it's empty or not. If you have a block that is found now, that doesn't change the probability of finding a block in the next second. These are probabilistically independent events. And so miners creating empty blocks simply forces everyone to restart their calculation, but doesn't change the probability that they will find a block within the next second. In general, you should think of empty blocks as adding to the cumulative proof-of-work and difficulty of a chain, and therefore increasing its security and increasing its immutability. There's also good reasons why miners create empty blocks. When a miner first receives a winning block from the network, they have to validate it. They have to validate every transaction within that block, and they have to remove those transactions from the mempool and create a new candidate block. That takes time. It takes a few seconds, maybe just a few hundred milliseconds. But in mining a few hundred milliseconds is time, and why would you stop mining? You don't stop mining. What miners do is start mining for an empty candidate block while they're doing the validation. If they find one during that time, they'll publish it, and then continue to do the validation for a block that has transactions. They can't put transactions inside a block until they have validated all of the previous block's transactions, to ensure they're not double-spending. Otherwise, they're wasting their mining power. That's why empty blocks get created. That's one of the reasons why empty blocks get created. Empty blocks are not a bad thing. They're part of the protocol. What happens if two miners solve the next block at the same time? asks Carell. BTC clients trust the longest chain. So if two blocks are mined at the same time, it's probably up to the miners to decide which is going to be accepted, but how do they decide it? This is the fundamental aspect of mining. We're going to talk about it in the future sessions, when we talk more specifically about mining and force. But for the time being, let me just prove this. Approximately once every week, two blocks of mines, nearly at the same time, miners and nodes decide which one to accept based on which one they see and validate first. This may cause the network to have two different perspectives of which is the correct next longest chain. That is a fork. It happens once a week on average, and it is resolved as long as the next block that comes in doesn't also come in simultaneously, which is a very low probability. Eventually, that fork is resolved because one of the two chains gets extended first, and then the other one has its tip, orphaned. The block is no longer considered. All of the transactions are replayed. So in the competition, it is normal for two blocks to be mined near at the same time. The winner is the one who remains on a chain that gets extended in the next round. If a Satoshi is the smallest unit of Bitcoin, is a Satoshi the smallest unit of Bitcoin that can be mined and tracked? Yes, Sudhakar. A Satoshi is the smallest unit of Bitcoin that can be mined and tracked. Let me be more precise, though. A Satoshi is the only unit of Bitcoin that can be mined and tracked. On the Bitcoin network, there is only one unit, and that's Satoshis. Everything is denominated in Satoshis. When you're wallet shows you Bitcoin, all it's doing is it's taking the number of Satoshis and dividing by 100 million. Everything on Bitcoin is in Satoshis. There is no other unit, just Satoshis. Where is the history of each Bitcoin fraction stored, and how can it be traced on a blockchain? The blockchain itself is a history of every Bitcoin fraction. Every transaction takes a Bitcoin fraction as its input, or more than one Bitcoin fraction as its input, and produces one or more Bitcoin fractions as its output. Therefore, the blockchain is a history of the fractions of Bitcoin moving from one owner to the next. When calculating your total amount of coin, your balance, must your wallet go through the entire blockchain from the Genesis block? What are the calculations on the blockchain the wallet must make, and what verification does it perform? Are there any shortcuts to doing this? If you are running a wallet that is a full-node wallet, in order for it to calculate your balance, and to do that authoritatively, you have to process the entire blockchain from the Genesis block. That doesn't mean you have to store it, but you have to at least validate everything and process everything once. Your wallet will have to go through the entire blockchain, which means downloading the entire blockchain, even if you're not storing the entire blockchain. The calculations that the wallet is doing is looking at each block, looking for any addresses it knows it controls, from the private keys it has, and looking for transactions involving those addresses. As it is, it is tracking unspent transaction outputs, or UTXO, which are basically coins, and adding them up. When they are spent, it removes them from the calculation, and when new ones are created with your addresses, it adds them to your balance calculation, until it reaches the end of the blockchain, and now it has an accurate picture of your balance. Are there any shortcuts to doing this? Yes. You can use what's known as simplified payment verification, or lightweight wallets. What they do is ask a full-node, validate the answer by looking for proof-of-work, and the position of the relevant transactions in the Merkle tree. Finally, the least preferred option, which is the ultimate shortcut, is to use a block explorer or website, and ask it what your balance is by typing in your address. This reduces your privacy, but also it means that you have no idea if that block explorer is telling you the truth. You're taking a third-party's word for what your balance is, and that breaks the security model of a decentralized cryptocurrency. An astute reader might say, but you have not yet solved the Byzantine Journal's problem, just moved it to the miners. What if two miners send out blocks with conflicting information? How do the clients choose? Again, as we said before, they choose based on their own appreciation of the consensus rules. If both blocks are fully valid by the consensus rules, by all of the clients, then timing matters. The first block to be seen in each part of the network gets chosen. If more than one block is seen and more than one part of the network finds itself with two competing realities, then the next block will resolve that, because the longest chain is something that evolves over time. When the next block is found, it will settle the dispute between the two competing versions of reality, by making one of those chains the one it built upon longer. The longest cumulative difficulty valid chain wins, but each one of those components is important. The longest cumulative difficulty valid chain is valid, whichever one your node thinks is valid. If a network is big enough, that is the valid chain, which is the longest. It is the one that has the most proof of work in it. These things all work together. The Byzantine Journal's problem is not solved in one place. The Byzantine Journal's problem is solved through the collaborative action of every participant in the system, who has a small role to play in all of these add-up. Freddy asks, is the longest chain the chain with the most blocks? No. Actually, it was briefly. The algorithm was changed very early on, during the very early experimental days of Bitcoin. But the correct definition of which chain wins in Bitcoin is the greatest cumulative difficulty valid chain. A longest does not mean most blocks. It means most difficulty. How do you do that? How do you calculate most difficulty? You add up the amount of proof of work that has existed. You add up for each block how much difficulty is expressed by the proof of work, how many bits of difficulty are involved in the proof of work for that particular block. The cumulative difficulty is the measure. The next word that is really important, the longest cumulative difficulty valid chain, means that the chain is valid because every block in it is valid, and the blocks are valid because every transaction in them is valid. It doesn't matter if you have the greatest cumulative difficulty if one of your transactions is invalid, or if one of your blocks is invalid. It is only in the context of the chain being valid under the consensus rules that you win. So, long as chain is really just a short way of saying, greatest cumulative difficulty valid chain.