This article is the fifth in a series of insights into the more purely technical part of Bitcoin, accessible even to those who are not familiar with coding. This article is also a sort of guide designed to gradually go down what many call “the rabbit hole”.
In terms of books, it is necessary to mention “Mastering Bitcoin” by Andreas Antonopoulos, a regular reference, from which the images in this article were taken.
Bitcoin transactions
Transactions are the most important part of the bitcoin system: everything else in bitcoin is designed to ensure that transactions can be created, propagated, validated, made unalterable by inserting them in the blockchain. In Bitcoin, transactions are data structures that encode the value of a property transfer: a transaction is a communication from a node to the network by which an owner of bitcoin authorises the transfer of all or part of it to another owner.
Each transaction consists of one or more inputs and one or more outputs (there is always a difference between the input and the total output, due to network fees). Each transaction transfers value from the inputs to the outputs:
- each input is given by a previous output;
- each output is associated with an impediment (encumbrance).
The impediment imposes the requirement of a signature in order to be able to “spend” that certain value, ergo to be able to use it as input for a subsequent transaction. This process generates a veritable chain of ownership.
A transaction is, therefore, a transfer of value, and can:
- have one input and more outputs (including “the remained”);
- have more inputs and (at least) two or more outputs (including “the remainder”).
Each input is given from a previous output. Wallets normally hold a database of unspent UTXOs (unspent transaction outputs) that are encumbered with the wallet keys. Full-client wallets otherwise keep copies of each UTXO in the blockchain. This allows a wallet both to create transaction inputs and to verify that incoming transactions have correct inputs.
Each output is associated with an encumbrance. A new transaction output is generated in the form of a script that creates an encumbrance on the value and can only be unlocked by providing the solution to the script (a signature of the private key that corresponds to the receiving public address, in the most common case). Each transaction usually has a number of inputs suitable for the value to be moved, meaning that:
- this value becomes an “encumbered” output and “directed” to a certain bitcoin address (that of the recipient);
- any excess value becomes an “encumbered” output and “directed” to a new address controlled by the client (or at the same address as the client).
Network fees are not explicit in the transaction but are given by the difference between input and output. A transaction contains all the information needed to be processed by the Bitcoin network, with the aim of propagating transactions (and blocks) to other nodes. Each node (client) in the Bitcoin network that receives a new valid transaction forwards it to the nodes with which it is connected, reaching a large percentage of nodes in a few seconds. In the end, a bitcoin transaction is only a 300-400 bytes of data that must reach one of the tens of thousands of bitcoin nodes. The transaction is signed, ergo does not contain any confidential information (so it can be public), so it can be transmitted via WiFi, Bluetooth, NFC, eventually through packet radio, satellite transmission, etc. Bitcoin has transformed value into a data structure, making it virtually impossible to prevent someone from creating a bitcoin transaction. Once sent to any node, the transaction will be validated by that node, which will propagate it to the other nodes to which it is connected. The bitcoin network is a P2P network, so each bitcoin node is connected to other bitcoin nodes via the peer-to-peer protocol. The entire network forms a loosely connected mesh without a fixed type or predefined structure. Messages (transactions and blocks) are propagated from each node to all the peers to which they are connected (flooding).
Inputs and Outputs
A UTXO is a non-divisible fragment of a value (currency) “locked” on a destination address, validated and entered into a blockchain. The recipient, owner of the private keys that can “unlock” the UTXO, does not enjoy (like anyone else in the Bitcoin network) of a balance related to an account: owning bitcoin means simply being in possession of private keys that can unlock the UTXO pointing to addresses generated by the same keys (the concept of balance is simply a construction of the wallet application, which scans the blockchain aggregating the UTXO related to the private keys of that same wallet).
A UTXO has an arbitrary value denominated in multiples of satoshis (one hundred millionth of BTC). Again: the value is arbitrary but not divisible: each transaction spends the entire UTXO generating eventually a remainder (change) pointed to an address generated by the same keys that unlock the UTXO in question. The UTXO “expenses” from the transaction are the inputs of the transaction, while the UTXO generated from the same transaction are the outputs of the transaction. Thus, an arbitrary amount of value (currency) moves from one owner (of private keys) to another in a chain of transactions that generate and spend UTXO. The only exception is a transaction called coinbase, through which new bitcoins are generated as a reward for the creation of a new block.
Outputs
Each transaction creates outputs, UTXO (with the exception of OP_RETURN), traced by each full-node as UTXO sets. An output consists of two parts:
- an amount of bitcoin denoted in satoshis
- a cryptographic puzzle that defines the conditions required to spend the output known as locking script, witness script, or scriptPubKey.
When transactions are transmitted to the network or exchanged between applications, they are serialised. This process converts the internal representation of the data structure into a format that can be transmitted one byte at a time (byte stream).
Inputs
Transaction inputs identify which UTXOs will be spendable and provide proof of ownership via the unlocking script. To construct a transaction, a wallet selects from the controlled UTXOs those (one or more) with sufficient value to execute a payment request. For each UTXO that will be spent, the wallet generates an input that “points” to the UTXO and unlocks it with the unlocking script.
The input contains four elements:
- a transaction ID, which refers to the transaction containing the UTXO that is being spent;
- an output index (vout), which identifies which UTXO of the transaction it is referring to;
- a scriptSig that meets the conditions of the UTXO, unlocking it to be spent;
- a sequence number (in SegWit transactions there is also a witness field).
Fees
Most transactions include fees (commissions), basically for two reasons:
- to (further) compensate miners for the safety of the network;
- making an attack on the network economically unsustainable by flooding it with transactions.
Fees are not calculated on the amount transited, but on the size of the transaction in kilobytes: overall, fees are based on market logic within the network. Miners may give priority according to different criteria, but high fee transactions tend to be included by the miners in the block under construction, while low fee transactions (or zero, they are not mandatory) may not be included for a long time (or at all). It should be noted that Bitcoin nodes do not accept transactions with fees of less than 1 sat/byte from the P2P network (which are accepted if they are in blocks). Initially, the fees were fixed, then as the network evolved, competition and the law of the market took over. The current default of the minrelaytxfee option (which sets the fees in Bitcoin Core) is 0.00001 bitcoins (1 sat/byte equivalent to 100 millibitcoins per kilobyte): this is the parameter that defines the transactions accepted via the P2P network.
Transactions below this threshold are considered as free (zero fee) and discarded. Wallets, exchanges and other services that create transactions implement dynamic fees, based on algorithms that estimate the correct fees to forward “competitive” transactions. Some services allow choosing between different types (high, medium and low).
The data structure of the transactions does not have a fee field: they are included in the difference between the sum of the inputs and the sum of the outputs. Any surplus between these two sums is retained by the miners.
