<p>There are some misunderstandings here. First, transactions are hashed in several ways for different purposes, but actually they are kept in the original in the blockchain: As you said, this is needed to check the blockchain later, or to provide the information to other participants for them to catch up with the network.</p>

<p>So, when and to what purpose are they hashed, then?</p>

<h2>Transaction Identifier (txid)</h2>

<p>Standard transactions range in size from roughly 192 bytes to 100,000 bytes, although the <a href="https://bitcoin.stackexchange.com/a/54682/5406">smallest possible transaction is 61
   bytes</a>, and the <a href="https://bitcoin.stackexchange.com/q/54264/5406">largest one ever seen was 999,657 bytes</a>. Anyway, I think we can agree that some of them can be unwieldy to send around in full, just to reference them. ;)</p>

<p>This is where transaction IDs come in. The transaction ID is the digest of performing the SHA-256 hashing function twice on the serialized transaction. The resulting digest or hash is always 256 bits (hence the name), which can be represented with 32 bytes. Using the txid to reference transactions is obviously much less bandwidth intensive which is why this is how peers exchange information about transactions: when a peer learns about a new transaction, this will be in form of an <code>INVENTORY</code> message that presents him a list of txids, to which the node may respond by requesting the unseen transactions with the corresponding txids.</p>

<h2>Merkle tree</h2>

<p>Transactions in a block have a fixed order. This can be used to create a <a href="https://bitcoin.stackexchange.com/q/10479/5406">Merkle tree</a> from the transactions. Merkle trees are useful in that they allow lightweight nodes to confirm the <a href="https://bitcoin.stackexchange.com/q/50674/5406">membership of a transaction in a block</a> without having full knowledge of the block's content. The Merkle tree is created by hashing transactions pairwise iteratively until only a single hash results. This <em>Merkle root</em> can be used to represent all transactions in a block and prevents anyone from changing the block's content.</p>

<h2>Proof of work</h2>

<p>A third  application of hashing in Bitcoin is the consensus mechanism 'proof of work'. Bitcoin's central innovation is using the <a href="https://bitcoin.stackexchange.com/q/12427/5406">blockchain to create consensus about the order of transactions in the system</a>. To that end, miners collect unconfirmed transactions into block templates for which they then evaluate whether they resolve to a <a href="https://bitcoin.stackexchange.com/q/148/5406">valid block</a>. These block templates consist of a block header (which among other information collects the aforementioned Merkle root) that is subjected to a <a href="https://bitcoin.stackexchange.com/q/8031/5406">doubly applied SHA-256 function</a>. If the result surpasses the <a href="https://bitcoin.stackexchange.com/q/855/5406">difficulty</a>, a new valid block has been found.</p>

<h2>Sighashes</h2>

<p>We need to make sure that only the owner of funds may spend them. This is solved by the owner signing a transaction with the corresponding private key for each input that they are spending. However, there's another application for hashes in there as well (hat tip to Pieter for pointing it out): for each input a "signature hash" is produced which is a digest of all inputs and outputs of the transaction. As this is what the sender signs, they not only authenticate themselves as the rightful owner, but also commit the signature to exactly this transaction. Thus the signature is useless even to spend another transaction output from the same address, and it is impossible for third parties to redirect payments.</p>

<h2>Addresses</h2>

<p>While private key and public key together make a point on an ECDSA curve, the address is actually also derived by hashing: It is a RIPEMD-160 hash of the public key. This allows the public key to remain unknown until received money is spent from an address for the first time.</p>

<h2>The point of hashing</h2>

<p>As we can see, while addresses are indeed kept in full in the blockchain, hashing allows us to: </p>

<ul>
<li>Save bandwidth in transaction relay</li>
<li>Verify transaction confirmations without knowing full blocks</li>
<li>Limit block discovery and introduce digital scarcity</li>
<li>Protect transactions from being altered by third parties</li>
<li>Protect sensible information, while proving our possession of it</li>
</ul>

CC BY-SA 4.0
2017-07-11T06:25:45.353Z
2018-06-26T21:45:11.017Z
2018-06-26T21:45:11.017Z
Murch
<p>I think you need to do a little more reading.  </p>

<p>What you're suggesting is like saying "Hey, I know what my current balance in my checking account is, so why not just throw away all the previous history".</p>

<p>That may be fine, until you need to figure out whether or not someone cashed a check 6 months ago.</p>

<p>Hashing is cryptographically signing the transaction, it's not reducing the transaction to ONLY a hash.  It's the transaction itself, along with the previous transactions hash, hashed together to form a new hash, which is verified by comparing the previous hash and the transaction.</p>

CC BY-SA 3.0
2017-07-05T08:39:14.043Z
How for example can I verify a transaction if it's hashed? @Erik Funkenbusch
adam eliezerov
CC BY-SA 3.0
2017-07-05T08:49:49.520Z
As I understand, we use hashing for indexing purposes. Hash of transaction is just an ID used an index for locating the complete transaction.
sanket1729
CC BY-SA 3.0
2017-07-05T10:41:48.200Z
@sanket1729 - hashing can be used for many purposes.  For example, they are often used in Proof of Work algorithms.  However, blockchains explicitly use hashing to cryptographically sign each entry, not for indexing purposes (although they can also be used for indexing, that's not its main purpose).
Mr.Nobody
CC BY-SA 3.0
2017-07-05T10:44:15.567Z
@adameliezerov - you don't verify it, generally, unless you're planning to write your own wallet software.  You can use tools like chain explorers and the like to find transactions.  But you have to get pretty low level to validate the hashing yourself.  If that's what you want to do, then I strongly suggest getting any of the numerous blockchain books out there.
Mr.Nobody
CC BY-SA 3.0
2017-07-05T13:24:41.033Z
I understand the uses of hashing. I meant specific to the case of transactions. It is just an unique identifier used for indexing.
sanket1729
CC BY-SA 3.0
2017-07-05T08:30:33.130Z
2017-07-05T08:30:33.130Z
Mr.Nobody
<p>In the blockchain people keep saying that all of the transactions are listed. Then why are they hashed? What's the point of hashing them if you can't check the blockchain afterwards.</p>

CC BY-SA 3.0
2017-07-11T00:31:17.427Z
Possible duplicate of [How are transaction hashes calculated?](https://bitcoin.stackexchange.com/questions/2859/how-are-transaction-hashes-calculated)
rny
CC BY-SA 3.0
2017-07-11T05:39:50.080Z
I've voted 'Leave open' as the proposed duplicate doesn't seem to be a related topic. This one here appears to ask what the benefit of hashing information is, while the other one is seeking instructions on how to perform the hashing.
Murch
<transactions><blockchain><bitcoin-core>
What is the point of keeping transactions if they are hashed?
adam eliezerov
# What is the point of keeping transactions if they are hashed?

(Asked by: username_0 on 2017-07-05)

In the blockchain people keep saying that all of the transactions are listed. Then why are they hashed? What's the point of hashing them if you can't check the blockchain afterwards.

**Tags:** transactions, blockchain, bitcoin-core

> **Comments:**
> **username_1**: Possible duplicate of [How are transaction hashes calculated?](https://bitcoin.stackexchange.com/questions/2859/how-are-transaction-hashes-calculated)  
> **username_2**: I've voted 'Leave open' as the proposed duplicate doesn't seem to be a related topic. This one here appears to ask what the benefit of hashing information is, while the other one is seeking instructions on how to perform the hashing.  

---

## 2 answers

### Answer by username_2 on 2017-07-11. Score: 7

There are some misunderstandings here. First, transactions are hashed in several ways for different purposes, but actually they are kept in the original in the blockchain: As you said, this is needed to check the blockchain later, or to provide the information to other participants for them to catch up with the network.

So, when and to what purpose are they hashed, then?

## Transaction Identifier (txid)

Standard transactions range in size from roughly 192 bytes to 100,000 bytes, although the [smallest possible transaction is 61
bytes](https://bitcoin.stackexchange.com/a/54682/5406), and the [largest one ever seen was 999,657 bytes](https://bitcoin.stackexchange.com/q/54264/5406). Anyway, I think we can agree that some of them can be unwieldy to send around in full, just to reference them. ;)

This is where transaction IDs come in. The transaction ID is the digest of performing the SHA-256 hashing function twice on the serialized transaction. The resulting digest or hash is always 256 bits (hence the name), which can be represented with 32 bytes. Using the txid to reference transactions is obviously much less bandwidth intensive which is why this is how peers exchange information about transactions: when a peer learns about a new transaction, this will be in form of an `INVENTORY` message that presents him a list of txids, to which the node may respond by requesting the unseen transactions with the corresponding txids.

## Merkle tree

Transactions in a block have a fixed order. This can be used to create a [Merkle tree](https://bitcoin.stackexchange.com/q/10479/5406) from the transactions. Merkle trees are useful in that they allow lightweight nodes to confirm the [membership of a transaction in a block](https://bitcoin.stackexchange.com/q/50674/5406) without having full knowledge of the block's content. The Merkle tree is created by hashing transactions pairwise iteratively until only a single hash results. This *Merkle root* can be used to represent all transactions in a block and prevents anyone from changing the block's content.

## Proof of work

A third application of hashing in Bitcoin is the consensus mechanism 'proof of work'. Bitcoin's central innovation is using the [blockchain to create consensus about the order of transactions in the system](https://bitcoin.stackexchange.com/q/12427/5406). To that end, miners collect unconfirmed transactions into block templates for which they then evaluate whether they resolve to a [valid block](https://bitcoin.stackexchange.com/q/148/5406). These block templates consist of a block header (which among other information collects the aforementioned Merkle root) that is subjected to a [doubly applied SHA-256 function](https://bitcoin.stackexchange.com/q/8031/5406). If the result surpasses the [difficulty](https://bitcoin.stackexchange.com/q/855/5406), a new valid block has been found.

## Sighashes

We need to make sure that only the owner of funds may spend them. This is solved by the owner signing a transaction with the corresponding private key for each input that they are spending. However, there's another application for hashes in there as well (hat tip to Pieter for pointing it out): for each input a "signature hash" is produced which is a digest of all inputs and outputs of the transaction. As this is what the sender signs, they not only authenticate themselves as the rightful owner, but also commit the signature to exactly this transaction. Thus the signature is useless even to spend another transaction output from the same address, and it is impossible for third parties to redirect payments.

## Addresses

While private key and public key together make a point on an ECDSA curve, the address is actually also derived by hashing: It is a RIPEMD-160 hash of the public key. This allows the public key to remain unknown until received money is spent from an address for the first time.

## The point of hashing

As we can see, while addresses are indeed kept in full in the blockchain, hashing allows us to:

* Save bandwidth in transaction relay
* Verify transaction confirmations without knowing full blocks
* Limit block discovery and introduce digital scarcity
* Protect transactions from being altered by third parties
* Protect sensible information, while proving our possession of it


---

### Answer by username_3 on 2017-07-05. Score: 0

I think you need to do a little more reading.

What you're suggesting is like saying "Hey, I know what my current balance in my checking account is, so why not just throw away all the previous history".

That may be fine, until you need to figure out whether or not someone cashed a check 6 months ago.

Hashing is cryptographically signing the transaction, it's not reducing the transaction to ONLY a hash. It's the transaction itself, along with the previous transactions hash, hashed together to form a new hash, which is verified by comparing the previous hash and the transaction.

> **Comments:**
> **username_0**: How for example can I verify a transaction if it's hashed? @Erik Funkenbusch  
> **username_4**: As I understand, we use hashing for indexing purposes. Hash of transaction is just an ID used an index for locating the complete transaction.  
> **username_3**: @username_4 - hashing can be used for many purposes.  For example, they are often used in Proof of Work algorithms.  However, blockchains explicitly use hashing to cryptographically sign each entry, not for indexing purposes (although they can also be used for indexing, that's not its main purpose).  
> **username_3**: @username_0 - you don't verify it, generally, unless you're planning to write your own wallet software.  You can use tools like chain explorers and the like to find transactions.  But you have to get pretty low level to validate the hashing yourself.  If that's what you want to do, then I strongly suggest getting any of the numerous blockchain books out there.  
> **username_4**: I understand the uses of hashing. I meant specific to the case of transactions. It is just an unique identifier used for indexing.  

---

