<p>No, that is not how transactions work.</p>

<p>First of all, transactions are not strings but rather blobs of binary data.</p>

<p>Secondly, the transaction hash that is included in the inputs of a transaction is not an encoding of the previous transaction but rather an identifier. Since sha256d is a secure hash (meaning that there will be a unique hash for basically all inputs), each sha256d hash uniquely identifies the transaction which it is the hash of. This is why transaction hashes are referred to as transaction ids (txids). A node, when it indexes the blockchain, can store in its database the transaction id as a key and the transaction itself as the value. This means that once the node needs the previous transaction for an input, it can easily use the given txid to lookup the transaction in its database and pull the necessary data.</p>

CC BY-SA 3.0
2017-06-16T06:56:47.007Z
Hi Andrew, agreed that transactions are blobs of binary data. My question is  how does anyone identify the content from its hash. You mentioned that transaction and the corresponding hash (txnid) are stored in a database. Where is this database? How do I access it? Who puts the mapping data in this db and as a part of what operation? My source of transaction knowledge is http://royalforkblog.github.io/2014/11/20/txn-demo/. Please point me to the correct source if this link doesn't seem to be talking sense.
anurag srivastava
CC BY-SA 3.0
2017-06-16T07:02:47.507Z
The db is implementation specific. Ideally, when you implement a full node, you also use a db to keep track of where data is stored in the blockchain itself. For example, Bitcoin Core creates a database where the outpoint (concatenation of txid and output index) is the key and the value is the output (output value and scriptPubKey). But this varies across implementations. Core used to do use the txid as the key and the transaction as the value. The naive way to lookup the previous transaction is to walk through the entire blockchain and calculate each txid until you find one that matches.
Ava Chow
CC BY-SA 3.0
2017-06-16T06:38:46.300Z
2017-06-16T06:38:46.300Z
Ava Chow
<p>When a transaction is broadcasted to the network, the transaction string contains the little-endian of SHA256(SHA256(X)) where X is the transaction string of input transaction.</p>

<p>Now, since SHA is irreversible, miners will not be able to get the full transaction string (X). So, how do miners verify the authencity of the input? How do they know that the mentioned input transaction actually had 'n' outputs? I am looking to understand the alogirthm behind this.</p>

<transaction-verification><algorithms>
How do miners decode the input transaction?
anurag srivastava
# How do miners decode the input transaction?

(Asked by: username_0 on 2017-06-16)

When a transaction is broadcasted to the network, the transaction string contains the little-endian of SHA256(SHA256(X)) where X is the transaction string of input transaction.

Now, since SHA is irreversible, miners will not be able to get the full transaction string (X). So, how do miners verify the authencity of the input? How do they know that the mentioned input transaction actually had 'n' outputs? I am looking to understand the alogirthm behind this.

**Tags:** transaction-verification, algorithms


---

## 1 answers

### Answer by username_1 on 2017-06-16. Score: 1 | Accepted answer

No, that is not how transactions work.

First of all, transactions are not strings but rather blobs of binary data.

Secondly, the transaction hash that is included in the inputs of a transaction is not an encoding of the previous transaction but rather an identifier. Since sha256d is a secure hash (meaning that there will be a unique hash for basically all inputs), each sha256d hash uniquely identifies the transaction which it is the hash of. This is why transaction hashes are referred to as transaction ids (txids). A node, when it indexes the blockchain, can store in its database the transaction id as a key and the transaction itself as the value. This means that once the node needs the previous transaction for an input, it can easily use the given txid to lookup the transaction in its database and pull the necessary data.

> **Comments:**
> **username_0**: Hi Andrew, agreed that transactions are blobs of binary data. My question is  how does anyone identify the content from its hash. You mentioned that transaction and the corresponding hash (txnid) are stored in a database. Where is this database? How do I access it? Who puts the mapping data in this db and as a part of what operation? My source of transaction knowledge is http://royalforkblog.github.io/2014/11/20/txn-demo/. Please point me to the correct source if this link doesn't seem to be talking sense.  
> **username_1**: The db is implementation specific. Ideally, when you implement a full node, you also use a db to keep track of where data is stored in the blockchain itself. For example, Bitcoin Core creates a database where the outpoint (concatenation of txid and output index) is the key and the value is the output (output value and scriptPubKey). But this varies across implementations. Core used to do use the txid as the key and the transaction as the value. The naive way to lookup the previous transaction is to walk through the entire blockchain and calculate each txid until you find one that matches.  

---

