 Julio asks, could you please explain the hash function, how it works, and how to make the reverse process? A hash function cannot be reversed. In fact, that is the primary feature, if you like, of hash functions. And what a hash function is, is a mathematical manipulation, or an arithmetic manipulation. Basically, you take a series of data, or a stream of data, that's coming into the hash function, and you mix the bits with a particular recipe, and that's the hash algorithm. So, the SHA-256 algorithm uses a specific recipe to mix the bits, using various arithmetic manipulations at a binary level, such as, for example, shifting bits left or right, as well as exclusive or other mixing operations at a binary level. Now, all of this mixing together will take an arbitrary stream of data, of arbitrary length, and produce a fixed fingerprint for that stream of data that is 256 bits long. You cannot arrive back at the original data by reversing the hash function. That is a fundamental feature of hash functions. You also cannot predict what the hash function will produce, or deliberately produce a specific output for the hash function by tweaking your data. Effectively, every time you put data into a hash function, it produces what appears to be almost a random number. But it's a deterministic random, which means if you put the same data into the hash algorithm, you'll get the same result. You just can't predict what that result will be. Think of it a bit like in a visual term. Think of a billiard table, right? Take a billiard ball and hit it really hard, and have it bounce off the edges of the billiard table many, many times. Let's say a hundred times, because you hit it really, really hard, and it arrives at a specific spot. Now, if you started with the same billiard ball at the same location, and you hit it at exactly the same angle, with exactly the same force, it would always stop finally after a hundred bounces in the same position. But if you took a photo of the final position of the billiard ball, and you said, well, where was it when it started? It's impossible to work that backwards. So, while forwards, you can take the same billiard ball, hit it with the same strength at the same angle, and it will always end up in the same position, finally, at the end of bouncing it all across the table, when you look at the final position, you can't work backwards where it came from. Because it could have arrived at that position from a number of different angles. And what that means is, there is an almost infinite number of starting positions and different angles you can hit at, but there's a much smaller number of ending positions where that ball could be. And as a result, that function is almost compressing the information, and hash functions work very much the same. It's useful to make relations between hash functions and encryption, in that it is a form that is similar to encryption. But unlike encryption, which is reversible, otherwise, of course, it would be useful, hash functions also have this compression capability, because the end result is always 156 bits, no matter how much data you put in on the front end of hash function. And as a result, the amount of information encoded in the hash function can be smaller than the amount of information you put in. You cannot reverse hash functions, and they produce a number that appears to be random, even though it is actually deterministic and therefore would produce the same number every time. George asks, SHA-256 risks and applying two hashing functions on public keys. The Bitcoin protocol seems to have a strong dependency on the SHA-256 hashing algorithm. Although there is no known vulnerability of SHA-256 right now, what will be the effect and the risks for the protocol in case such an issue comes up? That's a great question, George. Any cryptographic function, including, of course, the SHA-256 hashing algorithm, will eventually become vulnerable in some way. And the reason for that is because computers get faster, but also mathematics advances, and algorithms get scrutinized in more and more ways in order to find weaknesses. So every single cryptographic algorithm that was strong 30 years ago is no longer strong enough. And as a result, has gradually been deprecated and replaced by more modern, stronger cryptographic algorithms with larger and larger key sizes in order to deal with this arms race between the strength of cryptographic algorithms and the strength of the computing infrastructure and the mathematical tricks used by people trying to break these cryptographic algorithms, including hashing. So it's not really an issue of whether a problem will be found or SHA-256 becomes too weak, but rather when it's naive to assume that this algorithm will survive forever, no algorithm survives forever. Now, it may be decades, it may be several decades, in fact, before SHA-256 has a meaningful compromise, and there are different categories of compromises when it comes to hashing algorithms. So a collision attack, for example, is one of them. Another is to select a specific hash and find a match. And another one is to select a specific plain text and modify it in order to find a specific hash. So there are different degrees of vulnerability that you can have in a hashing algorithm. Some are easier, some are harder. And it's unlikely that in the case of a hashing algorithm, you're going to have a vulnerability that immediately makes that hashing algorithm completely useless. Rather, what has happened in the past and is likely to happen with SHA-2 again, is that either a mathematical technique is discovered or a particular weakness that makes it slightly easier to attack the algorithm, meaning that it is theoretically possible at first with enormous computing power, and then eventually practically possible with enormous computing power, and then possible with even less computing power until eventually mainstream computers can break it. We saw that happen with algorithms such as MD5, for example, and the data encryption standard. An initial weakness was only exploitable in very narrow circumstances with enormous amounts of computing, and eventually nowadays you can break MD5 on your laptop in a reasonable amount of time quite easily. So we're not going to see SHA-256 go from completely secured to completely insecure. Rather, it's going to get eroded and become weaker over time, and that will require replacements. SHA-256 can be replaced in Bitcoin. There are a number of different places where it's used, and already there have been some upgrades. For example, SegWit changes the way addresses are computed for scripts, so making them stronger than they were before. With SegWit V0, a script is encoded as a double SHA-256 instead of a ripe MD-160, increasing the key space significantly in order to preempt potential attacks against pay-to script hash. So we could see other upgrades like that, we can see changes in algorithms, and for the most part the Bitcoin system can be upgraded fairly easily now with SegWit in ways that can address future impacts on cryptographic functions. However, one of the areas where this is more difficult is in mining itself. So we may see that it is much more difficult to change the mining algorithm of Bitcoin, and the reason for that is because you have all of this deployed equipment. However, if it becomes easier and easier to mine SHA-256, that's going to cause some changes in the difficulty of the algorithm, because miners will use the shortcuts to get greater profitability, which will drive the hash rate up and will of course then cause the difficulty to go up. In fact, that's already happened. Particular manipulation of the SHA-256 algorithm, called ASIC Boost, was implemented three years ago, and has led to a reduction in the amount of electricity needed to produce SHA-256 hashes, and therefore an increase in the efficiency of mining, and therefore an increase in the hash rate and difficulty of the Bitcoin system. That's exactly the kind of thing we'll see over time. So, in general, these things can be upgraded. The additional comment you made, George, which is, what is the purpose of double-hashing a public key to produce the address, and double-hashing it with two different algorithms, SHA-256 and then RIPE MD-160? Well, the first reason is to create a level of abstraction where what you're paying is a hash, not a public key. That gives us a lot of flexibility, including, as we've seen with the implementation of script hashes, the ability to pay to scripts that are more complicated than simply a public key. The other thing it does is it creates a degree of separation whereby, if the elliptic curve digital signature algorithm is found to be weak, but you don't have a public key and you have to crack a Bitcoin address, you have to crack two different hash algorithms before you get to cracking the elliptic curve, which creates a significant difficulty because hash algorithms and elliptic curve digital signature algorithms behave differently. One such example is in the use of quantum computers, which we'll address in one of the following questions. I hope that answered your questions, George.