 Yenis also asks, when transactions are broadcast to the network, the SHA-256 function is used to verify data integrity. One of the really useful functions that cryptographic hashes offer is the ability to produce a fingerprint. The way a hash function works, cryptographic digest or cryptographic hash function, is that it takes an arbitrary-length data stream of bits, basically, and converts it to a fixed-length number. For example, SHA-256 will take any amount of data and convert it to a 256-bit number. That 256-bit number depends on every bit in the source data in such a way that even a small change in the source data, just one bit change, will lead to a very large change in the outcome in the fingerprint. That is one of the characteristics of cryptographic hash functions, and allows us to do something very interesting, which is produce fingerprints. If you want to confirm that the data hasn't been modified since it was created, and this applies, for example, to a file on your computer, it applies to a picture that you want to make sure hasn't been modified, or PDF document. You could use cryptographic function like SHA-256 to produce a 256-bit fingerprint. As long as you can check that again, you can make sure that it hasn't changed. In the case of transactions, the transaction itself is hashed using the SHA-256 function. In fact, it is double-hashed, and the result is called the transaction ID. When you see a transaction ID, that transaction ID is produced by hashing all of the data in the transaction, using a specific formula, and that acts as a fingerprint. That transaction ID doesn't change, so you can't change the transaction without effectively changing the transaction ID. That way, you can ensure that the transaction hasn't been changed. Cryptographic hashes are also used in digital signatures, meaning that when you sign something with a digital signature, you don't sign the data itself. That would be inefficient. Instead, what you do is you sign a hash of the data. If you sign the hash of the data, you are essentially taking the fingerprint that summarizes the data in a way that can't be changed. Then you put a digital signature on that fingerprint, certifying that that was signed by you or your private key. Both of those techniques used together produce the integrity that you need in a transaction. The signatures within a transaction validate that the private key was used, so it shows that an authorized user created this transaction. The person who was authorized to spend the bitcoin. The transaction itself can't be modified because its fingerprint has been signed, and you can't modify the transaction without modifying the fingerprint, which then invalidates the signature. Yannis asks a related follow-up question, which is, many wallets offer an option to sign a message. What does this mean, and how is it displayed on the blockchain? Does it have anything to do with sending funds? Great question, Yannis. The option to sign a message that you find in many wallets is the option to take an arbitrary piece of data, which could be, for example, a text message that you could compose by writing a little text message, and then use the private keys controlled by your wallet to apply a digital signature to that text message. Essentially, it signs a cryptographic hash fingerprint of that message. You can write a message that says, on this day, I, Yannis, approve something. On this day, I, Yannis, testify that this happened. Then you use one of your private keys from your wallets to sign that. If you send them the signed message, somebody else can then verify against your Bitcoin address that this, in fact, was signed by you. You're basically using the private key, public key cryptography to sign messages that are not transactions. This has nothing to do with spending funds. This has nothing to do with signing transactions. It's the same technique. It's the same technology as you use to sign transactions. But instead of signing a transaction that you present to the blockchain, and the blockchain uses that to verify that you want to spend funds, you're signing a text message that you present to whoever you want that proves that you were willing to sign that text message, and whatever it says inside. It's not included in the blockchain. It's not transmitted to the blockchain. It simply creates a signed message. For example, you could say, I am Satoshi Nakamoto, and then sign with the keys that are in the Coinbase of the Genesis block. That would prove that you have control over those keys. It wouldn't actually prove that you are Satoshi Nakamoto. It would only prove that you have the keys from that Genesis block. It's the kind of simple proof that could be implemented by someone claiming to be Satoshi Nakamoto, for example. It tells us a lot when that kind of simple proof is forged. Compressed versus uncompressed keys, and validation of uncompressed keys. Michael asks, in mastering Bitcoin, you mentioned that if a hash used in the pay-to-witness public key hash came from an uncompressed public key, it may be unspendable, and you may lose funds in the plant's future soft fork. Part of the problem there, Michael, is that pay-to-witness public key hash, which is the seguit version of a standard payment transaction, does not support uncompressed public keys. That is because those have been obsolete since 2013. Therefore, carrying them forward into seguit is a waste of space and optimization. It is also unnecessary, because they are barely used. Michael's second part of the question is, how can we determine if a Coinbase account, for example, that we send funds to from, say, a ledger wallet that has a seguit, was a compressed or uncompressed public key, and therefore will be valid going forward? As a practical matter, Coinbase seguit addresses are not pay-to-witness public key hash. They are actually pay-to-witness public key hash wrapped in a script hash. If Coinbase created these witness addresses in a way that potentially made them unspendable in the future, that would represent an enormous risk to them. Keep in mind, the moment you send funds into a Bitcoin address given to you by Coinbase, or any exchange, they almost immediately sweep that money and stick it into cold storage. They don't just leave it in the address you sent it. Check it out. Next time you do a transaction where you send money to an exchange, or a merchant processing, or a retailer, or something like that, watch the blockchain and see what happens. Less than an hour after you do your transaction, that money is going to move again, and move to another address. Maybe you will see a consolidate with some other things, jump a few hops, and then stop at an address that has a lot of Bitcoin in it. That is cold storage. Essentially, whatever address they gave you, they are only using it temporarily, so they can then move the funds elsewhere. They can make sure they can move those funds. If they have implemented Segwit, which they have, you can rest assured that if they did their job well, they implemented Segwit in a way that only used compressed public keys. That is determined by them. That is encoded inside the three-address. The three-address itself, when it is constructed, is constructed based on the underlying public key. You can be sure they put a compressed one in there, because otherwise that would violate the Segwit standard, and they would stand a chance to lose their money. It doesn't matter what your wallet is doing. One of the really important characteristics of Bitcoin is that the recipient decides how to construct an address, and what that address means in terms of how it will be spent. This is magical, because it means that behind the address you could have a private key, a multi-sig, a witness multi-sig, a witness private key, a complex script with 15 steps. It could be a lightning channel. None of that matters, because all of it is going to be encoded in an address. Your wallet will send to that address. That address is hiding behind it a script, and that script is determined by the recipient. The flexibility of the recipient being able to choose how they receive and what is going to be required for them to spend it, actually gives a lot of flexibility to the entire system, because that way, wallets don't need to know what the recipient intends to do, what their internal governance structure or key management structure is. They just pay to a hash, which is effectively what a three-address or a segwit address is. Then it is the recipient's responsibility to give the right hash to them. Don't worry, as long as you are using the address that the recipient sent you, it is their problem to make sure that that is spendable. If it is an exchange, arguably there is some risk that they make a mistake, and there is a bug, and they mess it up, which is always a risk. That is a risk with custodial wallets. If you are giving them money, you are trusting them. Among other things, you are trusting them to do the implementation correctly. Let me clarify, Coinbase is implementing segwit correctly, so you don't need to worry about that. You can verify that by the fact that they execute the transactions and sweep that money very quickly. In general, you are right. They could have a bug in how they implement it, and that represents the custodial risk.