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)
  2. It doesn't reference any previous output. vin[0].prevout.IsNull() (source)
  3. The scriptSig is not too big. vin[0].scriptSig.size() <= 100 (source)
  4. The scriptSig is not too small. vin[0].scriptSig.size() >= 2 (source)

I don't see the point of any of these. #1 and #2 enable BIP34, 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)
  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.

  • #1 and #2 enable BIP34 Actually, block height goes in the scriptSig, not the prevout. – Nick ODell Jan 12 '15 at 17:55
  • @NickODell, but the prevout being null makes it so that the scriptSig can contain anything, in particular it can contain the height. – StephenM347 Jan 12 '15 at 18:07
up vote 2 down vote accepted

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? 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 and wanted to require people use something like the original extranonce to help prevent accidental TXID collisions.

  • 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. – StephenM347 Jan 12 '15 at 18:59
  • #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, 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 which uses a static prevout and an ignored vout. – David A. Harding Jan 12 '15 at 19:18

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.