These are the requirements on the coinbase transaction that I am currently aware of.
The transaction is structured like every other transaction, though not all fields have the same meaning.
- Version: a 32-bit LE integer. For normal transactions, the version number can only be 1 or 2 (for relative timelock semantics, see BIP 68). For coinbase transactions it has no meaning, and can be anything.
- Transaction inputs: for normal transactions, refers to the set of unspent previous transaction outputs that are being spent. For coinbase transactions it is different, there must be exactly 1 input, and it must have specific values.
- Prevout hash: must be 0000...000
- Prevout index: must be 0xffffffff
- scriptSig: for normal (non-segwit, see BIP141) transactions contains the proof that this transaction is authorized by the previous holder of the coin being spent. For coinbase transactions, it has different semantics. Instead it must:
- Start with a push of the block height (as specified in BIP34)
- Be followed by arbitrary data (which is often called the extraNonce)
- The entire scriptSig must be between 2 and 100 bytes exactly (this rule predates BIP34, so its lower bound 2 is now superseded by the fact that the block height push is already larger than that).
- nSequence: for normal transactions this field affects BIP125 RBF semantics, and relative locktime semantics (BIP 68), but these don't apply to coinbase transactions. Can be anything.
- Transaction outputs: determines which UTXOs are created by this transaction. The semantics are identical for normal transactions and coinbase transactions. In particular, it can contain any number of outputs. Typically it will contain one or more outputs that give mined coins (subsidy + tx fees from other transactions in the block) to the miner, plus some dummy 0-value outputs for various purposes (one of them being the segwit commitment, if this is a segwit block, see BIP141).
- nLockTime: This has absolute locktime semantics (stating when the transaction becomes valid), both for normal transactions and coinbase transactions.
So to answer your question directly:
- version - 4 Bytes - LE - 01000000
In fact it can be any 4-byte value.
- input count - 1 Bytes - xx - 01
- prev tx - 32 Bytes - xx - 0000000000...0000
- prev out n - 4 Bytes - xx - ffffffff (outpoint index or fake index)
Correct.
- coinbase script length (LCS) - <?> Bytes - <?> - <what is value range of LCS i.e. min and max Bytes?>
- coinbase script - LCS Bytes :
1 Bytes - xx - 03 (Size of Block Height in next 3 Bytes)
3 Bytes - LE - __ (Valid Block Height in LE for Block being mined)
[LCS-4 Bytes] - xx - xx (ANY binary string is Valid. ANY STRING!!!!)
The coinbase scriptSig is encoded as 1 byte encoding the length of the script, plus the script itself. That script must be between 2 and 100 bytes. The script has to start with a push of the block height, due to BIP34. For the current range of heights (65536 through 16777215), that's a 0x03 to indicate a 3-byte push, followed by 3 bytes encoding the block height in LE. After that, up to 96 other bytes can follow, whose contents does indeed not matter at all.
- sequence - 4 Bytes - xx - ffffffff
This can be anything.
- output count - 1 Bytes - xx - 01
- value - <?> Bytes - LE - __ (mining reward + transaction fee of all other included transactions in Satoshi)
Correct. You can have multiple outputs in fact (and their sum of values has to match the subsidy + tx fees), but 1 works fine. If you want to create a segwit block (see BIP141), there also needs to be another zero-value output with a specific structure; see the BIP for details.
- script length (SL) - 1 Bytes - xx - (what is value range of SL i.e. min and max bytes, or is it fixed size?)
- pubkey script - SL Bytes - <?> - __ (What is this?! Is it the wallet address or the public key or something else - of the person who recieves the funds in 'value'?)
This is the scriptPubKey corresponding to the address you want to receive the mining reward for. There are many software libraries that can decode addresses to scripts for you, and answers on this site that explain it.
- locktime - 4 Bytes - xx - 00000000
Not strictly required, as there are other permitted values, but they must result in a "final" transaction, which depends on the height and timestamp of block. Choosing 00000000 here will always work.
