<p>Firstly, transactions are not blocks, and blocks are not transactions. They are two distinct data structures that you seem to think are the same thing.</p>

<blockquote>
  <p>How is that calculated?</p>
</blockquote>

<p>By performing SHA256 double on the transaction.</p>

<blockquote>
  <p>I see an arrow coming from the left (I'll get to that in a moment)--it seems to depict the Hash of the previous transaction block. But the arrow coming from Owner 1's Public Key confuses me too. Is this diagram saying that owner 1's public key is hashed together with the previous block's hash value? Is that what actually happens in Bitcoin, or is there more detail?</p>
</blockquote>

<p>Yes, the public key is part of the data that is hashed in a transaction.</p>

<blockquote>
  <p>'d like to see the original block in the depicted hash chain because that original block wouldn't have a previous block hash to reference. So would that mean that the first block's hash is just a hash of the owner's public key?</p>
</blockquote>

<p>A transaction is more than just a public key and an output. But the first transaction in that transaction chain does not have any inputs so it does not have any previous transactions that it references. This transaction is known as a coinbase transaction or a coin generation transaction. It is created by miners and essentially produces Bitcoin out of nothingness.</p>

<blockquote>
  <p>Are there any good resources that go into more technical detail about the first block in the transaction hash chain and how these hashes are calculated?</p>
</blockquote>

<p>Bitcoin.org's <a href="https://bitcoin.org/en/developer-guide" rel="nofollow noreferrer">developer guide</a> explains most of Bitcoin's details.</p>

<hr>

<blockquote>
  <p>Is the arrow coming from the Owner's Public Key saying that the Hash is encrypted with the owner's public key?</p>
</blockquote>

<p>No, it is saying that the public key is used to verify Owner 1's signature. This public key is specified in the previous transaction. In order to know what the previous transaction is, we place the hash of it in the current transaction (Owner 2's transaction). That way we can quickly lookup Owner 1's transaction to retrieve Owner 1's public key.</p>

<p>There is no encryption that happens in the Bitcoin protocol. Nothing is encrypted.</p>

<blockquote>
  <p>In other words, does the previous transaction's hash get somehow combined with a new hash before being encrypted with the public key?</p>
</blockquote>

<p>Yes, the previous transaction's hash is combined with the other data in the current transaction to produce the current transaction's hash.</p>

<hr>

<p>Instead of trying to understand the technical details and diagrams that Satoshi put in the whitepaper, you should try to understand how Bitcoin actually works today based on the code and other documentation available. The whitepaper does not describe how Bitcoin actually works; it was written months before the first release and lots of details changed between the concepts in the whitepaper and the actual implementation of those concepts.</p>

CC BY-SA 4.0
2018-05-23T17:27:59.823Z
Correct me if I am wrong but I am not talking about blocks on the blockchain--I *know* the difference between that block and a transaction block. I am talking about transaction blocks on the transaction hash chain the tracks a digital asset from genesis across all owners. Can't each link (data object) in this transaction-chain be called a "transaction block"?
Jazimov
CC BY-SA 4.0
2018-05-23T17:35:13.950Z
I read the developer's guide and I think our disconnect is that Bitcoin doesn't actually create or discuss a hash chain of transactions. This is more of an abstraction of a data structure that could be created from the transaction hashes. So I don't think it's relevant to discuss the nomenclature of such "transaction blocks" here...
Jazimov
CC BY-SA 4.0
2018-05-23T17:40:08.833Z
Question edited for clarity. I am interested in the first and subsequent Hash values along the ownership chain of transactions.
Jazimov
CC BY-SA 4.0
2018-05-23T17:51:43.280Z
I think I really messed up in how I asked my question. Rather than post a new question, I decided to reduce this one to what I really am trying to ask and reduce all of the clutter in my original question. Please accept my apologies and new clarifications. I am really trying to understand this. The developers guide did not help me with the specific question I am asking.
Jazimov
CC BY-SA 4.0
2018-05-23T17:52:09.380Z
No, it is not a transaction block. It is just a transaction. Calling them blocks or transaction blocks will just create more confusion. Just call it a transaction. Also, Bitcoin does create chains of transactions. A transaction input directly references the txid (aka hash) of a previous transaction.
Ava Chow
CC BY-SA 4.0
2018-05-23T18:11:12.463Z
I am not trying to understand Bitcoin from the diagram. I am trying to figure out what is generically done in such transaction chains. I don't even care whether it's Ripple, Ethereum, or Bitcoin. I'm trying to figure out what the intent was because I'd like to be able to teach the idea behind the transaction chain. I am just hung up on the Hash. I can't figure out if the transactions have two Hash values--one for the digital asset being tracked and the other for the transaction block, so that it can back-link to the previous block... If there is only one Hash, that helps to know...
Jazimov
CC BY-SA 4.0
2018-05-23T18:23:55.177Z
Each transaction has its own hash. That hash is not part of the transaction itself because it is computed directly from the transaction. Each transaction (except for coinbase transactions) also contain the hash of a previous transaction. In the diagram, the hash that is shown is a different hash each time, it is the hash of the previous transaction.
Ava Chow
CC BY-SA 4.0
2018-05-23T18:25:16.953Z
OK--Thanks. Last clarification: I was not talking about the dashed arrow from the Owner's Public Key--I understand that it's used to verify. I was talking about the solid arrow that points to the Hash. What is that saying?
Jazimov
CC BY-SA 4.0
2018-05-23T18:28:38.657Z
The solid arrow means that the public key AND the previous transaction are hashed together. Note that this is not how Bitcoin (or any coin that I am aware of) works and is completely unnecessary.
Ava Chow
CC BY-SA 4.0
2018-05-23T18:34:31.413Z
I think you just NAILED my confusion--thank you! So the public key just sits in the transaction--it doesn't do anything other than help validate the signature for the *next* transaction... Right? :)
Jazimov
CC BY-SA 4.0
2018-05-23T18:40:53.833Z
Yes. The public key is in the transaction only for signature validation.
Ava Chow
CC BY-SA 4.0
2018-05-23T18:50:11.113Z
All that chat just to learn that one simple fact? Sheesh! :) :) :) You made my day. Thank you!
Jazimov
CC BY-SA 4.0
2018-05-23T18:58:20.923Z
"There is no encryption that happens in the Bitcoin protocol. Nothing is encrypted." If this is a semantic issue then fine, but isn't "signing with a private key" a form of digital encryption? I want to learn what's correct--I see "encryption" used all the time when talking about PKC...
Jazimov
CC BY-SA 4.0
2018-05-23T21:15:27.123Z
A digital signature is not the same thing as encryption. Encryption obfuscates a message so that no one except the intended recipients can read the message. With a digital signature, the message is not obfuscated. Rather the message is in plaintext and the signature serves as proof that the owner of the public key created the message and verifies the message's authenticity (i.e. it was not tampered).
Ava Chow
CC BY-SA 4.0
2018-05-23T21:18:55.343Z
Thanks Andrew, but I thought a digital signature encrypts a hash of the message--then the message and the encrypted hash are sent together to the recipient. I thought the recipient uses the public key to verify by decrypting the hash then recomputing the hash against the message to ensure a match. Now if we're saying the same thing, fine. Otherwise, I am curious where I have gone wrong in my understanding. I do understand that the message itself is not encrypted--but isn't the hash? And if it's only the hash, perhaps it's not good to talk about encryption at all bcse message is not encrypted.
Jazimov
CC BY-SA 4.0
2018-05-23T21:23:40.773Z
It may be that way for some digital signature algorithms, but Bitcoin uses ECDSA which does not do that. The message hash is not recovered in any way, it must be recomputed from the message in order to perform signature verification.
Ava Chow
CC BY-SA 4.0
2018-05-23T21:23:53.810Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/77912/discussion-between-andrew-chow-and-jazimov).
Ava Chow
CC BY-SA 4.0
2018-05-23T16:14:11.863Z
2018-05-23T17:57:05.597Z
2018-05-23T17:57:05.597Z
Ava Chow
<p>In Satoshi Nakamoto's diagram: </p>

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

<p>Consider the Hash block in the first transaction block above:</p>

<p>How is that Hash value calculated? I see arrows from an Owner's Public Key and another arrow, so it's confusing. Is the arrow coming from the Owner's Public Key saying that the Hash is encrypted with the owner's public key? If yes, then what is the other arrow? Is that involved during the encryption with the public key? In other words, does the previous transaction's hash get somehow combined with a new hash before being encrypted with the public key? What exactly is going on here?</p>

<p>Thank you.</p>

<transactions><blockchain><hash><transaction-id>
Confused About Hash In Satoshi Nakamoto Diagram
Jazimov
# Confused About Hash In Satoshi Nakamoto Diagram

(Asked by: username_0 on 2018-05-23)

In Satoshi Nakamoto's diagram:

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

Consider the Hash block in the first transaction block above:

How is that Hash value calculated? I see arrows from an Owner's Public Key and another arrow, so it's confusing. Is the arrow coming from the Owner's Public Key saying that the Hash is encrypted with the owner's public key? If yes, then what is the other arrow? Is that involved during the encryption with the public key? In other words, does the previous transaction's hash get somehow combined with a new hash before being encrypted with the public key? What exactly is going on here?

Thank you.

**Tags:** transactions, blockchain, hash, transaction-id


---

## 1 answers

### Answer by username_1 on 2018-05-23. Score: 2 | Accepted answer

Firstly, transactions are not blocks, and blocks are not transactions. They are two distinct data structures that you seem to think are the same thing.

> How is that calculated?

By performing SHA256 double on the transaction.

> I see an arrow coming from the left (I'll get to that in a moment)--it seems to depict the Hash of the previous transaction block. But the arrow coming from Owner 1's Public Key confuses me too. Is this diagram saying that owner 1's public key is hashed together with the previous block's hash value? Is that what actually happens in Bitcoin, or is there more detail?

Yes, the public key is part of the data that is hashed in a transaction.

> 'd like to see the original block in the depicted hash chain because that original block wouldn't have a previous block hash to reference. So would that mean that the first block's hash is just a hash of the owner's public key?

A transaction is more than just a public key and an output. But the first transaction in that transaction chain does not have any inputs so it does not have any previous transactions that it references. This transaction is known as a coinbase transaction or a coin generation transaction. It is created by miners and essentially produces Bitcoin out of nothingness.

> Are there any good resources that go into more technical detail about the first block in the transaction hash chain and how these hashes are calculated?

Bitcoin.org's [developer guide](https://bitcoin.org/en/developer-guide) explains most of Bitcoin's details.

---

> Is the arrow coming from the Owner's Public Key saying that the Hash is encrypted with the owner's public key?

No, it is saying that the public key is used to verify Owner 1's signature. This public key is specified in the previous transaction. In order to know what the previous transaction is, we place the hash of it in the current transaction (Owner 2's transaction). That way we can quickly lookup Owner 1's transaction to retrieve Owner 1's public key.

There is no encryption that happens in the Bitcoin protocol. Nothing is encrypted.

> In other words, does the previous transaction's hash get somehow combined with a new hash before being encrypted with the public key?

Yes, the previous transaction's hash is combined with the other data in the current transaction to produce the current transaction's hash.

---

Instead of trying to understand the technical details and diagrams that Satoshi put in the whitepaper, you should try to understand how Bitcoin actually works today based on the code and other documentation available. The whitepaper does not describe how Bitcoin actually works; it was written months before the first release and lots of details changed between the concepts in the whitepaper and the actual implementation of those concepts.

> **Comments:**
> **username_0**: Correct me if I am wrong but I am not talking about blocks on the blockchain--I *know* the difference between that block and a transaction block. I am talking about transaction blocks on the transaction hash chain the tracks a digital asset from genesis across all owners. Can't each link (data object) in this transaction-chain be called a "transaction block"?  
> **username_0**: I read the developer's guide and I think our disconnect is that Bitcoin doesn't actually create or discuss a hash chain of transactions. This is more of an abstraction of a data structure that could be created from the transaction hashes. So I don't think it's relevant to discuss the nomenclature of such "transaction blocks" here...  
> **username_0**: Question edited for clarity. I am interested in the first and subsequent Hash values along the ownership chain of transactions.  
> **username_0**: I think I really messed up in how I asked my question. Rather than post a new question, I decided to reduce this one to what I really am trying to ask and reduce all of the clutter in my original question. Please accept my apologies and new clarifications. I am really trying to understand this. The developers guide did not help me with the specific question I am asking.  
> **username_1**: No, it is not a transaction block. It is just a transaction. Calling them blocks or transaction blocks will just create more confusion. Just call it a transaction. Also, Bitcoin does create chains of transactions. A transaction input directly references the txid (aka hash) of a previous transaction.  
> **username_0**: I am not trying to understand Bitcoin from the diagram. I am trying to figure out what is generically done in such transaction chains. I don't even care whether it's Ripple, Ethereum, or Bitcoin. I'm trying to figure out what the intent was because I'd like to be able to teach the idea behind the transaction chain. I am just hung up on the Hash. I can't figure out if the transactions have two Hash values--one for the digital asset being tracked and the other for the transaction block, so that it can back-link to the previous block... If there is only one Hash, that helps to know...  
> **username_1**: Each transaction has its own hash. That hash is not part of the transaction itself because it is computed directly from the transaction. Each transaction (except for coinbase transactions) also contain the hash of a previous transaction. In the diagram, the hash that is shown is a different hash each time, it is the hash of the previous transaction.  
> **username_0**: OK--Thanks. Last clarification: I was not talking about the dashed arrow from the Owner's Public Key--I understand that it's used to verify. I was talking about the solid arrow that points to the Hash. What is that saying?  
> **username_1**: The solid arrow means that the public key AND the previous transaction are hashed together. Note that this is not how Bitcoin (or any coin that I am aware of) works and is completely unnecessary.  
> **username_0**: I think you just NAILED my confusion--thank you! So the public key just sits in the transaction--it doesn't do anything other than help validate the signature for the *next* transaction... Right? :)  
> **username_1**: Yes. The public key is in the transaction only for signature validation.  
> **username_0**: All that chat just to learn that one simple fact? Sheesh! :) :) :) You made my day. Thank you!  
> **username_0**: "There is no encryption that happens in the Bitcoin protocol. Nothing is encrypted." If this is a semantic issue then fine, but isn't "signing with a private key" a form of digital encryption? I want to learn what's correct--I see "encryption" used all the time when talking about PKC...  
> **username_1**: A digital signature is not the same thing as encryption. Encryption obfuscates a message so that no one except the intended recipients can read the message. With a digital signature, the message is not obfuscated. Rather the message is in plaintext and the signature serves as proof that the owner of the public key created the message and verifies the message's authenticity (i.e. it was not tampered).  
> **username_0**: Thanks Andrew, but I thought a digital signature encrypts a hash of the message--then the message and the encrypted hash are sent together to the recipient. I thought the recipient uses the public key to verify by decrypting the hash then recomputing the hash against the message to ensure a match. Now if we're saying the same thing, fine. Otherwise, I am curious where I have gone wrong in my understanding. I do understand that the message itself is not encrypted--but isn't the hash? And if it's only the hash, perhaps it's not good to talk about encryption at all bcse message is not encrypted.  
> **username_1**: It may be that way for some digital signature algorithms, but Bitcoin uses ECDSA which does not do that. The message hash is not recovered in any way, it must be recomputed from the message in order to perform signature verification.  
> **username_1**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/77912/discussion-between-andrew-username_1-and-username_0).  

---

