How the Recipient's public key is used in bitcoin transaction In the second paragraph the white paper by Nakatomo, we have this image: 



It says a coin is a set of digital signature. For what I understand the whole process is the following: 


Hash together the previous transaction hash plus the recipient public key;
digitally sign the hashing string with the private key of the sender;


The digitally signed result represents the transaction.

I have a couple of questions. 

First of all, when the transaction is trasmitted to majority of the nodes, they have to decrypt the signed transactions by applying the public key of the sender to verify his identity. 
Well, where the nodes take the public key of the sender? I thought that they can retrieve it by looking at previous transaction (where in the last transaction the actual sender will figure out as a receiver and so his public key is in the input of the hash function), but we cannot do so because the transaction is again encrypted and we need the public key of the last-last owner.

The other question is about the Receiver public key inside the data in the hash function. Does this really matter as a proof that the coin associated to that transaction are held by the new owner? Or they play a role in the user validation? I mean, the arrow with the name "verify" what stands for?
It says a coin is a set of digital signature. For what I understand the whole process is the following:

Hash together the previous transaction hash plus the recipient public key;

digitally sign the hashing string with the private key of the sender;



The thing that is signed is not related to the previous transaction. It is actually the current transaction that is being created (or parts of it), but without the signatures.

The digitally signed result represents the transaction.

No. The result is never transmitted as it can be calculated from the transaction itself. The signature is placed inside of the transaction.

First of all, when the transaction is trasmitted to majority of the nodes, they have to decrypt the signed transactions by applying the public key of the sender to verify his identity.

No. There is no encryption or decryption happening. A digital signature does not produce any encrypted data. Nodes should be verifying that the transaction is signed with the public key.

Well, where the nodes take the public key of the sender?

The public key is either provided in the transaction output that is being spent (so nodes refer back to the previous transaction) or it is provided within the spending transaction itself. In the latter case, typically the previous transaction output will contain the hash of the public key so nodes will check that the public key provided hashes to that hash.
Note that I say typically because there are cases where none of this is true. Since Bitcoin uses a script system, anyone can create a script which does whatever they want, including signing the transaction or not. Transactions are only signed because the commonly used scripts say that the transaction must be signed in order to be spendable, but not all scripts require that.

but we cannot do so because the transaction is again encrypted and we need the public key of the last-last owner.

No. Again, nothing is encrypted. Furthermore, in an encryption scheme, the public key is absolutely useless for attempting to decrypt something. Things can only be decrypted with the private key. All blocks and transactions in Bitcoin are not encrypted and all of their details can be plainly read.

The other question is about the Receiver public key inside the data in the hash function. Does this really matter as a proof that the coin associated to that transaction are held by the new owner? Or they play a role in the user validation? I mean, the arrow with the name &quot;verify&quot; what stands for?

Yes, it does matter. Otherwise anyone could provide a public key which has a valid signature. The point of having the hash of the public key is to prove that the public key provided is the correct one and that the previous transaction committed to that public key (i.e. the previous transaction actually specified that public key).