<blockquote>
  <p>What I don't understand is the need for the hashing of B's public key </p>
</blockquote>

<p>Hashing the public key is done for two reasons. It is a cost saving measure as it reduces the size of A's transaction. It also protects the actual public key so that, if Elliptic Curve Cryptography is broken, the private key cannot be reversed from the public key because the public key is not known until it is used in an input to a transaction.</p>

<blockquote>
  <p>and the previous transaction, </p>
</blockquote>

<p>Including the hashing of the previous transactions lets a transaction refer to the transactions it is spending from so that you can verify whether the money is legitimate.</p>

<blockquote>
  <p>and what exactly is being verified/signed.</p>
</blockquote>

<p>The message that is signed is the transaction (the one that is being created) itself. Of course it does not contain the signatures, but it contains everything else - the transactions being spent from and the outputs being created. This protects the other parts of the transaction from being modified by people not authorized to spend the money.</p>

<blockquote>
  <p>If transaction i - 1 is being hashed in transaction i, that means only transaction i - 1 is known. It says nothing about transaction i - 2, where the same money that is being spent in transaction i could have already been spent. It doesn't seem like transaction i - 1 or i keeps a list of all previous transactions, so there's no way of verifying where the buyer in i actually has the money.</p>
</blockquote>

<p>Transaction <code>i - 1</code> contains the hash of transaction <code>i - 2</code>, which contains the hash of <code>i - 3</code>, and so on and so forth until you reach transaction <code>i - i</code> (the "first" transaction) which is a special transaction known as a coinbase. This is a coin generation transaction. Thus by following the entire chain of transactions backwards, you can verify if the money actually exists.</p>

CC BY-SA 3.0
2018-01-20T23:46:40.417Z
2018-01-20T23:46:40.417Z
Ava Chow
<p>I'm trying to go through the whitepaper to get a better understanding of bitcoin but I don't understand the block and subsequent blockchain model to create a transaction. The problems that bitcoin seems like it is trying to address is verifying if person A actually has the money to send to person B, and ensuring person B can't alter the amount person A sends. </p>

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

<p>I get that if A is trying to send money to B, A should sign the transaction with his private key as B wants to ensure A is who is sending the money. What I don't understand is the need for the hashing of B's public key and the previous transaction, and what exactly is being verified/signed. </p>

<p>I read a bit about the problem of "double-spending" but I don't think I understand it entirely because I don't see how the above solves it. Double-spending as I understand it is A giving money to one person, then making the transaction seem like it didn't happen or is invalid in order to spend the same money to someone else. </p>

<p>If transaction i - 1 is being hashed in transaction i, that means only transaction i - 1 is known. It says nothing about transaction i - 2, where the same money that is being spent in transaction i could have already been spent. It doesn't seem like transaction i - 1 or i keeps a list of all previous transactions, so there's no way of verifying where the buyer in i actually has the money. </p>

<p>What is the purpose of hashing the recipients public key and the previous transaction, and what is being verified in the picture above</p>

CC BY-SA 3.0
2018-01-20T21:05:44.740Z
I provided an answer to a similiar question here: https://bitcoin.stackexchange.com/questions/69062/why-does-bitcoin-uses-a-script-language/69077#69077
pebwindkraft
<transactions><blockchain>
How do transactions in the blockchain work
Jeremy Fisher
# How do transactions in the blockchain work

(Asked by: username_0 on 2018-01-20)

I'm trying to go through the whitepaper to get a better understanding of bitcoin but I don't understand the block and subsequent blockchain model to create a transaction. The problems that bitcoin seems like it is trying to address is verifying if person A actually has the money to send to person B, and ensuring person B can't alter the amount person A sends.

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

I get that if A is trying to send money to B, A should sign the transaction with his private key as B wants to ensure A is who is sending the money. What I don't understand is the need for the hashing of B's public key and the previous transaction, and what exactly is being verified/signed.

I read a bit about the problem of "double-spending" but I don't think I understand it entirely because I don't see how the above solves it. Double-spending as I understand it is A giving money to one person, then making the transaction seem like it didn't happen or is invalid in order to spend the same money to someone else.

If transaction i - 1 is being hashed in transaction i, that means only transaction i - 1 is known. It says nothing about transaction i - 2, where the same money that is being spent in transaction i could have already been spent. It doesn't seem like transaction i - 1 or i keeps a list of all previous transactions, so there's no way of verifying where the buyer in i actually has the money.

What is the purpose of hashing the recipients public key and the previous transaction, and what is being verified in the picture above

**Tags:** transactions, blockchain

> **Comments:**
> **username_1**: I provided an answer to a similiar question here: https://bitcoin.stackexchange.com/questions/69062/why-does-bitcoin-uses-a-script-language/69077#69077  

---

## 1 answers

### Answer by username_2 on 2018-01-20. Score: 2

> What I don't understand is the need for the hashing of B's public key

Hashing the public key is done for two reasons. It is a cost saving measure as it reduces the size of A's transaction. It also protects the actual public key so that, if Elliptic Curve Cryptography is broken, the private key cannot be reversed from the public key because the public key is not known until it is used in an input to a transaction.

> and the previous transaction,

Including the hashing of the previous transactions lets a transaction refer to the transactions it is spending from so that you can verify whether the money is legitimate.

> and what exactly is being verified/signed.

The message that is signed is the transaction (the one that is being created) itself. Of course it does not contain the signatures, but it contains everything else - the transactions being spent from and the outputs being created. This protects the other parts of the transaction from being modified by people not authorized to spend the money.

> If transaction i - 1 is being hashed in transaction i, that means only transaction i - 1 is known. It says nothing about transaction i - 2, where the same money that is being spent in transaction i could have already been spent. It doesn't seem like transaction i - 1 or i keeps a list of all previous transactions, so there's no way of verifying where the buyer in i actually has the money.

Transaction `i - 1` contains the hash of transaction `i - 2`, which contains the hash of `i - 3`, and so on and so forth until you reach transaction `i - i` (the "first" transaction) which is a special transaction known as a coinbase. This is a coin generation transaction. Thus by following the entire chain of transactions backwards, you can verify if the money actually exists.


---

