 Arpit asks, what is the expected pattern which the hash is reviewed against to determine a valid block? Are the attempts to find the nonce manually or automatically implemented? Let's start with the second part. The attempts to find the nonce are absolutely automatically implemented. Keep in mind these involve billions of hashes attempted per second, which means billions of different nonces attempted per second. It is usually done entirely in hardware, not even in software. It is done on an application-specific integrated circuit, or ASIC, which is a silicon-based device that a chip specializes in doing just that. You put a block header into the device and it plugs nonces and does hashes as fast as possible, billions of times per second. In fact, some of the newest equipment I believe is terror hashes per second. Its performance is measured in terror hashes, and terror hashes means trillions of hashes per second. What is the expected pattern which the hash is reviewed against to determine a valid block? The pattern itself is the difficulty target. The difficulty target is a number, and the hash must be less than that number. Rather than thinking of it as a pattern, think of it as a number. If you take a hash, 256 bits, it will look like a pattern with a lot of zeros in the beginning. That just means that it is a number that is smaller than another number. If you have a lot of zeros in the beginning, that means it is a smaller number. The smallest possible number you could do in a hash is all zeros followed by one bit. That would be the greatest difficulty. Obviously, if all of the bits are one, that is the easiest one to find, because everything is smaller than that. The difficulty is somewhere in between that range. It is a number that has all zero bits in the beginning and one bit, that is one. That means that your hash has to be smaller than that number. When the difficulty target gets lower, finding a number that is smaller is more difficult. When the difficulty target gets higher, finding a number that is smaller is easier. Think of it like a limbo bar. As the limbo bar gets lower, it gets harder and harder to squeeze underneath it. Again, that is the general idea here with the difficulty target. WinterMutco is asking, what do I mean by validating a transaction? How does that process work? Again, validating a transaction is not something that is done manually. All of these things are done automatically by software. When I am running a copy of Bitcoin Core on my laptop, it is receiving transactions several times a second, in fact, from other nodes that it is connected to. Every time it receives a transaction, my node will validate that transaction. What that means is it will go through and check 20 or 25 rules to make sure that the transaction passes all of these checks. What are some of these checks? Okay, let's think of some. One of the ones we have been discussing today, which is obvious, is make sure that the coins that are being spent, the inputs of the transaction, have not been spent before. In order to do that check, my node has to have a copy of the blockchain so far and knows about which coins have been spent and which coins have been unspent. In fact, it keeps a database of all of the coins that have been unspent, and that database is called the unspent transaction output database, or UTXO set. By keeping that database, my node can immediately check if these are in fact unspent coins, and if they are, proceed to the next validation. Well, every transaction has an amount that it sends to each of the outputs. What do we know about that amount? Well, it can be less than zero, obviously. And we also know it can be more than 21 million Bitcoin or 21 quadrillion Satoshis. That's kind of obvious, right? So, the transaction validation is going to make sure that the amounts, all of the amounts, and all of the transactions are between zero and 21 quadrillion Satoshis, which is the maximum amount that can exist. Next, it's going to check that the numbers add up. So, the total amount in the inputs must be greater than or equal to the total amount in the outputs. Then it's going to check that the inputs that are being referenced exist, that the inputs are properly validated, and it's going to check the script in those inputs to see that, for example, a signature is correctly applied. Then it's going to check the scripts that are being presented in the outputs, and see if those are in fact valid. It's going to check the structure of the rest of the transaction. The transaction has a data structure, which includes things like n-lock time and n-sequence, and those have to be correct. The header has to be correct. So, once all of those checks are done, as I said, about 20 or 25 checks, that's a valid transaction. Similarly, every time a block is received, nodes go through a process of validating that block by checking against the long list of rules. These are the consensus rules. This is how consensus happens. Consensus is the agreement on what valid is, and it's all of the software rules that are checked against every block and every transaction. So, to be in consensus simply means to be using the same rules to check a block in a transaction. Joseph asks, what exactly is the difference between miners and nodes? Well, nodes are any computer that participates in the protocol, and it may store a full copy of the blockchain or not, but a node is a computer that is participating in the peer-to-peer network. Most nodes usually validate all transactions and blocks, which means they're checking everything against the consensus rules. Miners do run nodes, but they run nodes with a special purpose. Those nodes are connected to mining equipment, not only validating transactions and blocks. They're also aggregating transactions in the mempool in order to produce the next block, so they're managing the queue of upcoming transactions. I run a node, and my node also has a mempool, and it knows what transactions have not yet been confirmed and await confirmation. The difference is that a miner's node, every ten minutes, will take a whole bucket load of those transactions and stuff them in a candidate block. It will prepare a candidate block by putting as many transactions as it can into that block, trying to maximize the amount of fees it collects. Then it will try to mine that block by finding a special non-stable producer, a special pattern, to match the difficulty requirements of the network. The difference between a mining node and a node is simply that the mining node is doing a bit more than the network node. It's also mining for new blocks. All nodes validate all transactions and all blocks. What are the uploads and downloads requirements for an internet connection to be able to be okay with a Bitcoin node? If you think about it, you're looking at each block at the moment on Bitcoin. Let's say about one and a half meg, including the segregated witness information, one and a half meg of transactions. You're going to receive every one of those transactions first, then you're going to receive a copy of the block and validate them. You're going to send every one of those transactions out to at least one, but more likely two or three other nodes that are adjacent to you. That means you're looking at downloading one and a half to three megabytes every ten minutes and uploading three to ten megabytes every ten minutes. Add that up over a day, add that up over a month. That's approximately what it's going to cost you in terms of data capacity to run a node. Now, you can actually put restrictions on your node to limit some of that data flow, but again, that's up to you. Fabiano asks, does the block need to be finished for the validation of all of its transactions? Not quite sure what this question is, but I think I understand what you're going with. No, it doesn't, meaning that when a miner receives a block from someone else, they don't immediately validate it. They start building a new candid block with no transactions in it and start mining immediately. Then they validate it while their mining equipment is already working, because the chances that it got to them, propagated to them over the peer-to-peer network without being valid, are pretty slim. Every node in the path had to validate that block. They're going to validate the basics of proof-of-work difficulty on the header, but they're not going to validate every transaction in that block, unless they've already validated it in the mem pool. So, as a shortcut, this is called light mining or SPV mining, if you like, and it's basically mining without validation. It has some downsides, but also it's likely that miners do it anyway, certainly for the five or six seconds it takes, to fully validate the block and all of its transactions. For that time, they start mining immediately without validating on the previous block. Fabiano also asks, why should I run a full node if I am not a miner? Fabiano, the answer is really simple. You should run a full node if you want to be able to answer the question, did I get paid? There are two ways to answer that question. One way, the naive way, is does blockchain info think I got paid? Does somebody else's node think I got paid? That's not the Bitcoin way, because then you're trusting somebody else to do the decentralized protocol for you. The correct answer, the correct way of finding the answer of did I get paid, have I received payment for this transaction, that I was expecting payment for, is to have your own node evaluate the consensus rules. So, I run a node because I want to be able to answer the question. Somebody just said they sent me Bitcoin, for example, to pay me for going to a conference. How do I know if I've been paid? How do I know if I actually received this, if it has six confirmations, if it's a valid transaction? Do I ask and trust somebody else? No. I run my own node, I do my own node, its own calculations, and it answers that question for me authoritatively. So, authoritative validation, an independent validation of transactions, is why you run your own node. Perhaps as an individual, that's not very important to you. It is for me, I think, I believe in the principle of it, very much, and I think that's why it's important to me. But certainly, if you're running a merchant service, if you're running an exchange, if you're running anything else, you can't possibly trust somebody else's infrastructure to tell you if you have been paid, perhaps hundreds of thousands or millions of dollars worth of Bitcoin or not. Because you have to make decisions in your software as to whether you're going to allow a withdrawal, whether you're going to allow a trade, whether you're going to ship merchandise, and these decisions will cost you money if you are wrong. And perhaps the person you are trusting is the one that wants to steal money from you, so they will pretend that you have been paid when, in fact, you haven't. That's exactly why you would run your own node. Very good. Here's one question from the forums. On what basis does my node connect to other nodes? Can I be cheated and connected to dishonest nodes? That's a great question. Your node connects to other nodes by a process that starts out by discovering some of the well-known nodes, which are called seeds, and then branching out and finding other nodes by exploration. It does so randomly by making its own decisions about who it connects to. It doesn't trust other nodes as long as it can validate the transactions and blocks it receives from them. Every node has to constantly prove its loyalty by sending good transactions and blocks. The moment a node that we're connected to stops sending us valid transactions and blocks and starts sending us incorrect transactions and blocks, our nodes will disconnect from them and ban them as being dishonest. Once they've discovered a few nodes that they trust, if you shut down your nodes and restart it, it's going to then connect to those trusted nodes again randomly, try them out, see if they're still online. When it connects to them, it's also going to ask them, do you know any honest nodes? They're going to reply with a list of other nodes that they know. This is the ADDR message on the Bitcoin peer-to-peer network protocol, ADDR, which stands for address. A node will ask, ADDR, do you have any addresses for me? The other node will respond and say, I know these honest nodes that I've been talking to for a while, but have proven to be honest. Your node will learn from the ones it knows. It will learn about more honest nodes, connect to them randomly, test them, and then ask them for honest nodes, etc. Each node does this so that it can constantly maintain a healthy network of honest nodes. It tests all of these nodes and nodes that are dishonest very quickly get disconnected from the network. Could someone create enough virtual lieutenants to bring down the general, replace him with a new one of their choice? Conduct a blockchain coup d'etat, as it were. This is a really critical question. This question you're asking refers to something we call a Sibyl attack in security systems. A Sibyl attack is where you create a lot of fake nodes that pretend to be real. For example, let's say you want to persuade people that your opinion is very popular when it isn't, so you create a lot of accounts on Facebook, and they're all controlled by you, and they all pretend to have the same opinion. People looking at that may think that there are a lot of people who hold this opinion, when in fact all of these accounts are connected and controlled by a single individual. That's called a Sibyl attack. These types of attacks are called sock puppets sometimes. The key there is that you can have one person or one actor create a whole number of fake or virtual accounts. Bitcoin directly solves the Sibyl attack problem, and it's the only system that solves this, as part of solving the Byzantine General problem, by solving the Sibyl attack problem by requiring each node, whether it's controlled by one entity or not, to produce proof of work. You can create a lot of fake systems, but if you only have a certain amount of mining power and you create a lot of fake systems, all you're doing is taking all of your mining power and splitting it among many systems. That doesn't do anything for you, because it just ends up diluting the mining power that each system can bring to bear. In any case, identities don't matter. The only thing that matters in the Bitcoin network is the cumulative amount of hashing that you bring to bear to the network. The number of votes you get do not increase when you have more nodes running. They only increase in terms of the mining system, at least, when you have more hashing power, whether you do that through one node or several, doesn't really matter. Can you create enough virtual new tenants, only if you buy enough hardware and spend enough electricity, in order to power those new tenants to bring down the general? That's exactly the power of the Bitcoin consensus algorithm. How does the network verify the winning-minor solution was correct? How many times is the solution verified, and by how many? The network verifies the winning-minor solution at every point. Let's say I'm a miner, and I've just found a solution that I believe to be valid. I'm going to announce it to all of the nodes I'm directly connected to, in order to propagate it across the network. When I tell those nodes I have a new block, they validate it before accepting that block. They don't tell any other nodes until they validate it. That means that nodes do not propagate across the network until they are validated by every intermediate node. They don't get to reach everyone unless everyone validates them. The entire network verifies the solution. They verify the solution as soon as they see it, and before telling anyone else about it, to ensure that they're not propagating invalid blocks. In fact, if a node propagates an invalid block to its neighbors, it will get banned by its neighbors. The neighbors will disconnect from nodes that they consider to be lying, to be propagating invalid information. They will isolate that node by cutting off connections to it. You stop talking to people who lie to you when you're on this network. Everybody validates everything. Without validation, it doesn't propagate. Only nodes that propagate are valid nodes, only valid nodes propagate. Other miners only see the blocks that other miners have found if everybody thought they are valid. Rittik asks, On my response to counting the connection with a node that is lying, do all following nodes find it at the same time? Can they be a mixed understanding of an invalid node? How is the consensus taken? Again, it's entirely a matter of perspective. I only care about my perspective, meaning that if I'm running a node, the perspective of my node is the only one that matters. If I find a node that is lying to me, I will disconnect myself from that node. I don't care what anybody else does. As far as I'm concerned, that node isn't following the consensus rules that I chose. From my perspective, they're invalid. Are they invalid to everyone? No. Maybe I'm the one who's running consensus rules that are invalid to everybody else. Maybe I've been cut off from everybody else, in which case I might find myself in the minority, outside of the broader consensus. Consensus is an individual perspective. I don't tell anybody else who to believe, and I don't believe anybody else. My node will decide on its own which nodes it will talk to, which answers it will believe, which rules it will validate. My goal, or role, as a node operator, as someone who runs a node, or chooses a wallet, or signs up with an exchange, is to pick the one that follows the consensus rules that I believe are the right consensus rules for this network.