How the Recipient's public key is used in bitcoin transaction

0

1

In the second paragraph the white paper by Nakatomo, we have this image:

enter image description here

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?

xcsob

Posted 2018-03-11T00:20:47.187

Reputation: 3

Why is this tagged "ethereum"? – Nate Eldredge – 2018-03-11T00:46:25.643

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 – 2018-03-11T09:01:17.607

All the details in Andreas' very well written book "Mastering Bitcoin" in section 6 "Transactions". It is online available... – pebwindkraft – 2018-03-11T09:01:49.750

@pebwindkraft can you link the book, if there is a free ebook available? – xcsob – 2018-03-11T17:47:23.183

@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 – 2018-03-11T17:48:44.387

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 – 2018-03-11T20:54:39.327

Answers

1

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

Andrew Chow

Posted 2018-03-11T00:20:47.187

Reputation: 40 910

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 – 2018-03-11T10:20:05.880

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. – Andrew Chow – 2018-03-11T15:37:06.893

Asked: 2018-03-11T00:20:47.187

Viewed: 697 times

Active: 2018-03-11T09:34:14.560