 Sify asks, why would one need to know in the future how many blocks there have been since the Genesis? There might be a number of different reasons. One of the obvious ones is that you're building a block explorer, and you want to be able to show to the user when they ask for a specific block height. Who knows why they want it, but you need to be able to display that. Another answer might be that certain events happen based on block height, meaning that every 210,000 blocks we have a halving of the block reward. That's one of the reasons you want to know the block height, because at precisely that moment in time, you change the reward by 50%. The block subsidy is halved after every 210,000 blocks. At block 630,000 in height, the difference between the reward of block 630,000 versus the block 630,000 in one, is six and a quarter bitcoin in block subsidy. That's something you might want to know, and that continues. That continues out to the year 2140, with continuous halving. That's one thing you might want to know. The other thing you might want to know is that every 2016 block, you have a difficulty adjustment or retargeting, and that is also stored in the 2016 block. You will see the difficulty change between block 2015 and 2016. Again, that depends on block height, so you need to know that information. If you're looking to make a chart of the difficulty across time, you will need to take every 2016 block to see how it changes. Chan asks, how can I see the balance of any bitcoin addresses that are not associated with my wallet and seeds in the bitcoin core? Great question. First of all, Chan, you need to understand that balance is not stored on the blockchain. Balance is calculated by adding up all of the different transactions, so that you can measure that balance. Meaning that if you want to see the balance of an address, what your software is doing is counting all of the deposits and withdrawals, all of the inputs and outputs in the transaction, in order to see how many UTXO are stored with a script that corresponds to that address, and add up all of the value of that UTXO to tell you how much balance you have. Balance is an artificial concept that is created by the user interface, which means that in order for bitcoin core to calculate the balance of an address, it has to scan the entire UTXO set and find all of the UTXO. That's if you're running bitcoin core with a full index. If you're not running it with a full index, it can't do that. Now, it doesn't do that for every address. The reason it doesn't do that for every address is because calculating the 26-27 million addresses that exist, or however many exist nowadays, I don't even know, it might be 100 million addresses, would take an enormous amount of computation, and the average user does not care about 99.999% of those. Therefore, because you're only interested in 1 in 10 million addresses, it doesn't do this. Instead, it will only calculate the suffix in your wallet. How do you make it do it for an address that's not in your wallet, which is your original question? You add what is known as a watch address. You basically say, Here's an address. I don't have the private key in my wallet, but I want you to watch the balance, and then bitcoin core will go and calculate the balance. In order to do that, it will basically re-scan the blockchain, and you need to send it a command to tell it to go back and re-scan. So, when you add a watch address, it will start watching from that moment into the future. If you wanted to also find transactions that existed before the moment you added it, you have to tell it to re-scan, so it will go back and look automatically. If the address has never been used before, you add it as a watch address, you don't need to do anything. If it has been used before and it already has a balance, then you need to tell bitcoin core to go re-scan. That takes a while. You tell it from what block number to go stand. For example, I recently needed to look at some addresses that I used back in 2017 for tax purposes. So, I needed to add those addresses as watch addresses on my node, and then I needed to tell it to re-scan from the 31st of December 2016, and bitcoin core will convert that automatically into a block number, that is from the previous day. Then it will start scanning from that block number up to today. It takes, on average, about 30 minutes to an hour to go back a year or two, and then it will produce a balance. For that moment, it will watch it. Why can't we securely download a precinct blockchain? Why do we need to run bitcoin core to check the whole blockchain before running a full node? Since the blockchain is data, why can't it be securely download checking its hash like any other software, and only after that have the nodes start validating transactions? This is a really great question. We can download the blockchain. I can make a full copy of the blockchain, and I can create a hash for it, and your node can download it, and even not validate it. In fact, there are checkpoints within the blockchain, so that you don't have to validate the whole thing. You can just skip validation if you want. You can configure your node to do that. What's the benefit of doing this? Let's look at the practicality of it. First of all, if I create a copy of the blockchain, and I publish a hash to that copy, someone has to validate it in order to validate that hash. Both the hash and the copy of the blockchain need to be stored somewhere, and then I make it available for people to download and skip validation up to a certain point. How would they download it? Maybe they would use FTP or HTTPS. That's not very efficient. Maybe a better one would be how about BitTorrents? We can make a copy of the blockchain available on BitTorrents, and then you can download it fast, skip the validation, and confirm the hash. What you've done there is put trust in whoever created the hash, and more importantly, in whatever validation you have, that hash is real. Effectively, you're trusting a checkpoint and not validating for yourself. The validation happens pretty fast, depending on how you do it and how much RAM you have. You can do it relatively fast. The download takes more time, and the best protocol we would have for that is BitTorrents. Hang on a second. What is the Bitcoin network? It's BitTorrents. The Bitcoin network itself is a peer-to-peer, distributed hash table, propagating flood network that allows you to connect to eight or ten peers and request blocks and then reconstruct them in a chain, independently downloading bits of it until you have a full picture. That's BitTorrents. We already have a dedicated BitTorrents network for downloading the Bitcoin blockchain. It's the Bitcoin network, and it already has all of the checkpoint and validation in it. The best part is you don't need to trust anyone, because all of the nodes are doing the checkpointing and validation of all of the blocks before they send them to you. You can configure your node to skip validation to a certain point. We already have this. The difference is, instead of using a protocol outside of Bitcoin, we're using Bitcoin. In fact, it's faster to use the Bitcoin peer-to-peer network than to use BitTorrents or FTP or HTTPS. The nodes are already out there. They already have lots and lots of copies. Best, it's not a static copy that you snapshot every now and then. It's a live copy that keeps growing, so you can always get the latest one. You don't need to worry about whether the blockchain you found on BitTorrents is three months old, and then you're going to have to download a whole bunch of new blocks, and how often someone is going to update the snapshot, and how often they're going to update the checkpoint. The reason we can securely download a precinct blockchain is because any mechanism for downloading a precinct blockchain is less efficient and slower than using the Bitcoin network to download a precinct blockchain.