<p>The correct answer is: ask Satoshi.</p>

<p>My guessed answers to the questions you asked:</p>

<ol>
<li><p><strong>Why only one input?</strong> You can't predict when a particular coinbase transaction will make it into a successful block and you can't spend the output of a coinbase transaction for 100 blocks.  That means using a regular transaction is much superior for any normal spending.  If there's no normal case for adding inputs to a coinbase, maybe Satoshi thought it best to disallow inputs to prevent un-thought-of attacks.</p></li>
<li><p><strong>Why reference a null <a href="https://bitcoin.org/en/developer-reference#outpoint" rel="nofollow noreferrer">outpoint</a>?</strong> Using the same basic format as a regular transaction probably allowed code reuse.  If he had optimized the coinbase, we would've saved 36 bytes times 338,692 blocks (so far), or about 12 MB.  Not a big deal.</p></li>
<li><p><strong>Why limit coinbase size to 100 bytes?</strong> We know Satoshi used the coinbase to put a message in block 0.  Maybe a 100-byte limit was his attempt to prevent anyone else from using that same mechanism to add overlong messages.  This was probably quite smart: from the fairly early days through today, many miners add messages to all of their coinbases---we can only imagine how annoying and wasteful those messages would be if they weren't limited to 100 bytes.</p></li>
<li><p><strong>Why specify minimum coinbase size as 2 bytes?</strong> Highly speculative here, but maybe Satoshi foresaw the easy-duplication-of-coinbases described in <a href="https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki" rel="nofollow noreferrer">BIP30</a> and wanted to require people use something like the <a href="https://bitcoin.stackexchange.com/questions/32603/why-didnt-satoshi-make-the-nonce-space-larger/32618#32618">original extranonce</a> to help prevent accidental TXID collisions.</p></li>
</ol>

CC BY-SA 3.0
2015-01-12T18:59:35.540Z
About #1, can you think of any such un-thought-of attacks? Possibly related to the paying a miner to mine a re-org in a certain way? I don't know how that would work. In #2, I'm assuming the optimization you're referring to is to not need to specify the prevout (32 bytes) and the index (4 bytes). I think your guess #3 makes a lot of sense.
morsecoder
CC BY-SA 3.0
2015-01-12T19:18:32.770Z
`#1` Well, when Satoshi made the design decision, consensus rules didn't reject blocks with that didn't include block height (that came with [BIP34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki), so the attack you're describing didn't work.  However, paying a specific miner for creating a block is anti-decentralization---if you're paying a specific miner, you're probably not encouraging decentralized mining using tx fees.  `#2` Yes, I'm talking about the coinbase's [outpoint](https://bitcoin.org/en/developer-reference#outpoint) which uses a static prevout and an ignored vout.
David A. Harding
CC BY-SA 3.0
2015-01-12T18:40:49.797Z
2015-01-12T23:00:21.480Z
2017-04-13T12:47:34.187Z
David A. Harding
<p>There are a few limitations on the structure of the coinbase (reward) transaction in a block. </p>

<ol>
<li>There is only one input. <code>vin.size() == 1</code> (<a href="https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/primitives/transaction.h#L232" rel="noreferrer">source</a>)</li>
<li>It doesn't reference any previous output. <code>vin[0].prevout.IsNull()</code> (<a href="https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/primitives/transaction.h#L232" rel="noreferrer">source</a>)</li>
<li>The scriptSig is not too big. <code>vin[0].scriptSig.size() &lt;= 100</code> (<a href="https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.cpp#L876" rel="noreferrer">source</a>)  </li>
<li>The scriptSig is not too small. <code>vin[0].scriptSig.size() &gt;= 2</code> (<a href="https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.cpp#L876" rel="noreferrer">source</a>)   </li>
</ol>

<p>I don't see the point of any of these. #1 and #2 enable <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="noreferrer">BIP34</a>, but they are not necessary to achieve the same outcome. The size constraints don't really limit anything, if a miner wants to make a large block they can just many many outputs in their coinbase, or many many transactions into their block.</p>

<p>Why isn't a coinbase transaction just a transaction which:</p>

<ol>
<li>Has at least one input that doesn't reference any previous outputs (for use in <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="noreferrer">BIP34</a>)</li>
<li>Allowed to claim up to (block reward + fees) more than it can spend</li>
</ol>

<p>In particular, the coinbase could optionally have further null inputs and could spend previous outputs. </p>

<p>I know for Bitcoin it's likely too late for these to change. <strong>Is this a case of over-designing, or are there security reasons for any of these constraints on the coinbase?</strong> Loosening constraint #2, in particular, makes me pause because of a bitcoin development mailing list email concerning how allowing the coinbase to spend prevouts would enable securely paying a miner to mine a chain reorganization in a particular way.</p>

CC BY-SA 3.0
2015-01-12T17:55:33.903Z
`#1 and #2 enable BIP34` Actually, block height goes in the scriptSig, not the prevout.
Nick ODell
CC BY-SA 3.0
2015-01-12T18:07:20.773Z
@NickODell, but the prevout being null makes it so that the scriptSig can contain anything, in particular it can contain the height.
morsecoder
<mining-reward><consensus><coinbase-transaction>
Why bother having limitations on Bitcoin Coinbase Transaction Scriptsigs?
morsecoder
# Why bother having limitations on Bitcoin Coinbase Transaction Scriptsigs?

(Asked by: username_0 on 2015-01-12)

There are a few limitations on the structure of the coinbase (reward) transaction in a block.

1. There is only one input. `vin.size() == 1` ([source](https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/primitives/transaction.h#L232))
2. It doesn't reference any previous output. `vin[0].prevout.IsNull()` ([source](https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/primitives/transaction.h#L232))
3. The scriptSig is not too big. `vin[0].scriptSig.size() <= 100` ([source](https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.cpp#L876))
4. The scriptSig is not too small. `vin[0].scriptSig.size() >= 2` ([source](https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.cpp#L876))

I don't see the point of any of these. #1 and #2 enable [BIP34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki), but they are not necessary to achieve the same outcome. The size constraints don't really limit anything, if a miner wants to make a large block they can just many many outputs in their coinbase, or many many transactions into their block.

Why isn't a coinbase transaction just a transaction which:

1. Has at least one input that doesn't reference any previous outputs (for use in [BIP34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki))
2. Allowed to claim up to (block reward + fees) more than it can spend

In particular, the coinbase could optionally have further null inputs and could spend previous outputs.

I know for Bitcoin it's likely too late for these to change. **Is this a case of over-designing, or are there security reasons for any of these constraints on the coinbase?** Loosening constraint #2, in particular, makes me pause because of a bitcoin development mailing list email concerning how allowing the coinbase to spend prevouts would enable securely paying a miner to mine a chain reorganization in a particular way.

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

> **Comments:**
> **username_1**: `#1 and #2 enable BIP34` Actually, block height goes in the scriptSig, not the prevout.  
> **username_0**: @username_1, but the prevout being null makes it so that the scriptSig can contain anything, in particular it can contain the height.  

---

## 1 answers

### Answer by username_2 on 2015-01-12. Score: 5 | Accepted answer

The correct answer is: ask Satoshi.

My guessed answers to the questions you asked:

1. **Why only one input?** You can't predict when a particular coinbase transaction will make it into a successful block and you can't spend the output of a coinbase transaction for 100 blocks. That means using a regular transaction is much superior for any normal spending. If there's no normal case for adding inputs to a coinbase, maybe Satoshi thought it best to disallow inputs to prevent un-thought-of attacks.
2. **Why reference a null [outpoint](https://bitcoin.org/en/developer-reference#outpoint)?** Using the same basic format as a regular transaction probably allowed code reuse. If he had optimized the coinbase, we would've saved 36 bytes times 338,692 blocks (so far), or about 12 MB. Not a big deal.
3. **Why limit coinbase size to 100 bytes?** We know Satoshi used the coinbase to put a message in block 0. Maybe a 100-byte limit was his attempt to prevent anyone else from using that same mechanism to add overlong messages. This was probably quite smart: from the fairly early days through today, many miners add messages to all of their coinbases---we can only imagine how annoying and wasteful those messages would be if they weren't limited to 100 bytes.
4. **Why specify minimum coinbase size as 2 bytes?** Highly speculative here, but maybe Satoshi foresaw the easy-duplication-of-coinbases described in [BIP30](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki) and wanted to require people use something like the [original extranonce](https://bitcoin.stackexchange.com/questions/32603/why-didnt-satoshi-make-the-nonce-space-larger/32618#32618) to help prevent accidental TXID collisions.

> **Comments:**
> **username_0**: About #1, can you think of any such un-thought-of attacks? Possibly related to the paying a miner to mine a re-org in a certain way? I don't know how that would work. In #2, I'm assuming the optimization you're referring to is to not need to specify the prevout (32 bytes) and the index (4 bytes). I think your guess #3 makes a lot of sense.  
> **username_2**: `#1` Well, when Satoshi made the design decision, consensus rules didn't reject blocks with that didn't include block height (that came with [BIP34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki), so the attack you're describing didn't work.  However, paying a specific miner for creating a block is anti-decentralization---if you're paying a specific miner, you're probably not encouraging decentralized mining using tx fees.  `#2` Yes, I'm talking about the coinbase's [outpoint](https://bitcoin.org/en/developer-reference#outpoint) which uses a static prevout and an ignored vout.  

---

