<blockquote>
  <p>Isn't each transaction dependent on a hash of the previous transaction? </p>
</blockquote>

<p>Yes and no. </p>

<p>Yes, in that each transaction must be created using valid inputs (ie, referencing a valid UTXO to be consumed as an input). No, in that transactions are not 'dependant' on the previous transaction's hash in the same way that blocks are 'dependant' on the previous block's hash. </p>

<p>For blocks, the hash has an extra level of importance, in that the hash of the block must be a valid proof-of-work on the network. Each block must have a valid hash, and also reference a valid previous block. For transactions, this extra layer of 'valid proof of work' is not required. </p>

<p>(Note that as Ugam mentioned, coinbase transactions are special, in that they do not consumer inputs)</p>

<blockquote>
  <p>Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block?</p>
</blockquote>

<p>When a UTXO is consumed as an input, those coins must be spent entirely, by the creation of new UTXOs as outputs. The sum of the outputs will be slightly less than the sum of the inputs (this difference will become part of the miner's fee for the block), so any excess of coins not specified in a new UTXO will simply be claimed as fees (added to the output of the coinbase transaction).</p>

<blockquote>
  <p>Everything I've seen on StackExchange about this refers to hashing in blocks, which makes sense to me on the level of blocks, but then I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.</p>
</blockquote>

<p>Right. A transaction is hashed to obtain the transaction ID (txID / wtxID), but this hash is not subject to the stipulations of being a valid proof-of-work. </p>

<p>There is one situation in which ordering within a block matters: suppose you create a <code>transaction-1</code> that makes <code>UTXO-1</code>, and then create a <code>transaction-2</code> that spends <code>UTXO-1</code> and creates <code>UTXO-2</code>. If you wanted to include both of those transactions in the same block, then <code>transaction-1</code> would need to be included <em>before</em> <code>transaction-2</code>, otherwise <code>transaction-2</code> would be seen as invalid (and thus the whole block would become invalid). In this way, 'child transactions' must always come after their parents, if included in the same block. </p>

<p>Otherwise, the transactions included in a block do not have to be related to each other at all, there is no requirement like this. The only stipulation is that a transaction must reference a valid UTXO (and hence the rule about ordering transactions that I mentioned above). </p>

CC BY-SA 4.0
2019-07-13T20:06:54.523Z
2019-07-13T20:06:54.523Z
chytrik
<blockquote>
  <p>Isn't each transaction dependent on a hash of the previous transaction?</p>
</blockquote>

<p>It is correct for most transactions apart from the coinbase transaction. The coinbase transaction is one that mints new coins through the mining process and as such does not have a preceding transaction it can reference.</p>

<blockquote>
  <p>Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block?</p>
</blockquote>

<p>There is no need for grouping all the transactions 'related to a coin' in a single block. Whenever you want to spend some coins with the keys you control, you would simply reference the transaction outpoint (the <code>txid</code> and the output number) and provide a valid signature that satisfies the unlocking condition. Bitcoin full nodes maintain a complete set of unspent transaction outputs (UTXOs) data that they build by going through all the transactions in the blockchain when that node is bootstrapped. This data set contains the information of the <code>txid</code>s and output numbers, which allows the full nodes to verify your unlocking condition without going back to the block in which this transaction was included. When a new transaction is created, the the outpoints which are used in the transaction inputs are deleted from the UTXO set and the outputs of the transaction is added to the UTXO set.</p>

<blockquote>
  <p>As far I can tell this is not true, so by what mechanism are transactions for different coins grouped in the same block? How can transactions from unrelated coins be organized into a block?</p>
</blockquote>

<p>Coinbase transaction always comes first in a block. If a transaction (child) spends coins from another transaction (parent), and if both these transactions gets mined in a single block, then the parent must precede the child in terms of transaction ordering in the block. Apart from these two rules, miners can include transactions in any order.</p>

<blockquote>
  <p>I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.</p>
</blockquote>

<p>A transaction data is serialized and then hashed twice using SHA-256 which gives you the transaction id (txid). Given the randomness in SHA-256 one can be assured that a <code>txid</code> is a unique identifier of a transaction and can be referenced with only 32 bytes. When spending some coins you control, all you need to do is reference the <code>txid</code> and output number.</p>

CC BY-SA 4.0
2019-07-13T19:15:29.920Z
2019-07-13T19:22:39.820Z
2019-07-13T19:22:39.820Z
Ugam Kamat
<p>Isn't each transaction dependent on a hash of the previous transaction?  Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block?  As far I can tell this is not true, so by what mechanism are transactions for different coins grouped in the same block.  </p>

<p>Everything I've seen on StackExchange about this refers to hashing in blocks, which makes sense to me on the level of blocks, but then I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.</p>

<p>So I guess a different way to phrase this is how can transactions from unrelated coins be organized into a block?  Because as I previously mentioned, I thought that each transaction was dependent on a hash of a previous transaction.</p>

<transactions><block>
How can bitcoin transactions for the same coin belong in different blocks?
srlrs20020
# How can bitcoin transactions for the same coin belong in different blocks?

(Asked by: username_0 on 2019-07-13)

Isn't each transaction dependent on a hash of the previous transaction? Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block? As far I can tell this is not true, so by what mechanism are transactions for different coins grouped in the same block.

Everything I've seen on StackExchange about this refers to hashing in blocks, which makes sense to me on the level of blocks, but then I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.

So I guess a different way to phrase this is how can transactions from unrelated coins be organized into a block? Because as I previously mentioned, I thought that each transaction was dependent on a hash of a previous transaction.

**Tags:** transactions, block


---

## 2 answers

### Answer by username_1 on 2019-07-13. Score: 1 | Accepted answer

> Isn't each transaction dependent on a hash of the previous transaction?

Yes and no.

Yes, in that each transaction must be created using valid inputs (ie, referencing a valid UTXO to be consumed as an input). No, in that transactions are not 'dependant' on the previous transaction's hash in the same way that blocks are 'dependant' on the previous block's hash.

For blocks, the hash has an extra level of importance, in that the hash of the block must be a valid proof-of-work on the network. Each block must have a valid hash, and also reference a valid previous block. For transactions, this extra layer of 'valid proof of work' is not required.

(Note that as username_2 mentioned, coinbase transactions are special, in that they do not consumer inputs)

> Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block?

When a UTXO is consumed as an input, those coins must be spent entirely, by the creation of new UTXOs as outputs. The sum of the outputs will be slightly less than the sum of the inputs (this difference will become part of the miner's fee for the block), so any excess of coins not specified in a new UTXO will simply be claimed as fees (added to the output of the coinbase transaction).

> Everything I've seen on StackExchange about this refers to hashing in blocks, which makes sense to me on the level of blocks, but then I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.

Right. A transaction is hashed to obtain the transaction ID (txID / wtxID), but this hash is not subject to the stipulations of being a valid proof-of-work.

There is one situation in which ordering within a block matters: suppose you create a `transaction-1` that makes `UTXO-1`, and then create a `transaction-2` that spends `UTXO-1` and creates `UTXO-2`. If you wanted to include both of those transactions in the same block, then `transaction-1` would need to be included *before* `transaction-2`, otherwise `transaction-2` would be seen as invalid (and thus the whole block would become invalid). In this way, 'child transactions' must always come after their parents, if included in the same block.

Otherwise, the transactions included in a block do not have to be related to each other at all, there is no requirement like this. The only stipulation is that a transaction must reference a valid UTXO (and hence the rule about ordering transactions that I mentioned above).


---

### Answer by username_2 on 2019-07-13. Score: 0

> Isn't each transaction dependent on a hash of the previous transaction?

It is correct for most transactions apart from the coinbase transaction. The coinbase transaction is one that mints new coins through the mining process and as such does not have a preceding transaction it can reference.

> Wouldn't that mean all of the transactions for a particular coin would have to be grouped in the same block?

There is no need for grouping all the transactions 'related to a coin' in a single block. Whenever you want to spend some coins with the keys you control, you would simply reference the transaction outpoint (the `txid` and the output number) and provide a valid signature that satisfies the unlocking condition. Bitcoin full nodes maintain a complete set of unspent transaction outputs (UTXOs) data that they build by going through all the transactions in the blockchain when that node is bootstrapped. This data set contains the information of the `txid`s and output numbers, which allows the full nodes to verify your unlocking condition without going back to the block in which this transaction was included. When a new transaction is created, the the outpoints which are used in the transaction inputs are deleted from the UTXO set and the outputs of the transaction is added to the UTXO set.

> As far I can tell this is not true, so by what mechanism are transactions for different coins grouped in the same block? How can transactions from unrelated coins be organized into a block?

Coinbase transaction always comes first in a block. If a transaction (child) spends coins from another transaction (parent), and if both these transactions gets mined in a single block, then the parent must precede the child in terms of transaction ordering in the block. Apart from these two rules, miners can include transactions in any order.

> I don't understand the level of hashing of transactions since it seems transactions are not organized into blocks by coin.

A transaction data is serialized and then hashed twice using SHA-256 which gives you the transaction id (txid). Given the randomness in SHA-256 one can be assured that a `txid` is a unique identifier of a transaction and can be referenced with only 32 bytes. When spending some coins you control, all you need to do is reference the `txid` and output number.


---

