0

Is it correct to say:

As the coinbase transaction doesn't need to identify an output, there is no need for the input scriptSig.

Would a block be accepted in which the coinbase transaction has an empty input scriptSig field? Is there an example of such?

Can any other fields be left out, e.g. could the input TXID and VOUT be omitted (as have implied values)?


Specifically, given this example coinbase transaction (from here):

01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4503ec59062f48616f4254432f53756e204368756e2059753a205a6875616e67205975616e2c2077696c6c20796f75206d61727279206d653f2f06fcc9cacc19c5f278560300ffffffff01529c6d98000000001976a914bfd3ebb5485b49a6cf1657824623ead693b5a45888ac00000000

Would it still be accepted as (input scriptSig removed):

01000000010000000000000000000000000000000000000000000000000000000000000000ffffffffffffffff01529c6d98000000001976a914bfd3ebb5485b49a6cf1657824623ead693b5a45888ac00000000

Or even (input TXID and VOUT removed):

0100000001ffffffff01529c6d98000000001976a914bfd3ebb5485b49a6cf1657824623ead693b5a45888ac00000000

1

1 Answer 1

3

Would a block be accepted in which the coinbase transaction has an empty input scriptSig field? Is there an example of such?

No, for unknown reasons there is a consensus rule that the coinbase input scriptSig must be between 2 and 100 bytes in length. Its contents however does not matter; it does not need to consist of valid opcodes even.

Since BIP34 activated in 2012, there is an additional rule that the coinbase scriptSig starts with a push of the block height (in a particular format). This forces all coinbase transactions to be unique.

Can any other fields be left out, e.g. could the input TXID and VOUT be omitted (as have implied values)?

No, because there is not even a way to signal missing fields.

Overall, a coinbase transaction is subject to these special rules:

  • It has a version number and locktime like other transactions, but their values are ignored.
  • It must have exactly one input:
    • Its prevout hash must be the all-zero hash (indicating it is "spending" new coins, if you will)
    • Its prevout index must be 0xFFFFFFFF, a value that cannot occur for normal UTXOs.
    • Its nSequence value must be present, but is ignored.
    • Its scriptSig must be between 2 and 100 bytes inclusive, and since BIP34 start with a push of the block height.
  • It must have 1 or more outputs. These outputs are treated like all other outputs; without them, there would be no way to signal where the created/mined coins go.
7
  • re. "all-zero hash" my interpretation is that the input prevout field should be zeros 0x00000... , not SHA256(0x0000)?
    – Lee
    Sep 2, 2023 at 18:02
  • Also, the coinbase version and locktime can be used for arbitrary bytes? It would be interesting to find an example in the wild...
    – Lee
    Sep 2, 2023 at 18:04
  • 1
    @Lee Correct. The prevout hash must be all zero bytes, not the hash of all zeroes. Sep 2, 2023 at 18:17
  • 1
    > Also, the coinbase version and locktime can be used for arbitrary bytes? It would be interesting to find an example in the wild... @Lee check this question
    – bordalix
    Sep 3, 2023 at 6:31
  • 1
    Yes, I said so above. Sep 5, 2023 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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