Bitcoin Infrastructure - The Instructions

Section 5 of the Bitcoin white paper defines the network's protocol specifications stipulating the one and only type of node found in Bitcoin. These nodes are often referred to as miners, and are characterised by an ability to produce blocks, distribute blocks to peers (other nodes), and validate received blocks.

Merely running the open source Bitcoin SV node software does not make a machine a Bitcoin node. If the system is not upholding the consensus mechanism of the network based on block publication and proof-of-work, it’s not a node.

Read: The difference between a Bitcoin node and a miner

In Bitcoin’s initial stages, a home computer could act as a node producing valid blocks by performing the proof-of-work (PoW) process using a desktop grade CPU. As the difficulty of the PoW increased, GPUs and then Application Specific Integrated Circuits (ASICs) became necessary equipment to remain competitive.

As bitcoin scales, the difficulty of the PoW and transaction throughput of the network increases. This makes it necessary to invest in specialised hardware and systems including server grade systems and high bandwidth network interfaces to validate the transactions that are included in each block, as well as large numbers of networked ASIC hashing machines to perform the energy intensive process of proof-of-work process.

Most nodes typically run software called "bitcoind" however there is no requirement to use any specific software. Nodes can run whatever software allows them to participate in the network by producing valid blocks.

More details about the system architecture of the Bitcoin SV node can be found here.

Read more about the Bitcoin network here.

The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work. This timestamping function is the main role of nodes on the network. It is their job to collate, validate, process and store all of the actions taking place on the network globally and in real-time by placing them into blocks which are then added to the chain via the competitive proof-of-work process. With each block added to the chain, winning participants are awarded payment.

Bitcoin uses a proof-of-work system in the process of mining. In order for a block to be accepted, the broadcasting node must demonstrate valid proof-of-work which covers all of the data in the block.

1. The proof-of-work algorithm attempts to solve a puzzle with a low probability of success per trial.
2. A miner uses a candidate block header as the input hashes it, then checks whether the hash value is below a target. If it's not, the miner changes the nonce in the block header and hashes it again. Once the miner finds a hash value below the target, validates the block, distributes the block to the rest of the miners on the network, and then those miners start the proof-of-work process again referencing this blockhash in their new header template, the block has been successfully mined.
3. The difficulty of this process is adjusted to limit the rate at which new blocks can be generated by the network. Due to the very low probability of successful generation, it is impossible to predict which node will generate the next block.
4. The low probability of successfully finding valid proof-of-work solutions reduces the likelihood that two or more miners generate a block around the same time.

Proof-of-work is a function of a node operator’s ability to invest in the network and acts as a means for other nodes to ensure that the information they are receiving was validly generated by another node. In this, it acts as a gating function applying an up-front cost to any attempt to suggest a new block.

This cost incentivises nodes to participate honestly; only proposing honest blocks. Importantly, proof-of-work does not prevent anyone from spinning up a node, or trying to extend the chain. However, it means that anyone wanting to participate must invest in the network and the infrastructure needed to maximise their chance of success.

Steps to running the Bitcoin network

Section 5 of the Bitcoin white paper, titled ‘Network’, outlines a list of instructions that nodes must follow to correctly operate the Bitcoin network.

The steps to run the network are as follows:

1. New transactions are broadcast to all nodes.
2. Each node collects new transactions into a block.
3. Each node works on finding a difficult proof-of-work for its block.
4. When a node finds a proof-of-work, it broadcasts the block to all nodes.
5. Nodes accept the block only if all transactions in it are valid and not already spent.
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.

By collectively following these instructions, nodes are incentivised to find ways to develop their own competitive advantage, and by doing so, their investments in hardware and network infrastructure allows the network to scale efficiently. The network's incentives are structured such that the most honest, open, and capable participants are the most likely to be rewarded.

When trying to understand these instructions, it helps to think of the system operating on a global scale, managing many billions of transactions per block. By having this understanding in mind, it becomes very easy to understand why there is a strong drive to follow the instructions strictly.

The network is designed like this so attacks are not economically viable and thus unsustainable.

Step 1: New transactions are broadcast to all nodes

This instruction states that “New transactions are broadcast to all nodes”. This instruction translates to the following main behaviours:

• If the transaction came from one node, it should not be sent back to that same node.
• If a node is aware 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 is aware that another node has not received a transaction it has, the node will send it.

Nodes operate in a very dense ‘small world’ configuration which constitutes the centre of the Bitcoin network. As a result they have awareness of which peers represent other active block building nodes.

It is important for nodes to ensure that every other node on the network has knowledge of every transaction, as it is the precursor step to telling other nodes the positional index of the transaction in the node’s block template. Selfishly, this may sometimes mean nodes have knowledge of transactions they don't intend to timestamp, and sending them to any other nodes that don’t have them in the interest of making the propagation of a found block, i.e. adding a new block to the blockchain and earning the reward for doing so, more efficient.

The economic incentives that drive nodes to comply with this instruction ensure nodes can

a) validate another node’s proposed block quickly, and

b) have any blocks they discover validated by other nodes as quickly as possible.

Learn more about Bitcoin’s Small World Network here.

Step 2: Each node collects new transactions into a block

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 the additions 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.

There is a process of checking that transactions are valid before appending them to the node’s Merkle tree. It is important to note that the merkle tree representation is dependent on the ordering of the transactions. The ordering is the individual node’s record of the events coming in from the network. If a node successfully wins a block, its Merkle tree will become the officially recognised timestamped order of events on the public ledger.

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

Learn more about UTXO’s here.

In this animation we can see how even though each node sees the same set of transactions, their Merkle trees are all different, as they saw and processed the transactions in a different order.

The node performs a few baseline rule checks before passing the transaction to the process that builds the Merkle tree (covered in our next chapter). The ordered list of transactions plus the block header is the full block data. Each time a new version of the Merkle tree is created, the node must renew its block header - updating the Merkle root each time new transactions are added.

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 (Application Specific Integrated Circuit) or ‘hashers’, and is typically governed by an intermediate control system called a ‘Pool Miner’. 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 attempt to solve a puzzle by performing the process of ‘hashing’ a provided block header -- modifying and iterating through nonce (number used once) values within the block header -- until they find a block header that hashes to a number less than a specified target number (difficulty target). The block templates to which have been hashed the most have the highest probability of being valid.

Each puzzle has a random outcome, and the frequency of solutions found, the block discovery rate, is ‘self tuned’ by the network to stay as close to 10 minutes as possible. The 10 minute block interval keeps the number of orphan blocks low, while still giving ample opportunity (2016 possible blocks every 2 weeks) for nodes to compete in the process of ordering the ledger.

Read more about orphan blocks here.

10 minutes was chosen as having longer block times would result in fewer competing nodes, while shorter block times would result in more orphan races. This means there are approximately 2016 blocks added to the Bitcoin blockchain every 2 weeks, creating a cap on the number of block winning nodes.

The valid hash puzzle is a type of impediment that makes it impossible to generate valid block proposals for anyone without access to hashers providing an extremely simple means by which nodes can determine whether they are talking to another node. A node wants to know who the other nodes in the network are so that they can efficiently share transactions and block announcements. The act of winning a block shows that a particular node is a valid competitor. In the not too distant future, it's likely nodes will establish high bandwidth, low latency communications with each other to optimise communication.

proof-of-work (PoW) is designed to ensure that only node operators who have invested significant time and money in equipment and infrastructure can participate in the network. This significant investment also ensures node operators are easily identifiable enterprise level actors who are required to process transactions as a corporate activity under law.

The Bitcoin network is considered financial infrastructure, and as such the maintainers and operators of that infrastructure will be accountable for how it is managed and used. Finding a valid solution for the hash puzzle as part of PoW is indeed an energy intensive process; however, this energy expenditure is independent from the overhead needed to gather and validate the transactions in each block. This means that as Bitcoin scales, its per-transaction efficiency increases.

For example, if the difficulty stays the same but transaction throughput increases by a factor of 10, then the same amount of proof-of-work can secure 10 times as many transactions. This however, is where additional investments in memory, network connectivity, and storage are necessitated by the nodes to handle the UTXO set.

It can be said that the network must trend towards a scenario where the outcome is such that the total energy spent per transaction on proof-of-work is worth a tiny fraction of the fee paid on that transaction. With Bitcoin’s micro fees, this would typically represent a very small amount of energy. This outcome takes some time to eventuate, but is borne from the economic incentives behind proof-of-work and the mining process.

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’.

Read about the first see rule and orphan race here.

When analysing this directive, it is important to also look at what is in a block so 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.

Again, it can be said the system will trend towards having nodes that are not just exceptionally well connected, but also actively share their computed block and other transaction lists with as many other nodes as possible to ensure they have the knowledge needed to accept and validate any proof-of-work solution extremely quickly.

This incentive to share information will be the primary impetus for increasing the density of the ‘small world network’ that forms in the centre of the overall network, and will be a huge driver influencing a node operators’ expenditure on networks and research and development into faster and more effective ways to connect.

Step 5: Nodes accept the block only if all transactions in it are valid and not already spent

This is a big part of the user security model. Allowing Bitcoin users to accept a node’s confirmation that a transaction they have broadcast has been accepted and is considered valid by a majority of block producers, removes any need for users to wait on block confirmation for the transaction’s timestamp to be officially recorded; enabling 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 the rules in place governing the protocol. If a node receives a block that contains an invalid transaction, the block cannot be accepted as valid. For example, if the node receives a block that contains a transaction that spends an already used output, the transaction is invalid and the block must be rejected because spendable outputs on the ledger can only be used once.

The rule also defends against malicious actors who try to create invalid transactions on the ledger by ensuring nodes are incentivised to validate all transactions.

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 indicating the newly introduced transaction was rejected as a double spend. If this ever happens, the user is instantly made aware there is something wrong with the transaction. Although this can happen occasionally due to user error or platform design, nodes have robust processes in place to quickly disconnect any nefarious nodes or 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 means beginning the process of clearing validated transactions out of the mempool* and preparing the next block’s Merkle tree. Doing any form of work on a superseded block becomes wasted effort as soon as another node's block proposal is disseminated and validated; creating the incentive to be hyper aware of other nodes and any blocks they discover.

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, 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.

*The mempool is a data structure containing the set of valid transactions that the node accepted but which have not yet been timestamped in a block.