My notes on bitcoin transactions — Part 1

If you ever wanted to learn more about bitcoin, I highly recommend Mastering Bitcoin by Andreas Antonopoulos. I wish I could have started reading it years ago. Its laid out in a very structured and thoughtful way. The more I read, the more I have come to really appreciate this cryptocurrency. Its a very detailed book and there is a digital version here. I plan to publish tidbits of information on certain topics as I read throught it. It really is mainly for re-enforcing it in my head :)

Transaction Inputs and Outputs

Transactions are the most important part of the bitcoin system. When someone sends bitcoin to your bitcoin address, the transaction can be seen on the bitcoin ledger or blockchain. This is visible to the bitcoin network as an unspent transaction output (UTXO). This is essentially your “claim” to the bitcoins and can only spent by you (assuming only you have the private keys), and in turn creating another UTXO for another peer to spend. This is all recorded on the blockchain.

Transaction outputs are transmitted and serialized with the following structure:

[8 bytes] => Bitcoin Amount in Satoshis. A Satoshi is 10^-8 or 0.00000001 BTC
[1 - 9 bytes] => Locking Script Size
[variable bytes] => Locking Script

To be able to spend these new bitcoins, the user will need a transaction input to satisfy the conditions of the locking script (or encumbrance) which can only be done if you have the correct private key (and therefore the owner of the bitcoin address). The locking script is commonly referred to as ‘scriptPubKey’. With a transaction input, you will have an unlocking script commonly known as ‘scriptSig’. This unlocking script is usually a digital signature and public key proving the ownership of bitcoin.

Transaction inputs are transmitted and serialized with the following structure:

[32 bytes] => Transaction Hash: Pointer to the transaction containing the UTXO to be spent
[4 bytes] => Output Index
[variable bytes] => Locking Script

Transaction Fees

Usually transaction fees are collected which serve as an incentive to miners for securing the network and help prevent ‘spam’ transactions or any kind of abuse. Miners will need to include (mine) a transaction into the next block in the blockchain. Transaction fees are calculated based on the size of the transaction in kilobytes (not the value of the transaction in bitcoins). They are not mandatory but not including the transaction fee will reduce the priority of processing the transaction.

Transaction fees are implied and calculated as follows:

Fees = Sum(Inputs) - Sum(Outputs)

As an example, if I have a transaction input of 50 BTC which produces an output of 45 BTC. The 5 BTC is implied and will be processed as a transaction fee. This is somewhat important to understand (especially if developing a bitcoin app) as to be able to spend BTC, you will need to identify your UTXOs and generate the correct transaction input and output amounts. You could have multiple outputs but the difference between inputs and outputs will be the transaction fee.

If Alice want to send 5 BTC to Bob, and Alice has 50 BTC in locked in one UTXO, she will need to create a transaction input of 50 BTC and multiple outputs: 5 BTC to Bob, 44.999 BTC back to Alice (think of it as change). The difference 0.001 BTC is implied and will form the transaction fee. This should be handled automatically by a bitcoin application.

Locking and Unlocking Scripts

To be able to spend BTC, a bitcoin client will validate a transaction by executing the locking and unlocking scripts together. The unlocking script is executed first, using the stack execution engine. If successful, the main stack is copied and the locking script is executed. If the result from executing the locking script with stack data copied from the unlocking script is TRUE, the unlocking script has succeeded in satisfying the conditions in the locking script and therefore the input is a valid authorization to spend the UTXO. Any other result and the transaction would fail.

The bitcoin transaction script language is called Script. It is a stack-based execution language, meaning you can push or pop data on to the stack with certain operations. Push adds an item on top of the stack while Pop removes an item from the top.

As a simple example, imagine a transaction where you have the following unlocking script in your input:

2

and this locking script from the UTXO:

3 OP_ADD 5 OP_EQUAL

To validate this transaction, the result of the unlocking script is pushed onto the stack, copied and the locking script is executed as follows:

2 3 OP_ADD 5 OP_EQUAL

This is how the execution will happen:

Bitcoin script validation

The result is ‘TRUE’ so the transaction input is valid, and the user has authoritative claim to spend this reference UTXO.

In part 2, I intend to walkthrough in detail the different bitcoin transaction scripts that are used today.