In section five of the Bitcoin white paper, Satoshi Nakamoto defines a set of instructions that describe the optimal behaviours that a node participating on the network should exhibit.
These nodes are characterised by their work of producing valid blocks, which they then distribute to other nodes and validating their blocks in return. Without nodes performing these tasks, the network will not function.
Nodes take on these important tasks by collating, validating and recording all interactions occurring on the Bitcoin network in real time.
Section 5 of the Bitcoin white paper, called ‘Network’, outlines a list of instructions that nodes must follow to correctly operate the Bitcoin network.
- New transactions are broadcast to all nodes.
- Each node collects new transactions into a block.
- Each node works on finding a difficult proof-of-work for its block.
- When a node finds a proof-of-work, it broadcasts the block to all nodes.
- Nodes accept the block only if all transactions in it are valid and not already spent.
- Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
By collectively following these instructions, nodes are incentivised to find ways to develop their own competitive advantage. By doing so, their investment in hardware and connectivity will allow the network to scale efficiently. These incentives are structured such that the most honest, open and capable participants are the most likely to be rewarded for their actions.
When trying to understand these instructions, it helps to think of the system operating at a global scale, managing many billions of transactions per block. By keeping this scenario in mind, it becomes very easy to understand why there is a strong drive to follow the instructions very closely.
The network is designed like this so that attacks are not economically viable and thus won’t be sustained.
Step 1: New transactions are broadcast to all nodes
This instruction states that nodes should transmit and broadcast any new transactions that it sees to all other nodes and:
- If the transaction came from one node, it should not be sent back to that same node.
- If a node knows that the node it received the transaction from would have sent it to other nodes already, there is no reason to send it to those nodes either, however;
- If a node knows that another node has not received a transaction it has, the node will send it.
Step 2: Each node collects new transactions into a block
There are numerous steps to this process, and at scale there is significant investment in infrastructure needed to manage this task effectively. Each transaction spends outputs from the UTXO set to which the spending party must attach a valid scriptSig. The node then puts the transaction through a set of tests checking the following:
* the scriptSig for each input validly solves the locking script / scriptPubkey
* this is the first time these inputs have been spent
* the outputs being generated are valid
A node can append transactions to a block in any order they like. However, thanks to the simplicity of Merkle trees, as new transactions arrive the most efficient method is to append transactions to the end of the block and calculate what is added to the Merkle tree.
At scale this effectively minimises the work that is re-done in the management of the Merkle tree allowing the block building capacity of the node to increase in the most efficient manner.
Step 3: Each node works on finding a difficult proof-of-work block
The process of finding a proof-of-work is done by specialised machines called ASIC miners or ‘hashers’. The process is typically governed by an intermediate control system called a ‘Pool Miner’, which manages the process. Nodes distribute key information about the incomplete block to the pool miners who use it to manage one or more hashers in the search for a valid proof-of-work.
Hashers perform the process of ‘hashing’ the block header by modifying a nonce (number used once) in an effort to solve a difficult puzzle, trying to find a block header that hashes to a number that is less than another number (difficulty target). This puzzle has a random outcome whose solution frequency is ‘self tuned’ by the network to try and maintain the block discovery rate to as close to 10 minutes as possible.
This time is fairly close to optimal in that it results in a low number of orphan blocks, while still giving ample opportunity (2016 per fortnight) for nodes to be complete in the process of ordering the ledger. Block templates to which the most hash has been applied have the highest probability of being valid.
Step 4: When a node finds a proof-of-work, it broadcasts the block to all nodes
When a node solves the puzzle, it must also propagate the solution to all other nodes on the network as quickly as possible. This is to minimise the chance that a competing node will also find their own valid proof-of-work and propagate it to the network, sparking what is known as an ‘Orphan Race’.
When analysing this directive it is important to also look at what is in a block so that we can understand how much information needs to be transmitted across the network. In its full form, a block is a set of all transactions in the Merkle Tree plus the block header.
These blocks represent an incorruptible record of valid transactions. In this way we can consider the chain of blocks as a chronologically ordered set of timestamps. The process of using proof of work gives the network an ideal method to control the cadence of these timestamps, with each node operating as part of a distributed, leaderless time-stamping service.
Step 5: Nodes accept the block only if all transactions in it are valid and not already spent
Step 5 of running the Bitcoin network makes up a big part of the user security model. Bitcoin users can accept a Bitcoin node’s confirmation that a transaction they have broadcast has been accepted and is considered valid by a majority of block writers. This removes any need for users to wait on block confirmation for the transaction’s timestamp to be officially recorded, allowing for almost instant transaction clearing and settlement.
This instruction clearly outlines the node’s need to validate the contents of the block against its own knowledge of what exists on the ledger, and of the rules in place governing the protocol. If a node receives a block that contains a transaction that is invalid, it cannot be accepted as valid. For example, if it receives a block that contains a transaction that spends an already used output, this transaction is invalid and the block must be rejected, ensuring that spendable outputs on the ledger can only be used once.
Similarly, nodes will always reject a transaction that attempts to re-spend a used input regardless of whether the first seen transaction is already in a block or not. In this way, if a transaction’s input is already used, the Bitcoin user should see a response from at least one node to indicate that the newly introduced transaction was rejected as a double spend. If this ever happens, the user can immediately know that something is wrong with the transaction. This can happen occasionally due to user error or platform design and nodes have robust processes in place to quickly disconnect nodes and any other network peers that are trying to propagate double spends.
Step 6: Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash
As soon as a node has received and validated a new block from one of its competitors, it is incentivised to build its new block template using that block’s hash. This has the effect of each subsequent block being added into a chain of valid proof of work.
This hyper awareness will have the effect of reducing the potential of orphan races, making the network more efficient and reducing the amount of work done producing valid blocks that don’t form part of the longest valid chain of proof-of-work.
Keep in mind also that nodes have the freedom to reject blocks on any basis, and it might eventuate that a group of nodes on the network determine that a particular subset of nodes are not following lawful order to generate a correction on the ledger.
Nodes follow Nakamoto Consensus which is used to set and act upon any rules agreed to by the operators of that group of nodes. Bitcoin’s traceability and incentive structure produces outcomes where the most honest, lawful action is the most profitable in the long term.
An introduction to Bitcoin infrastructure
If you’re interested in more in-depth knowledge on how to run the Bitcoin network most efficiently, you’re sure to benefit from the BSV Academy’s introduction to Bitcoin Infrastructure course.
This certificate course is focussed on providing students a solid understanding of the role that nodes and node operators play in the construction of the network. In particular it focuses on the incentives that drive enterprise operators to spend large sums of money to build and operate their infrastructure.
To sign up for this free course, head over here.
