<p>You have the idea wrong: each transaction doesn’t need to reference the transaction that comes before it in a certain block, it needs to reference the transaction that created the outputs it is now spending. This ‘chain of transactions’ refers to following the history of certain outputs through time, not just the arbitrary transaction ordering within a block. </p>

<p>So the second transaction in a block (first non-coinbase transaction) will reference the transaction(s) that created the outputs it is spending. It will not reference the coinbase transaction.</p>

CC BY-SA 4.0
2020-01-05T22:15:42.240Z
Thanks! I figured it out using the previous answer and digging in block explorers, but now I have confirmation that my conclusions were right.
Jacob
CC BY-SA 4.0
2020-01-05T21:49:51.480Z
2020-01-05T22:15:16.193Z
2020-01-05T22:15:16.193Z
chytrik
<p>The coinbase transaction is created when the miner creates the template for the block which they attempt to mine. Unlike regular transactions, it does not have regular inputs. The miner simply specifies the outputs to spend the coins, where the sum of the output amounts must be less than or equal to the total amount of fees in the block plus the subsidy. The coinbase is always positioned as the first transaction in the block.</p>

<p>The coinbase transaction has the same structure as regular transactions, but for each <code>txIn</code> it has, any <code>txOutPoint</code> should just have a zero value (there is no previous <code>txid</code> to refer to). The <code>scriptSig</code> can contain arbitrary information, as miners do not need to sign anything. Miners add information to the <code>scriptSig</code> such as their name, or additional source of entropy for mining. Additionally, some consensus rules which have been soft forked into Bitcoin require that the <code>scriptSig</code> contains the block height and a merkle root of <code>wtxids</code> (for segwit).</p>

<p>The process is roughly like this:</p>

<ul>
<li><p>Miner creates a coinbase template which spends some not yet known amount of money to one or more outputs.</p></li>
<li><p>Miner sorts transactions in the mempool by highest paying fee per weight unit (per byte in original), and picks some number of transactions such that their serialized size plus the serialized size of the coinbase is not greater than the block size limit.</p></li>
<li><p>They sum all fees paid in the included transactions and add it to the subsidy to create an amount that the block is worth.</p></li>
<li><p>They update the coinbase template with <em>at most</em> this amount being spent (it is possible to not claim the full amount of fees or the subsidy, but overclaiming produces an invalid block).</p></li>
<li><p>The miner computes the merkle root of all of these transactions <code>txids</code> (where the <code>txid</code> is the double-SHA of the serialized transaction), taken as a binary tree ordered by the position the transaction is serialized in the block. The coinbase is explicitly the first transaction.</p></li>
<li><p>The miner inserts this merkle root into a block header with the 5 other required fields (version, prevBlockHash, target, nonce and timestamp) and serializes it.</p></li>
<li><p>The miner repeatedly attempts double-SHA256 on the block header until the resulting digest, when taken as an integer, is numerically less than or equal to what is required by the <code>target</code> in the header. The miner modifies the <code>nonce</code>, or occasionally <code>timestamp</code> for each double-SHA256 attempt so that a different digest is produced, but the other fields of the header remain unchanged.</p></li>
<li><p>At some regular interval, if the miner has not yet found a successful hash, or if a new block is received, they compute a new template by starting this process from the beginning, which can take new information and may provide a higher reward. They discard the previous template they were working on. If a new block was found, any transactions which were included in the block are dropped from the mempool.</p></li>
</ul>

CC BY-SA 4.0
2020-01-05T23:02:30.450Z
Thank you, this was informative and helped me find the exact solution myself.
Jacob
CC BY-SA 4.0
2020-01-05T17:52:32.563Z
2020-01-05T17:57:53.820Z
2020-01-05T17:57:53.820Z
Mark H
<p>I'm making a simple demonstrator program, pretty much a simplified bitcoin clone based mostly on the original whitepaper.</p>

<p><strong><em>Please bear with me, because I haven't found a way to describe the problem more concisely.</em></strong></p>

<p>My blockchain is based on <a href="https://www.ibm.com/developerworks/cloud/library/cl-develop-blockchain-app-in-python/index.html" rel="nofollow noreferrer">this tutorial.</a></p>

<p>However, it completely ignores the transaction part, so I've based the transactions on this part of the original documentation:
<a href="https://i.sstatic.net/TRUHB.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/TRUHB.png" alt="A section of the original bitcoin whitepaper"></a>
As specified here, my transactions consist of the next owner's public key and the signature of last transaction signed by the previous owner. I also added the amount being transferred (I'm not using the in/out system for the sake of simplicity).</p>

<p>Since each transaction needs a hash of a previous one, I also created a coinbase transaction. It only contains  the mined amount and the miner's public key (to know whom to give the mined amount). This allows for the first regular transaction in a block to have a previous transaction to hash and sign.</p>

<p><em>However, that also means that the miner key has to be specified before the first transaction is made</em> (since all future transactions require that the coinbase's hash stays the same). 
At the same time, it does <em>not</em> make sense to specify the miner before they have mined a block.
In other words, this would require the transaction user to know a priori who will mine the block with their transaction.</p>

<p>My assumption so far was that a coinbase transaction is added to the unconfirmed transaction list after the previous block is mined, and new transactions refer to it. Then the whole list is put into a block which is then mined. However that assumption led to the aforementioned problems.</p>

<p>The only possible solution which I could come up with is using the last transaction hash from the previous block to sign a new transaction, effectively bypassing the coinbase transaction. But that doesn't seem right to me.</p>

<p><strong>Please, tell me if I'm missing something, or got the wrong idea somewhere.</strong></p>

<p><strong>Where and when should the coinbase transaction(including the miner key) be added?</strong></p>

<p><strong>Or should I scrap that idea completely and use the "bypass" method?</strong></p>

<p>PS. I've already tried searching various wikis and questions, but nothing realy gave me a clear solution to this. 
Especially, <a href="https://bitcoin.stackexchange.com/questions/85903/when-does-miner-insert-the-coinbase-transaction">this answer</a> is too vague</p>

<unconfirmed-transactions><coinbase-transaction>
Where and when should the coinbase transaction(including the miner key) be added?
Jacob
# Where and when should the coinbase transaction(including the miner key) be added?

(Asked by: username_0 on 2020-01-05)

I'm making a simple demonstrator program, pretty much a simplified bitcoin clone based mostly on the original whitepaper.

***Please bear with me, because I haven't found a way to describe the problem more concisely.***

My blockchain is based on [this tutorial.](https://www.ibm.com/developerworks/cloud/library/cl-develop-blockchain-app-in-python/index.html)

However, it completely ignores the transaction part, so I've based the transactions on this part of the original documentation:
[![A section of the original bitcoin whitepaper](https://i.sstatic.net/TRUHB.png)](https://i.sstatic.net/TRUHB.png)
As specified here, my transactions consist of the next owner's public key and the signature of last transaction signed by the previous owner. I also added the amount being transferred (I'm not using the in/out system for the sake of simplicity).

Since each transaction needs a hash of a previous one, I also created a coinbase transaction. It only contains the mined amount and the miner's public key (to know whom to give the mined amount). This allows for the first regular transaction in a block to have a previous transaction to hash and sign.

*However, that also means that the miner key has to be specified before the first transaction is made* (since all future transactions require that the coinbase's hash stays the same).
At the same time, it does *not* make sense to specify the miner before they have mined a block.
In other words, this would require the transaction user to know a priori who will mine the block with their transaction.

My assumption so far was that a coinbase transaction is added to the unconfirmed transaction list after the previous block is mined, and new transactions refer to it. Then the whole list is put into a block which is then mined. However that assumption led to the aforementioned problems.

The only possible solution which I could come up with is using the last transaction hash from the previous block to sign a new transaction, effectively bypassing the coinbase transaction. But that doesn't seem right to me.

**Please, tell me if I'm missing something, or got the wrong idea somewhere.**

**Where and when should the coinbase transaction(including the miner key) be added?**

**Or should I scrap that idea completely and use the "bypass" method?**

PS. I've already tried searching various wikis and questions, but nothing realy gave me a clear solution to this.
Especially, [this answer](https://bitcoin.stackexchange.com/questions/85903/when-does-miner-insert-the-coinbase-transaction) is too vague

**Tags:** unconfirmed-transactions, coinbase-transaction


---

## 2 answers

### Answer by username_1 on 2020-01-05. Score: 0 | Accepted answer

You have the idea wrong: each transaction doesn’t need to reference the transaction that comes before it in a certain block, it needs to reference the transaction that created the outputs it is now spending. This ‘chain of transactions’ refers to following the history of certain outputs through time, not just the arbitrary transaction ordering within a block.

So the second transaction in a block (first non-coinbase transaction) will reference the transaction(s) that created the outputs it is spending. It will not reference the coinbase transaction.

> **Comments:**
> **username_0**: Thanks! I figured it out using the previous answer and digging in block explorers, but now I have confirmation that my conclusions were right.  

---

### Answer by username_2 on 2020-01-05. Score: 1

The coinbase transaction is created when the miner creates the template for the block which they attempt to mine. Unlike regular transactions, it does not have regular inputs. The miner simply specifies the outputs to spend the coins, where the sum of the output amounts must be less than or equal to the total amount of fees in the block plus the subsidy. The coinbase is always positioned as the first transaction in the block.

The coinbase transaction has the same structure as regular transactions, but for each `txIn` it has, any `txOutPoint` should just have a zero value (there is no previous `txid` to refer to). The `scriptSig` can contain arbitrary information, as miners do not need to sign anything. Miners add information to the `scriptSig` such as their name, or additional source of entropy for mining. Additionally, some consensus rules which have been soft forked into Bitcoin require that the `scriptSig` contains the block height and a merkle root of `wtxids` (for segwit).

The process is roughly like this:

* Miner creates a coinbase template which spends some not yet known amount of money to one or more outputs.
* Miner sorts transactions in the mempool by highest paying fee per weight unit (per byte in original), and picks some number of transactions such that their serialized size plus the serialized size of the coinbase is not greater than the block size limit.
* They sum all fees paid in the included transactions and add it to the subsidy to create an amount that the block is worth.
* They update the coinbase template with *at most* this amount being spent (it is possible to not claim the full amount of fees or the subsidy, but overclaiming produces an invalid block).
* The miner computes the merkle root of all of these transactions `txids` (where the `txid` is the double-SHA of the serialized transaction), taken as a binary tree ordered by the position the transaction is serialized in the block. The coinbase is explicitly the first transaction.
* The miner inserts this merkle root into a block header with the 5 other required fields (version, prevBlockHash, target, nonce and timestamp) and serializes it.
* The miner repeatedly attempts double-SHA256 on the block header until the resulting digest, when taken as an integer, is numerically less than or equal to what is required by the `target` in the header. The miner modifies the `nonce`, or occasionally `timestamp` for each double-SHA256 attempt so that a different digest is produced, but the other fields of the header remain unchanged.
* At some regular interval, if the miner has not yet found a successful hash, or if a new block is received, they compute a new template by starting this process from the beginning, which can take new information and may provide a higher reward. They discard the previous template they were working on. If a new block was found, any transactions which were included in the block are dropped from the mempool.

> **Comments:**
> **username_0**: Thank you, this was informative and helped me find the exact solution myself.  

---

