A string of hex
Each transaction consists of a version number, at least one input, at least one output, and an nLocktime constraint.
Each input contains a reference to and the outpoint (vout) from the TX that created it, a sequence number, and an unlocking script called a scriptSig or solution. The scriptSig must provide a valid solution to the vout being spent.
Each output contains the amount being sent and a locking puzzle, also known as a scriptPubKey.
The transaction’s nLocktime parameter determines a point in the future from which this coin can be spent. If there are inputs with nSequence values that are not final (0xFFFFFFFF) the coin cannot be mined until the nLocktime expires.
The first 4 bytes of a transaction are the Version No. For most transactions today, this is simply set to 1 however over time we will see this being used to implement specialty functions and to enforce mining constraints.
Following the version is a Varint which defines the number of inputs being spent. The maximum is 4.3 Billion.
Following the input count are the inputs themselves. They are structured as follows:
1: 32 bytes referencing the TXID being spent (little endian hex)
2: 4 bytes pinpointing the vout number of the UTXO in the transaction
3: The unlocking script. This is broken down as follows:
i: Length of the unlocking script (varint, 1-9 bytes long)
ii: scriptSig (contains signatures, public keys and any other data, in the required order for the Input ScriptPubKey to be spent)
iii: A one-byte SIGHASH flag. This tells the script processing engine which parts of the transaction to include in the message hash being signed
4: Sequence number (4 bytes, little endian) - Used to iterate transactions in payment channels
Following the serialised inputs, we have the outputs. The next 1-9 bytes are a varint type declaring the number of outputs being created by the transaction.
Next comes the outputs. They are comprised of the following:
1: The amount of Satoshis being spent in the output (16 bytes)
2: The locking script which is a set of Opcodes in Bitcoin script that describe the conditions under which the output being created can be spent - It is structured as follows:
i: Length of the script (varint)
ii: The script itself which is a set of opcodes and data items
The final 8 bytes of the transaction is the nLocktime parameter. This can be used to specify a date and time or a blockheight at which the transaction can be spent.