Bitcoin Transactions
Transaction Outputs and Inputs
Transaction Inputs
Transaction inputs identify (by reference) which UTXO will be consumed and provide proof of ownership through an unlocking script.
To build a transaction, a wallet selects from the UTXO it controls, UTXO with enough value to make the requested payment. Sometimes one UTXO is enough, other times more than one is needed. For each UTXO that will be consumed to make this payment, the wallet creates one input pointing to the UTXO and unlocks it with an unlocking script.
Let's look at the components of an input in greater detail. The first part of an input is a pointer to an UTXO by reference to the transaction hash and an output index, which identifies the specific UTXO in that transaction. The second part is an unlocking script, which the wallet constructs in order to satisfy the spending conditions set in the UTXO. Most often, the unlocking script is a digital signature and public key proving ownership of the bitcoin. However, not all unlocking scripts contain signatures. The third part is a sequence number, which will be discussed later.
Consider our example in Transactions - Behind the Scenes. The transaction inputs are an array (list) called vin:
"vin": [ { "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18", "vout": 0, "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf", "sequence": 4294967295 } ]
As you can see, there is only one input in the list (because one UTXO contained sufficient value to make this payment). The input contains four elements:
-
A transaction ID, referencing the transaction that contains the UTXO being spent
-
An output index (vout), identifying which UTXO from that transaction is referenced (first one is zero)
-
A scriptSig, which satisfies the conditions placed on the UTXO, unlocking it for spending
-
A sequence number (to be discussed later)
In Alice's transaction, the input points to the transaction ID:
7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18
`and output index 0 (i.e., the first UTXO created by that transaction). The unlocking script is constructed by Alice's wallet by first retrieving the referenced UTXO, examining its locking script, and then using it to build the necessary unlocking script to satisfy it.
Looking just at the input you may have noticed that we don't know anything about this UTXO, other than a reference to the parent transaction containing it. We don't know its value (amount in satoshi), and we don't know the locking script that sets the conditions for spending it. To find this information, we must retrieve the referenced UTXO by retrieving the parent transaction that contains it. Notice that because the value of the input is not explicitly stated, we must also use the referenced UTXO in order to calculate the fees that will be paid in this transaction (see Transaction Fees).
It's not just Alice's wallet that needs to retrieve UTXO referenced in the inputs. Once this transaction is broadcast to the network, every validating node will also need to retrieve the UTXO referenced in the transaction inputs in order to validate the transaction.
Transactions on their own seem incomplete because they lack context. They reference UTXO in their inputs but without retrieving that UTXO we cannot know the value of the inputs or their locking conditions. When writing bitcoin software, anytime you decode a transaction with the intent of validating it or counting the fees or checking the unlocking script, your code will first have to retrieve the referenced UTXO from the blockchain in order to build the context implied but not present in the UTXO references of the inputs. For example, to calculate the amount paid in fees, you must know the sum of the values of inputs and outputs. But without retrieving the UTXO referenced in the inputs, you do not know their value. So a seemingly simple operation like counting fees in a single transaction in fact involves multiple steps and data from multiple transactions.
We can use the same sequence of comm and s with Bitcoin Core as we used when retrieving Alice's transaction (getrawtransaction and decoderawtransaction). With that we can get the UTXO referenced in the input from Alice's transaction and take a look:
"vout": [ { "value": 0.10000000, "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG" } ]
We see that this UTXO has a value of 0.1 BTC and that it has a locking script (scriptPubKey) that contains "OP_DUP OP_HASH160…".
Tip |
To fully underst and Alice's transaction we had to retrieve the previous transaction referenced as input. A function that retrieves previous transactions and unspent transaction outputs is very common and exists in almost every bitcoin library and API. |
Transaction serialization - inputs
When transactions are serialized for transmission on the network, their inputs are encoded into a byte stream as shown in Transaction input serialization.
Table 2. Transaction input serialization
Size | Field | Description |
---|---|---|
32 bytes |
Transaction Hash |
Pointer to the transaction containing the UTXO to be spent |
4 bytes |
Output Index |
The index number of the UTXO to be spent; first one is 0 |
1–9 bytes (VarInt) |
Unlocking-Script Size |
Unlocking-Script length in bytes, to follow |
Variable |
Unlocking-Script |
A script that fulfills the conditions of the UTXO locking script |
4 bytes |
Sequence Number |
Used for locktime or disabled (0xFFFFFFFF) |
As with the outputs, let's see if we can find the inputs from Alice's transaction in the serialized format. First, the inputs decoded:
"vin": [ { "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18", "vout": 0, "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf", "sequence": 4294967295 } ],
Now, let's see if we can identify these fields in the serialized hex encoding in Alice's transaction, serialized and presented in hexadecimal notation:
0100000001186f9f998a5aa6f048e51dd8419a14d8a0f1a8a2836dd73 4d2804fe65fa35779000000008b483045022100884d142d86652a3f47
ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039 ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813
01410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade84 16ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc1
7b4a10fa336a8d752adfffffffff0260e31600000000001976a914ab6 8025513c3dbd2f7b92a94e0581f5d50f654e788acd0ef800000000000
1976a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac00000 000
Hints:
- The transaction ID is serialized in reversed byte order, so it starts with (hex) 18 and ends with 79
- The output index is a 4-byte group of zeros, easy to identify
- The length of the
scriptSig
is 139 bytes, or 8b in hex - The sequence number is set to
FFFFFFFF
, again easy to identify
ScriptSig
is a specific type of unlocking script that when serialized for transmission on the network, inputs are encoded into a byte stream as shown in ScriptSig
input serialization. The serialization of the signature field is detailed in Serialization of signatures (DER). The signature field also includes a Signature Hash Type (SIGHASH), which is detailed in Signature Hash Types (SIGHASH).
Table 3. ScriptSig input serialization
Size | Field | Description |
---|---|---|
1–9 bytes (VarInt) |
Signature Size |
Signature length in bytes, to follow |
Variable |
Signature |
A signature that is produced by the user's wallet from his or her private key, which includes a SIGHASH |
1–9 bytes (VarInt) |
Public Key Size |
Public key length in bytes, to follow |
Variable |
Public Key |
The public key, unhashed |