<blockquote>
<p>It says a coin is a set of digital signature. For what I understand the whole process is the following:</p>
<ol>
<li><p>Hash together the previous transaction hash plus the recipient public key;</p>
</li>
<li><p>digitally sign the hashing string with the private key of the sender;</p>
</li>
</ol>
</blockquote>
<p>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.</p>
<blockquote>
<p>The digitally signed result represents the transaction.</p>
</blockquote>
<p>No. The result is never transmitted as it can be calculated from the transaction itself. The signature is placed inside of the transaction.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>Well, where the nodes take the public key of the sender?</p>
</blockquote>
<p>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.</p>
<p>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.</p>
<blockquote>
<p>but we cannot do so because the transaction is again encrypted and we need the public key of the last-last owner.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>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).</p>

CC BY-SA 3.0
2018-03-11T10:20:05.880Z
Thank you.
So the flow is the following:

1) The sender send transaction data (plain data including receiver pub key) + digital signature (the signed hash of the data using his private key);
2) Other nodes use the pub key of the sender retrieved from the previous transaction (that is not encrypted), to verify the digital signature and to be sure that the sender was him and that the data have not been changed;

(if it's so) What I was missing is that this follows the normal working scheme of the digital signature.
xcsob
CC BY-SA 3.0
2018-03-11T15:37:06.893Z
The transaction data contains the signature itself, it isn't separate. The pubkey can also be part of that transaction data to, or it can be found in the previous transaction.
Ava Chow
CC BY-SA 3.0
2018-03-11T03:38:37.943Z
2018-03-11T03:38:37.943Z
2020-06-16T11:10:03.350Z
Ava Chow
<p>In the second paragraph the <a href="https://bitcoin.org/bitcoin.pdf" rel="nofollow noreferrer">white paper by Nakatomo</a>, we have this image: </p>

<p><a href="https://i.sstatic.net/YXguz.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/YXguz.png" alt="enter image description here"></a></p>

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

<ol>
<li>Hash together the previous transaction hash plus the recipient public key;</li>
<li>digitally sign the hashing string with the private key of the sender;</li>
</ol>

<p>The digitally signed result represents the transaction.</p>

<p>I have a couple of questions. </p>

<p>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.</p>

<p>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?</p>

CC BY-SA 3.0
2018-03-11T00:46:25.643Z
Why is this tagged "ethereum"?
Nate Eldredge
CC BY-SA 3.0
2018-03-11T09:01:17.607Z
Achow explained already the details, I want to give one further hint: the bitcoin system has a locking and unlocking mechanism. The locking mechanism is in the pubkey script (some refer to it also as the spending condition), and the unlocking is in the sigscript of the transaction. In the pubkey script the author of a tx defines the target address (to whom the tx shall go), and the spending condition(s). When then the receiver of the tx wants to spend the tx, (s)he needs to fulfill the condition (usually by showing the pubkey in hex format) and also signs the tx with his priv key.
pebwindkraft
CC BY-SA 3.0
2018-03-11T09:01:49.750Z
All the details in Andreas' very well written book "Mastering Bitcoin" in section 6 "Transactions". It is online available...
pebwindkraft
CC BY-SA 3.0
2018-03-11T17:47:23.183Z
@pebwindkraft can you link the book, if there is a free ebook available?
xcsob
CC BY-SA 3.0
2018-03-11T17:48:44.387Z
@pebwindkraft are referring only to bitcoin, or to smart contracts? Where do we find these spending condition in the white paper from nagatomo? 
(I have not read the technical specification on github yet)
xcsob
CC BY-SA 3.0
2018-03-11T20:54:39.327Z
last link I had was here: http://chimera.labs.oreilly.com/books/1234000001802/index.html - a little bit of research on the net may help as well (google books), sometimes the webpages change. In my answer I am referring to transactions in bitcoin, not to smart contracts. I haven't searched the whitepaper for these spending conditions, it must not be there. But the logic can be derived in this sense.
pebwindkraft
<signature>
How the Recipient's public key is used in bitcoin transaction
xcsob
# How the Recipient's public key is used in bitcoin transaction

(Asked by: username_0 on 2018-03-11)

In the second paragraph the [white paper by Nakatomo](https://bitcoin.org/bitcoin.pdf), we have this image:

[![enter image description here](https://i.sstatic.net/YXguz.png)](https://i.sstatic.net/YXguz.png)

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

1. Hash together the previous transaction hash plus the recipient public key;
2. 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?

**Tags:** signature

> **Comments:**
> **username_1**: Why is this tagged "ethereum"?  
> **username_2**: Achow explained already the details, I want to give one further hint: the bitcoin system has a locking and unlocking mechanism. The locking mechanism is in the pubkey script (some refer to it also as the spending condition), and the unlocking is in the sigscript of the transaction. In the pubkey script the author of a tx defines the target address (to whom the tx shall go), and the spending condition(s). When then the receiver of the tx wants to spend the tx, (s)he needs to fulfill the condition (usually by showing the pubkey in hex format) and also signs the tx with his priv key.  
> **username_2**: All the details in Andreas' very well written book "Mastering Bitcoin" in section 6 "Transactions". It is online available...  
> **username_0**: @username_2 can you link the book, if there is a free ebook available?  
> **username_0**: @username_2 are referring only to bitcoin, or to smart contracts? Where do we find these spending condition in the white paper from nagatomo?  (I have not read the technical specification on github yet)  
> **username_2**: last link I had was here: http://chimera.labs.oreilly.com/books/1234000001802/index.html - a little bit of research on the net may help as well (google books), sometimes the webpages change. In my answer I am referring to transactions in bitcoin, not to smart contracts. I haven't searched the whitepaper for these spending conditions, it must not be there. But the logic can be derived in this sense.  

---

## 1 answers

### Answer by username_3 on 2018-03-11. Score: 1 | Accepted answer

> It says a coin is a set of digital signature. For what I understand the whole process is the following:
>
> 1. Hash together the previous transaction hash plus the recipient public key;
> 2. 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 "verify" 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).

> **Comments:**
> **username_0**: Thank you. So the flow is the following:  1) The sender send transaction data (plain data including receiver pub key) + digital signature (the signed hash of the data using his private key); 2) Other nodes use the pub key of the sender retrieved from the previous transaction (that is not encrypted), to verify the digital signature and to be sure that the sender was him and that the data have not been changed;  (if it's so) What I was missing is that this follows the normal working scheme of the digital signature.  
> **username_3**: The transaction data contains the signature itself, it isn't separate. The pubkey can also be part of that transaction data to, or it can be found in the previous transaction.  

---

