The BSV Academy’s free introduction to Bitcoin Theory course covers the design of Bitcoin as a system as prescribed by Satoshi Nakamoto. This course is open to anyone who is interested in Bitcoin and is the beginner course in this series. Some technical experience would be helpful to complete the course, however, it is open to anyone regardless of experience.
The course goes through the Bitcoin white paper section by section elaborating on the concepts contained within each. This section focuses on transactions and payments.
To make it as effortless as possible for you to have access to this educational material, we are publishing the entire course here on our blog. Stay tuned for a section-by-section release, and remember that you are still welcome to enrol in the BSV Academy to gain a certificate of completion to add to your resume.
How do Bitcoin transactions work?
We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.
The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double-spending.
After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.
We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first.
To accomplish this without a trusted party, transactions must be publicly announced, and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.
Electronic coins
We define an electronic coin as a chain of digital signatures.
- Satoshi Nakamoto, Bitcoin White paper
In Bitcoin, transactions are built by referencing unspent digital coins called ‘Unspent Transaction Outputs’ or ‘UTXOs’ in transaction inputs. To be spent, the input must also include a solution to the script puzzle contained in the output which locks the satoshi tokens it holds.
In almost all cases one part of this script puzzle requires a valid digital signature to be provided by the party that holds custody of the UTXO. The tokens (coins) are spent into the transaction and redistributed into new unspent transaction outputs, consuming the UTXOs reference by the inputs in the process. In this way, a coin’s history can be mapped as a chain of valid script solutions or digital signatures.
This chain leads all the way back to the blocks in which each of the Satoshi tokens being used in the transaction was first made accessible in the form of a coinbase reward.
This chain forms a Directed Acyclic Graph or DAG. The combined DAGs that represent the history of all UTXOs that currently exist on the network is what we refer to as the Bitcoin ledger.
Spending a coin
Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin.
- Satoshi Nakamoto, Bitcoin White paper
Each UTXO is locked with a script commonly called a scriptPubKey. This scriptPubKey is a puzzle that defines a predicate. The spending party must provide a solution which allows the predicate to be solved with a ‘True’ or non-zero outcome.
When spending a coin, the owner (or their proxy) first constructs a message that includes:
- The identity of the coin or coins on the ledger (transaction ID and output index);
- Valid solutions to each of the locking scripts written onto the ledger when the coin or coins were created;
- A new locking script for each of the outputs being generated in the transaction which tests a knowledge proof provided by the receiver to the spending party;
- Other details include a locktime parameter and protocol version.
Depending on the spender’s preference, some or all of this message is combined, and the resulting string hashed and used to generate an ECDSA signature using a keypair controlled by the spending party and specified by scriptPubKey contained in the input being spent. Once the transaction is complete, it is ready to be sent onto the network to be processed into a block.
Payee verification
A payee can verify the signatures to verify the chain of ownership.
- Satoshi Nakamoto, Bitcoin White paper
Each iteration of a coin contains a solution to the previously defined predicate. Typically, this includes a public key and a corresponding signature created using Elliptic Curve Digital Signature Algorithm (ECDSA) making it computationally trivial to validate the proof of ownership supplied with the given coin.
This is a crucial element of the peer to peer nature of the system as it means that a merchant can accept payments directly from users and validate their ownership claim without the need of a trusted third party using only information that can be validated against the network’s proof of work process.
This makes it possible for merchants to broadcast transactions to the network on behalf of users whose wallets can be used as very simplified applications which hold and sign digital coins but do not have an interface to the network. This also makes it possible for Bitcoin to be used with devices as simple as a smart card.
Existing solutions to digital money
The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double-spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.
- Satoshi Nakamoto, Bitcoin White paper
When payments are made, the simple validation of the signature does not provide a means for the merchant to check that the coins being handed over have not been spent in a separate transaction which would invalidate this transaction.
This is a recurring problem in digital currencies and prior to the introduction of Bitcoin a typical solution was for each transaction to be routed back to a central arbiter who is responsible for checking the validity of the transaction using a closed system.
The inherent weakness of this style of system is that the centralised validation system is managed by a single company or entity which operates like a central clearing house through which all transactions must be routed.
This creates problems around transparency and scalability as unlike Bitcoin where a competitive system of incentives drives the network to scale organically, the system is reliant on a single entity or team to manage the growth of the central system and for whom competitive pressures do not exist to keep transaction fees as low as economically feasible.
Bitcoin’s first seen rule
We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend.
- Satoshi Nakamoto, Bitcoin White paper
Bitcoin is a solution that solves the double spending problem without the need for a centralised decision-making system through the use of the ‘First Seen Rule’. This rule states that the first seen transaction that validly spends a given UTXO is the transaction which is accepted by the node.
In a case where two conflicting transactions are introduced simultaneously onto the network which each seek to spend the same input coins to different output destinations, the one which reaches the network nodes which have been allocated the most hashpower stands to be the version of the transaction which is written into a block. The other transaction will never be accepted into a block and as such can never become a permanent part of the Ledger.
Additional protections can be implemented such as ‘Double Spend Notifications’ which detect and announce double spend attempts to peers on the network including merchants handling the double spends. Because a double spend must occur within a very short window (less than 5 seconds) it is very simple for online and physical merchants to reject transactions that are double spent or even attempted.
Learn more about double spending.
How the Bitcoin network broadcasts transactions
The only way to confirm the absence of a transaction is to be aware of all transactions.
- Satoshi Nakamoto, Bitcoin White paper
For a node that is seeking to build blocks and extend the ledger, the only way to be certain that each transaction they have received is the only one trying to spend a given UTXO or set of UTXOs is to be aware of all of the transactions taking place on the network in as close to real time as possible.
If a node tries to create a block using a transaction that other nodes on the network recognise as a double spend, there is a very strong chance that they will lose their money, effectively wasting the cost of constructing their block and performing the proof of work.
This creates an incentive for nodes to ensure that all other nodes are aware of the transactions they are working on incorporating into a block, as without this awareness, the chance of using a double spent input in a block is higher.
How the Bitcoin network achieves consensus
In the mint-based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received.
- Satoshi Nakamoto, Bitcoin White paper
When the system is managed by a centralised party, the monitoring of which inputs are used in a transaction and their spent/unspent status is managed simply on a first seen basis.
In Bitcoin, the system has no such means for centralised decision-making so each node must operate as a self-contained mint.
Public announcement of all transactions is critical to the sound operation of the system and provides the fastest means for participants in the competitive block-building process to come to a consensus on the order of events when a valid block is announced to the network.
Without public announcement, every time a potential block is found, the discovering node must subsequently supply any missing transactions to the rest of the network which consumes time and resources, impacting its ability to operate as effectively and efficiently as possible.
The first-seen rule and its application to both transaction and block announcements is a core element of the incentives that drive the construction of the infrastructure that underpins the Bitcoin network.
Proof of acceptance in Bitcoin
The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.
- Satoshi Nakamoto, Bitcoin White paper
For merchants to have confidence in funds received via the Bitcoin network, there must be a means for them to be able to query the nodes who validate the transaction to ensure that it is not double-spending valid inputs. This can be achieved in a variety of ways including:
- Querying a selection of nodes for a transaction output that meets the merchant’s requirements;
- By the merchant sending the transaction on the sender’s behalf and receiving notification of the transaction’s validity from the nodes it uses;
- Through double-spend alarm systems that notify any parties to transactions that double spend an input.
