You've received several responses, and much of what I'm about to say will probably just be a re-phrasing of what's already been written in this thread. However, I'll attempt to provide a more complete and detailed explanation if I can.
The first thing you'll need to understand is that the Whitepaper does NOT describe exactly how Bitcoin works. The whitepaper was released before Satoshi had finished writing the software and provided an overview of one way that proof-of-work, and a chain of signatures could be used to create a digital currency. Several improvements were made in the final version of the actual software, and this transaction structure therefore changed significantly.
The additional educational resources you've been provided by others (such as learnmeabitcoin) will give a better understanding of how Bitcoin actually works, but may cause additional confusion if you try to apply what you learn there to what you see in the whitepaper.
That all being said, here's my attempt to explain what you're seeing in that image:
Let's start by making it clear that the "transaction" on the left is not a transaction being sent by "Owner 1". It is the transaction whereby "Owner 1" initially received the value that they will be using. "Owner 0" signed that transaction when they created and broadcast it to initially pay "Owner 1" (which is why you see an "Owner 0's signature" in that transaction).
Next, let's go over a brief explanation of public key cryptography, and digital signatures. A person generates a pair of keys. One that they keep secret and secure (the "private" key) and another that they share with others (the "public" key). The "signature" is a value that is calculated by using some source of data and a private key. A person can use their private key to sign some set of data (generate the signature value using the appropriate calculations). If they then provide the data, the public key, and the signature, then it is possible with another calculation to verify the signature. In that case, the verifier can perform a calculation using the provided data and the result makes it clear that the ONLY way to have generated the signature value is if 2 things are BOTH true:
- The data is the EXACT same data that was used by the person that created the signature (if the data changed, then the verification calculation would no longer work).
- The signature was generated using the private key that is associated with the given public key, meaning that ONLY someone with acess to that private key could have created the signature
When transactions are used for the data, this combination of facts means that anyone with access to the transaction, the public key, and the signature can verify that the transaction they are looking at is definitely the one that was signed (hasn't been modified) and that the signature came from someone that has access to the private key.
At some point in time prior to the image that you provided, "Owner 0" offered to send a transaction to pay "Owner 1". "Owner 1" generated a key pair
and provided "Owner 0" with the public key, telling "Owner 0" to embed that public key in the transaction. The concept that Satoshi is suggesting in that part of the whitepaper is that we can create a requirement that the ONLY way someone can be allowed to spend value in a given transaction is if they can provide a signature that can be verified with the public key that is embedded in the transaction.
So, "Owner 0" creates the transaction that you see on the left, and they sign it. It has embedded in it the public key provided to "Owner 0" by "Owner 1". This means that the ONLY way to now spend the value in the transaction is if you can provide a signature that can be verified by the public key that is embedded in the transaction. Since "Owner 1" is the person that generated that key-pair, as long as they do a good job of keeping their private key secure, they are the only person in the world that will be able to provide a valid signature.
Now that we understand what the important pieces are of that transaction on the left , let's look at what happens when "Owner 1" needs to pay "Owner 2". It can get very big if every time you create a transaction you need to embed the entire previous transaction in the new transaction so that you have all the necessary pieces to validate. Instead, Satoshi suggests that we use a digest. A much smaller value that can be trusted to represent the data that is being used. Then, you can go back and look at the original transaction, and compare against it's hash to make sure that you are looking at an accurate representation.
- "Owner 2" generates a key pair and provides "Owner 1" with the public key, telling "Owner 1" to embed that public key in the transaction that they create.
- "Owner 1" creates the transaction that you see in the middle column. They embed the public key that was supplied by "Owner 2", and they embed a hash generated from a set of data that includes both that public key (2) and the earlier transaction where they received the value that they are spending (1)
- "Owner 1" generates a signature of this hash using their private key (4), and include this signature in the transaction that they are creating (3)
- "Owner 2" (and the rest of the world) are now able to verify (5) that "Owner 1" has the authority to spend the value from the transaction in the first column
The reason that they can all verify this is because they can hash the data in the left transaction (along with "Owner 2" public key from the middle transaction) and compare that to the hash embedded in the middle transaction to prove that neither the data in the left transaction nor the embeded "Owner 2" public key has been altered. They can then use the signature provided in the middle transaction along with the hash and the public key from the first transaction to verify that the signature could ONLY have been calculated by someone that has access to the private key that is associated with the public key in the left transaction, and that the hash in the middle transaction hasn't been altered.
With the signature provided by "Owner 1" in the middle transaction, he has proven that he is has the authority to spend the value he received in the left transaction (verifiable by using the public key from the left transaction)
With "Owner 1" embedding the public key of "Owner 2" in the middle transaction, "Owner 1" has created a requirement that the value from the middle transaction can ONLY be spent by the person that has access to the associated private key.
The hash that is embedded in the middle transaction links the two transactions together, since any change to any of the data in either transaction would result in a different hash. This makes it possible for EVERYONE to verify that the transactions have not been modified/manipulated and that the value from the left transaction is now under the control of the middle transaction.
I'll repeat, THIS IS
NOT HOW BITCOIN WORKS. Some of the concepts and ideas were re-used, and there are some similarities, but there are also some significant differences.