"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..