Raw transactions are encoded into hex as a serialization format to compactly represent them. The hex format of a p2pkh has byte fields for:
- the version
- the number of inputs
- For each input:
-- the transaction ID, & output number
-- the length of scriptSig
-- a bunch of bytes called "sequence"
- the number of outputs
- For each output:
-- the amount to send
-- the locking script
- the locktime.
An example will greatly aid the presentation of what a raw P2PKH transaction is composed of, like the one located at
https://medium.com/@bitaps.com/exploring-bitcoin-signing-the-p2pkh-input-b8b4d5c4809c :
They have a raw transaction that looks like this:
0100000001449d45bbbfe7fc93bbe649bb7b6106b248a15da5dbd6fdc9bdfc7efede83235e0100000000ffffffff014062b007000000001976a914f86f0bc0a2232970ccdf4569815db500f126836188ac00000000This is the raw transaction for a 1 P2PKH input, 1 P2PKH output transaction.
We have a
version of 1,
number of inputs which is also 1,
the transaction ID of the input we want to spend (it looks like it's written backwards but more on that later) as well as
the output number within the transaction that, along with the transaction ID, fully identifies the input, then we have he
sigscript length which is 0, because we didn't sign the transaction yet, our
sequence number is 0xffffffff which disables Locktime [more on that below], then there's the
number of outputs which is 1, followed by the
amount to spend, and this particular value is hex for 1.29 BTC, then we have our
locking script (OP_DUP OP_HASH160... but in hex) and finally we have the
Locktime value which is completely zero here because it's turned off.
The reason why the above is relevant is because after we derive the sighash from it and sign the transaction, we fill in the sigScript part of the raw transaction that we left empty.
So what used to be
00 is now:
6b483045022100e15a8ead9013d1de55e71f195c9dc613483f07c8a0692a2144ffa9050643682202206 2bc9466b9e1941037fc23e1cfadf24c8833f96942beb8f4340df60d506f784b012103969a4ac9b1521cfae44a929a614193b0467a20e0a15973cae9ba1efb9627d830Let's break this down:
The
sigscript length is now 107 bytes. Our
signature length is 72, and this measures the blue value which is our
DER-encoded signature with r and s values and whatnot, then there's our
sighash type which here is 01 or SIGHASH_ALL, followed by the
length of the public key and
the public key itself.
The reason why many of the values in the raw transaction (not the sigscript though) look "reversed" is because they are stored in little-endian format, so if the true value is 0x12345678, we will actually store it in the hex as 0x78563412. That is what you can see in the transaction ID, script version and output numbers.