Bitcoin is not strictly BFT; it is a probabilistic consensus that trades computational-power assumptions for openness

Bitcoin’s consensus mechanism is not a strict Byzantine Fault Tolerant State Machine Replication (BFT-SMR) protocol in the traditional sense. Rather, it is a probabilistic, asynchronous approximation. This distinction stems from Bitcoin’s pursuit of openness to the greatest possible extent: any node can freely join or leave the network, which directly invalidates the assumptions of a fixed membership and synchronous communication on which classical BFT protocols depend. To withstand Byzantine faults in an open environment—or, more precisely, to achieve Sybil resistance—Bitcoin replaces traditional security assumptions with assumptions about computational power. The key to this shift is establishing a strong link between computational power and actual computational work, a principle rooted deeply in computational complexity theory. Under the Random Oracle Model (RO), the protocol treats the number of hash queries as its unit of resources and assumes that each query produces an independent, uniformly distributed output. In this idealized setting, the probability of finding a valid proof of work (PoW) is determined entirely by the network difficulty, so an attacker’s query budget directly limits the amount of valid work they can produce. No matter how many fake identities an attacker creates, they cannot exceed this computational budget, thereby establishing Sybil resistance. The real world, however, is not an ideal RO model. Outside this abstract framework, the protocol must rely on concrete computational hardness assumptions to quantify an attacker’s ability to accelerate computation. This is where Fine-grained Complexity becomes crucial: we need quantitative guarantees about computational costs, and the efficiency gap between honest algorithms and optimal attack algorithms directly determines the maximum proportion of malicious resources the protocol can tolerate. Work based on Beacon in 2024 took this approach further in constructing PoW: Beacon provides random material for generating new challenges at regular intervals, and the security of the construction is supported by computational hardness assumptions rather than relying solely on the unpredictability of the hash function.

The key to turning computational work into consensus security lies in defining the nature of a chain and how it binds to the historical record. In the classical BFT-SMR abstraction, the protocol aims to establish a total order of operations. Each honest node locally determines a log prefix that can be committed based on protocol messages, and consensus guarantees that these local decisions are compatible. In this setting, the sequence number directly represents the order in which operations are executed, because the protocol guarantees that the content committed at each position is consistent. In Bitcoin, however, a chain is an ordered representation of history built through computational work, so it must be specified which part of history each proof of work supports. Merely assigning a block a height is not enough to determine where it belongs: which block at height 99 does a block at height 100 follow? This determines which historical branch it inherits. Bitcoin includes the previous block’s hash (Previous Hash) in the PoW input, forcing each block to explicitly reference its parent. Following these hash references back to the genesis block uniquely identifies the entire history inherited by that block and defines its height within that history. The Previous Hash mechanism organizes independent mining work into a chain, binding each proof of work to a specific historical branch and allowing work on the same branch to accumulate.

This binding mechanism also determines how the chain is extended and provides resistance to pre-mining. Suppose the current chain tip is at height h. To extend the chain, a miner must mine the next block using that block’s hash as input. If they instead use the hash of the parent at height h-1, the result will be a competing branch at height h and will not increase the length or cumulative work of the current main chain. To inherit the work accumulated by the current longest chain, miners must continue computing from that chain’s tip. This mechanism entails an important security constraint: malicious nodes cannot gain an additional advantage through prediction or pre-mining. In the RO model, the hash of a specific block that has not yet been produced cannot be predicted effectively, so work on its successor cannot be prepared in advance either. An attacker may pre-mine their own fork, but once honest nodes produce a new block, the attacker cannot transfer their pre-mined work to build on that block and inherit its latest work. To inherit the work of the latest block, the attacker must compute in real time from the current chain tip. This property ensures that proofs of work are timely and non-transferable, preventing the hoarding of resources from distorting the consensus process.

From a high-level perspective, Nakamoto consensus connects computational complexity, cryptography, and distributed computing into a coherent chain of reasoning. Computational complexity provides a quantitative basis for the cost of work, ensuring that an attacker must expend resources proportional to those of honest nodes to influence consensus. Cryptography constructs publicly verifiable proofs of work and demonstrates that these proofs retain the corresponding computational costs even in scenarios involving maliciously chosen inputs, preprocessing, and reuse, thereby preventing proofs of work from being forged or reused inefficiently. Distributed computing, in turn, specifies the synchronous network and adversary model, and designs the chain selection rule (the longest-chain rule) and confirmation mechanism, converting resource constraints into fault-tolerance capabilities within the BFT-SMR framework. The system’s core logic is to translate the attacker’s share of computational resources into fault constraints that a distributed protocol can handle, and then establish consensus on that basis. Bitcoin’s success ultimately does not depend on whether it can achieve absolute Byzantine fault tolerance, but on whether it can continue to maintain the validity of its computational-power assumptions and a stable mapping between computational cost and consensus security in an open, decentralized environment. As hardware becomes more efficient and the distribution of computational power changes, the stability of this mapping will face ongoing challenges. Yet its underlying principle—exchanging computational cost for trust—remains one of the most resilient architectural foundations in today’s decentralized monetary systems.

Follow me so you don’t miss the next quick market read.