<p>Sure, the protocol could have been designed that way.</p>

<p>The benefit would be that a block would be slightly smaller, since it only needs to contain a single address, rather than a full coinbase transaction.</p>

<p>However, a benefit of the current system is that miners have the flexibility to pay out their coinbase transaction in some other way than sending it all to a single address.  For example, a pool can distribute the coinbase transaction directly to its members in proportion to the amount of work they have done.  This removes the need for the pool manager to hold those funds, even temporarily, and gives the members some additional assurance against fraud by the manager.  It also lets miners take advantage of more sophisticated transaction types, such as multisig, segwit, etc.</p>

<p>The current system also means that coinbase transactions are handled the same as other transactions, using the same code; the only difference is that the inputs need not be checked.  Under your proposal, there would need to be special code to create the transaction, which would be another possible source of bugs and increase the "attack surface".</p>

<p>On balance, I think the current way is better.</p>

CC BY-SA 4.0
2020-01-03T00:20:28.193Z
2020-01-03T00:20:28.193Z
Nate Eldredge
<p>It's pointless to separate mining reward from transaction selection. Mining rewards and mining in general were the solution Satoshi Nakamoto gave to the very problem of transaction selection.</p>

<p>For example: </p>

<p>Alice mines a block A and gets her reward of 50 BTC, but it contains no transactions yet. So, 100 other nodes create 100 new different blocks with the transactions that will be related to the block A. What of those 100 blocks is the one you should consider the valid? You don't know, no until someone selects one of them and do the proof of work, creating a new block, B.</p>

<p>In the end you recreated the original Bitcoin solution, but with more indirections and network bandwidth usage. </p>

CC BY-SA 3.0
2018-02-16T13:56:46.053Z
2018-02-16T14:02:37.607Z
2018-02-16T14:02:37.607Z
Osias Jota
<p>AFAIK when a miner succeeds in creating a block, he puts a special transaction (coinbase) in it which spends no input and sends a fixed amount of BTC to an address he can arbitrarily specify.</p>

<p>Instead of doing so, can we do the following: Miner simply puts an address in the block header. When he succeeds in creating the block, all nodes that receive this block create the coinbase transaction -which spends no input and sends the fixed amount to the address in header- in their UTXO pool. </p>

<p>Would that work? </p>

CC BY-SA 3.0
2018-02-15T14:23:01.480Z
Why to make that change? What's the difference?
Osias Jota
CC BY-SA 3.0
2018-02-15T14:23:46.413Z
Curiosity. Don't think it is any better than current model in any way. Just curious if it's feasible or not.
SpiderRico
CC BY-SA 3.0
2018-02-15T14:31:35.083Z
No, I mean what's the rationale behind it? To separate mining work from transaction selection?
Osias Jota
<mining-theory><mining-reward><coinbase-transaction>
A different way to create coinbase transaction
SpiderRico
# A different way to create coinbase transaction

(Asked by: username_0 on 2018-02-15)

AFAIK when a miner succeeds in creating a block, he puts a special transaction (coinbase) in it which spends no input and sends a fixed amount of BTC to an address he can arbitrarily specify.

Instead of doing so, can we do the following: Miner simply puts an address in the block header. When he succeeds in creating the block, all nodes that receive this block create the coinbase transaction -which spends no input and sends the fixed amount to the address in header- in their UTXO pool.

Would that work?

**Tags:** mining-theory, mining-reward, coinbase-transaction

> **Comments:**
> **username_1**: Why to make that change? What's the difference?  
> **username_0**: Curiosity. Don't think it is any better than current model in any way. Just curious if it's feasible or not.  
> **username_1**: No, I mean what's the rationale behind it? To separate mining work from transaction selection?  

---

## 2 answers

### Answer by username_2 on 2020-01-03. Score: 2 | Accepted answer

Sure, the protocol could have been designed that way.

The benefit would be that a block would be slightly smaller, since it only needs to contain a single address, rather than a full coinbase transaction.

However, a benefit of the current system is that miners have the flexibility to pay out their coinbase transaction in some other way than sending it all to a single address. For example, a pool can distribute the coinbase transaction directly to its members in proportion to the amount of work they have done. This removes the need for the pool manager to hold those funds, even temporarily, and gives the members some additional assurance against fraud by the manager. It also lets miners take advantage of more sophisticated transaction types, such as multisig, segwit, etc.

The current system also means that coinbase transactions are handled the same as other transactions, using the same code; the only difference is that the inputs need not be checked. Under your proposal, there would need to be special code to create the transaction, which would be another possible source of bugs and increase the "attack surface".

On balance, I think the current way is better.


---

### Answer by username_1 on 2018-02-16. Score: 0

It's pointless to separate mining reward from transaction selection. Mining rewards and mining in general were the solution Satoshi Nakamoto gave to the very problem of transaction selection.

For example:

Alice mines a block A and gets her reward of 50 BTC, but it contains no transactions yet. So, 100 other nodes create 100 new different blocks with the transactions that will be related to the block A. What of those 100 blocks is the one you should consider the valid? You don't know, no until someone selects one of them and do the proof of work, creating a new block, B.

In the end you recreated the original Bitcoin solution, but with more indirections and network bandwidth usage.


---

