"What does the following sentence mean? 'when transactions are broadcast to the network, the SHA-256 function is used to verify data integrity'" Well, cryptographic hashes offer the ability to produce a fingerprint [of a piece of data]
A hash functions [produces] a cryptographic digest [You can provide] an arbitrary length data stream of bits [as input] and it will convert it to a fixed length [output] 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 / inpute data; even a small change in the [input] would lead to a large change in the fingerprint [output] That is one of the characteristics of cryptographic hash functions They allow us to produce fingerprints of data which help you confirm that it has not been modified since [the hash] was created For example, this would apply to a file, such as a picture or PDF, on your computer If you want to make sure it hasn't been modified, you could use a cryptographic hash function like SHA-256 to produce the fingerprint As long as you can check [the input against the output] again, you can make sure that it hasn't been changed In the case of transactions, the transaction itself is hashed using SHA-256 In fact, it is double-hashed
The result is called the transaction ID That acts as a fingerprint You can't change [any fields in] 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
When you sign something with a digital signature, you don't sign the data itself That would be inefficient Instead, you sign a hash of the data The fingerprint summarizes the data in a way that can't be changed, and then you apply a digital signature, certifying that it was made by you / your private key Both of those techniques, used together, verify the transaction's integrity
The signatures within a transaction validate that the [correct] private key was used to authorize it, [hopefully by] the person who is authorized to spend the bitcoin The transaction can't be modified because its fingerprint has been signed You can't modify the transaction without modifying the fingerprint, which then invalidates the signature A related follow-up question: "Many wallets offer an option to sign a message What does this mean?" "How is it displayed on the blockchain? Does it have anything to do with sending funds?" Great question
The option to sign a message, which you can find in many wallets, allows you to submit an arbitrary piece of data, for example a text message, and then using a private key [within] your wallet to apply a digital signature to that text message Essentially, it signs a cryptographic fingerprint of that message You could write a message which says: "On this day, I approve" or "testify that this happened" Then you use one of your private keys from your wallet to sign that [message]
If send somebody else the signed message, they can verify [the signature] against your bitcoin address They can prove that it was signed by you, using public key cryptography to sign messages This [use case doesn't need to involve] spending funds [by] signing transactions It is the same technique and technology that you would use to sign transactions, but instead of signing a transaction that you present to the [network] to spend funds, you are signing a text message that you can present to whoever you want, and prove that you signed that text message It is not included in the blockchain
It [does not need to be] transmitted to the blockchain It simply creates a signed message [However, it does not prove that what you said is true] For example, you could say, "I am Satoshi Nakamoto," and sign with keys [linked to] the coinbase of the Genesis block That would prove that you control those keys, but it wouldn't prove that you are Satoshi Nakamoto
It is the kind of proof which could be implemented [or faked] by someone claiming to be Satoshi Nakamoto It tells us a lot when that kind of simple proof is forged "Compressed versus uncompressed keys, and validation of uncompressed keys" "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 could lose funds in the future soft fork" Part of the problem there is, pay-to-witness public key hash (P2WPKH), which is the SegWit version of the standard pay-to-public key hash (P2PKH), does not support uncompressed public keys Those have been obsolete since 2013 Therefore, carrying them forward into SegWit is a waste of space and optimization It is also unnecessary because they are barely used The second part of the question is: "How can we determine if a Coinbase account [uses]
a compressed or uncompressed public key, and therefore will be valid going forward?" As a practical matter, Coinbase's SegWit addresses are not P2WPKH They are P2WPKH wrapped in pay-to-script hash (P2SH) If Coinbase generated 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 to an address at Coinbase, or any exchange, they will almost immediately sweep that money and stick it into cold storage They don't just leave it in the address you sent it to Check it out [for yourself] The next time you send [bitcoin] to an exchange or merchant processor, watch the blockchain [for an hour or so] and you will see what happens That money will move again to another address
You will see it consolidated with [other bitcoin], maybe jump a few hops and then stop at an address with a lot of bitcoin in it That is [their] cold storage Whatever address they gave you [to deposit], they are only using it temporarily Then they will move the funds elsewhere They will make sure that they can move those funds
If they have implemented SegWit [well], which they [should] have, you can rest assured that implemented it in a way that only uses compressed public keys That is determined by them, encoded in the '3' address
It is constructed based on the underlying public key You can be sure that they put a compressed one in there Otherwise, that would violate the SegWit standard, and they would [risk] losing [customer] money It doesn't matter what your wallet is doing One of the critical characteristics of Bitcoin is, the recipient decides how to construct addresses, and the terms of how it will be spent
This is magical It means that, behind the address, you could have a [single] private key or a multi-sig You could have a witness private key or multi-sig, or a complex script with fifteen steps It could be a [funding transaction for] a Lightning channel None of that matters [to the one paying]
Your wallet will send to that address; hiding behind it is a script, which is determined by the recipient With the recipient being able to choose how they will receive and [the conditions] to spend, actually gives a lot of flexibility to the entire system That way, wallets don't need to know what the recipient intends to do with [the bitcoin], how their internal governance or key management is structured They just pay a hash, which is effectively what an address is Then it is the recipient's responsibility to give them the right hash [to pay]
So don't worry As long as you use the address that the recipient sends to you, it is their problem to make sure it is spendable With an exchange, arguably there are some risks There could be a mistake, a bug, they mess it up This is always a risk with custodial wallets
If you are giving them money, you are trusting them Among many other things, you are trusting them to handle the implementation correctly Let me clarify [As far as I know], Coinbase has implemented SegWit correctly You don't need to worry about that
You can verify that by [watching] as they sweep that money very quickly But in general, you are right They could have a bug in the implementation That [is part of] the custodial risk
