The long-lasting block size dispute and the recent introduction of several new Bitcoin implementations highlighted that not all Bitcoin nodes apply the exact same rule – and, perhaps more important, that not all development teams apply similar policies when it comes to implementing these rules.
The development team behind Bitcoin Core, Bitcoin’s historic “reference client,” requires widespread community consensus before it implements rule changes such as raising the block size limit, while other changes are not held to the same standards.
Meanwhile, some Bitcoin forks, such as Bitcoin LJR, are generally accepted by the development community, while others, such as Bitcoin Classic, attract a lot of controversy. This is considered inconsistent by some.
But this difference can be explained. Certain rule changes, implemented in certain forks, impact the Bitcoin network very differently than others. Or more specifically: Certain rule changes impact very different layers of the Bitcoin network. And some of these rules changes can split the Bitcoin network while others cannot.
To clarify these differences, Bitcoin Core developer and Ciphrex CEO Eric Lombrozo recently proposed to tag the relevant layers in all Bitcoin Improvement Proposals. These are the four main layers on the Bitcoin network as specified in his BIP 123, and the respective importance of consensus on each.
The Consensus Rules
The consensus rules are Bitcoin's most important rules. They establish – among many other things – the amount of bitcoins included in the block reward, the mining difficulty, the type of proof-of-work required, and, indeed, the block size limit.
These rules are so important because they determine which blocks are deemed valid by full nodes. And if all full nodes apply the same consensus rules, it ensures they all maintain an identical copy of the blockchain.
If different nodes apply different consensus rules, however, they risk accepting blocks that other nodes reject. Such discrepancy could lead to different nodes maintaining completely incompatible versions of the blockchain, effectively splitting the Bitcoin network.
Bitcoin's consensus rules can be changed in two ways. A change that adds extra rules to the protocol (making previously valid blocks invalid) is called a soft fork. Soft forks require a majority of hash power to support the change. The blocks that are produced under the new rules would be valid under the old rules as well, so nodes that didn’t upgrade would still follow the longest chain.
However, non-upgraded miners might produce blocks that are invalid under the new rules, wasting hash power. And non-upgraded full nodes would no longer be able to verify whether blocks adhere to the new rules, requiring them to wait additional confirmations to achieve the same level of security.
For these and other reasons, the Bitcoin Core development team has said that it will typically require a super-majority of 95 percent of hash power to agree on soft forks.
A consensus rule change that removes rules from the protocol (making previously invalid blocks valid) is called a hard fork. A hard fork requires all full nodes on the network to adopt. Any node that doesn't implement the change might not follow the longest chain at all, as it could consider that chain invalid and stay on the “old” chain instead. This could split the Bitcoin network as described above. How long such a split would persevere is not really a technical question, but rather a debate on politics, sociology, economics, game theory and more.
Soft fork changes to the consensus rules without consensus could – in a worst-case scenario – cause a minority of miners to waste hash power, and (slightly) degrade the security of full nodes.
Hard fork changes to the consensus rules without consensus could – in a worst-case scenario – split the Bitcoin network.
Peer-to-Peer Layer
The peer-to-peer layer of the Bitcoin network covers how full nodes share data and what data they share. This includes protocol rules to send and receive transactions and blocks, as well as special data packages such as SegregatedWitnesses or Invertible Bloom Lookup Tables.
Most importantly, the peer-to-peer layer must ensure that new blocks find their way through the entire network, as well as data packages required to verify blocks. If this relay policy fails, it could result in a network split where different nodes hold different versions of the blockchain – at least until blocks find their way through the entire network again.
But as opposed to the consensus rules, it’s not necessarily a huge problem if not every single node applies the exact same relay policy. Since most nodes forward blocks to at least eight peers, this amplifier should ensure that all nodes receive all blocks even if some of them don’t forward properly.
Nodes have even more leeway when it comes to relaying transactions. Most nodes on the Bitcoin network today use a “first seen” policy: If they receive two or more conflicting transactions, they reject the latter. But a growing number of nodes apply variations of “replace-by-fee” policies, meaning they pick the transactions which include the highest fees – regardless of which came first. Additionally, some nodes reject certain types of transactions altogether, or don’t relay any transactions at all.
That said, miners ultimately decide which transactions they include in blocks, and why. It’s only when transaction relay policies vary wildly, or are sufficiently restrictive, that it might become unpredictable which transactions are confirmed for these reasons alone.
Changes to the peer-to-peer layer without consensus could – in a worst-case scenario – split the network. This risk exists if blocks can’t find their way throughout the whole network. The split will, however, automatically resolve once the network is reconnected.
If the changes concern transactions only, they could – in a worst case scenario – prevent certain transactions from confirming. It could also decrease the reliability of unconfirmed transactions. But it cannot split the network.
Application Programming Interfaces and Remote Procedure Calls
The Application Programming Interface (API) and Remote Procedure Call (RPC) layers are communications layers on top of the peer-to-peer protocol. Many Bitcoin software applications – such as mobile wallets and block explorers – communicate with the blockchain through these layers by connecting to an API or software library.
If one of these layers fails, all connected software applications will be unable to reliably communicate with the Bitcoin network. Mobile wallets won't know if they received Bitcoin, and blockchain explorers can't tell whether a new block was found. However, all other Bitcoin users won’t notice a thing; the network itself is still running fine.
Changes to the API and RPC layers without consensus could – in a worst-case scenario – completely disconnect users of these layers from the Bitcoin network. But such changes cannot split the network itself.
Applications
Last, the application layer refers to how Bitcoin software applications create and use certain types of data that doesn’t really touch the network directly, but that is useful to synchronize across applications.
This includes, for example, address formats, private keys generation or wallet back-ups. If one wallet generates an address that another wallet doesn't consider valid, transacting between them will be impossible. Or if one wallet uses one method to create a backup address seed, and another wallet uses another, users can't recover their private keys with each wallet. The same goes for wallet backups.
Changes to the application layers without consensus could – in a worst case scenario – prevent some users from mutually transacting, and cause other inconveniences. Such changes cannot split the network. Thanks go out to Lombrozo for technical guidance.