The “longest chain” rule is a fundamental principle in blockchain consensus that helps decentralized networks agree on a single transaction history.
%2Fimages%2Fimage1.png&w=3840&q=75)
The “longest chain” rule was introduced with Bitcoin as part of Satoshi Nakamoto’s design to solve the double-spending problem in a peer-to-peer network.
In simple terms, this rule dictates that nodes should recognize the longest (or heaviest) valid blockchain as the canonical one. By relying on Proof-of-Work, the longest chain is presumed to have the most computational work invested, representing the “majority decision” of the network.
What Is the Longest Chain Rule?
The longest chain rule refers to a consensus rule that a blockchain network’s nodes follow in choosing the valid blockchain: whichever chain of blocks has the most cumulative work (often manifesting as the greatest length) is considered the authoritative ledger.
In practice, this means all honest nodes adopt the same longest chain as “the truth,” ensuring consensus on transaction history across the distributed network. It’s not merely about block count – it’s about which chain requires the most computational effort (work) to produce.
Each block added requires a significant amount of hashing power, so a longer chain indicates more total work.
This rule is a cornerstone of the Nakamoto Consensus—the consensus mechanism behind Bitcoin—aligning network participants to one consistent history without any central authority. By following the longest chain rule, the Bitcoin network achieves a single source of truth that all nodes agree upon despite operating in a trustless, adversarial environment.
Key Concepts in this Context:
- Blockchain: an append-only ledger of transaction blocks, linked by cryptographic hashes.
- Proof-of-Work (PoW): the mechanism requiring miners to perform costly computations (hashing) to create a valid block. PoW makes creating each block difficult, so a chain of many blocks represents a huge cumulative effort.
- Nodes: computers running the Bitcoin protocol. Full nodes verify blocks and transactions and enforce rules like the longest chain rule.
- Chain Length vs. Work: “Longest” is conceptually about length, but practically means the chain with the greatest total accumulated work (also called the “heaviest” chain). Bitcoin nodes calculate a value called chainwork to measure this. This ensures the chosen chain truly reflects the most PoW, not just the most blocks.
How Does the Longest Chain Rule Work in Bitcoin Mining?
This section explains the mechanics of the longest chain rule in action – how Bitcoin nodes build the blockchain and decide which chain to follow at any given time. Understanding this process will clarify how the network remains synchronized and resolves conflicts (forks) when they occur.
Blockchain Growth and Chain Selection
Bitcoin’s network operates in rounds of block creation and propagation. The basic process is as follows:
- Miners Create Blocks: Miners gather pending transactions into a new block and expend computing power to solve a cryptographic puzzle (the PoW). Each block references the hash of a previous block, linking it into a chain.
- Block Broadcast: When a miner finds a valid block (i.e., a hash below the difficulty target), they broadcast it to the network. Full nodes that receive the block validate it (checking that all transactions are valid and that the PoW meets the required difficulty).
- Node Adds Block to Blockchain: If the new block is valid and extends the node’s current active chain (the chain the node currently considers best), the node appends the block to that chain. This becomes the new “tip” (latest block) of the blockchain for that node, and the block’s transactions are now considered confirmed.
- Fork Handling: If a new block does not extend the current chain – for example, it creates a divergent branch (fork) at some earlier block – the node doesn’t immediately discard it. Instead, the node compares the total work of the new block’s branch to that of its current chain
- If the new branch’s cumulative work exceeds the current chain’s work, this branch is now the longest (heaviest) chain. The node will reorganize: it switches to this new chain as the active chain, adopting those blocks as the new history. The formerly accepted blocks that are no longer on the main chain become orphaned (or stale) – more on this below.
- If the new branch has less or equal work compared to the current chain, the node keeps its current chain as is and just stores the new block in case it grows longer later. In other words, nodes remember forked blocks but stick with the heaviest chain until a fork proves itself longer.
Through this process, every node independently applies the longest chain rule: always work on and extend the chain with the most accumulated proof of work. This way, even if some nodes see different blocks first (causing momentary disagreements about the tip of the chain), they all have a consistent rule to decide which history to eventually accept.
Example: Competing Blocks and Fork Resolution
To illustrate, imagine two miners find a block at nearly the same time, creating two competing versions of the blockchain (Fork A and Fork B). Some nodes receive Block A first and start mining on that chain, while others receive Block B first and do likewise. At this point, there is a temporary fork – two chains of equal work. According to the longest chain rule, there’s no final winner yet, so nodes simply keep track of both. They will follow whichever chain gets the next block first:
- If a miner adds another block on top of Fork A, that chain now has more work (longer length) than Fork B. All nodes will then switch to Fork A as the main chain, because it’s now the longest chain. Fork B’s latest block, having lost the race, is dropped (orphaned) from the main history.
- Conversely, if Fork B gets the next block first, nodes adopt that chain and Fork A’s last block becomes orphaned.
This tie-breaking process ensures that forks are resolved quickly and the network converges back to a single chain. Nodes that were temporarily on the “losing” fork will automatically catch up by downloading the blocks from the winning chain. The protocol is designed such that the probability of extended forks is very low; as more blocks are added on one side, the chance of the shorter fork catching up diminishes exponentially.
In practice, Bitcoin’s 10-minute block interval (on average) combined with fast block propagation makes it rare for a fork to persist beyond one extra block. Usually, any split is resolved within one block interval, and there is once again a clear longest chain that all honest nodes accept.
Active Chain vs. Block Tree
While the network conceptually maintains one blockchain, under the hood each node actually maintains a block tree of all known valid blocks.
This tree includes the main branch (active chain) and any side branches (from past forks that didn’t become the longest). The longest chain rule guides the node in choosing one path through this tree as the active chain (from the genesis block to the current tip).
All blocks not on that chosen path are effectively disregarded for transaction history (though they remain stored in case a reorg is needed). This means there isn’t always one “right” chain at every moment – different nodes might briefly have different views – but the rule causes those views to coalesce into a single chain soon after.
The design ensures that eventually all honest nodes agree on which path is the longest (most work) and thus should be the accepted history.
Why Is the Longest Chain Rule Important for Bitcoin Security?
The longest chain rule is vital because it anchors the security and consistency of a decentralized ledger.
- Ensuring One Global Truth: In a distributed network with no central authority, conflicting information can arise (e.g., two miners create different blocks). The longest chain rule provides a deterministic way for all nodes to agree on one history. By having every participant adopt the chain with the most Proof-of-Work, the system achieves eventual consensus on which transactions are confirmed and which are not. This solves the synchronization problem—i.e., how to keep all independent nodes in sync about the state of transactions. Each new block extending the longest chain reinforces that shared history.
- Preventing Double Spending: A double spend attack is when someone tries to spend the same coins in two different transactions. Without a rule to prefer one chain, an attacker could try to fork the blockchain and have one transaction confirmed on each branch. The longest chain rule thwarts this by only allowing one branch to survive. If two conflicting transactions compete, only the one on the longest chain will end up valid. The other transaction on a shorter fork will be dropped once that fork is abandoned. In essence, only one of the double-spend attempts can win, and honest miners will extend the chain containing the legitimate transaction, making it the longest. For an attacker to successfully double spend, they’d have to somehow make their fraudulent chain grow faster than the honest chain – an extremely difficult feat without majority hash power (as discussed in the security section below). Thus, the longest chain rule is a core part of Bitcoin’s defense against fraud.
- Trustless Consensus: The rule enables trustless operation. You don’t have to trust any single miner or node – as long as you follow the longest chain, you are following the collective “decision” of the majority of computing power. Honest nodes will always contribute to and follow the chain with the greatest cumulated proof of work, so that chain effectively represents the agreement of the decentralized network. New nodes joining the network or nodes coming back online can simply download blocks and identify the longest chain (by total work) to know the current valid ledger. This removes the need for any centralized authority to tell nodes which transactions or blocks are valid.
- Network Stability and Recovery: The longest chain rule also allows the network to recover from splits or delays. If part of the network goes offline or if there’s a temporary communication delay causing a fork, once connectivity is restored all nodes reconcile by accepting whichever chain has grown the most. This property was highlighted by Satoshi: nodes can leave and rejoin, and on rejoining, they accept the longest chain as proof of what happened while they were gone. This makes the system robust; it can heal itself and reach consistency even after network partitions or outages, as long as honest nodes eventually share their mined blocks.
In summary, the longest chain rule is important because it underpins consistency, security, and trust minimization in Bitcoin. It leverages the competitive work done by miners to organically decide the valid chain, aligning everyone to one record of transactions. Next, we delve into what happens when the rule is tested by network forks or malicious actors, and how it holds up in those scenarios.
Forks and Orphan Blocks: The Rule in Action
Even with the longest chain rule in place, the Bitcoin network can experience forks – situations where there are temporarily multiple candidate chains.
What Causes a Fork?
Most forks in Bitcoin are unintentional and arise from network latency or coincidence. If two miners solve a block at nearly the same time, each block will reference the same parent (previous block) and both will start circulating through the network. Different subsets of nodes might see different blocks first, leading the network to temporarily have two chains of equal length (with different last blocks). This is a mining race condition, not a protocol failure. Forks can also occur if a miner extends a block that some nodes haven’t received yet (due to propagation delay), or theoretically if someone deliberately attempts to create an alternative chain. Regardless of cause, at the moment of a fork the network lacks a single longest chain — there are competing chains of equal work.
Orphan Blocks (Stale Blocks) Explained
An orphan block is a valid block that is not part of the final longest chain. In our example of two simultaneous blocks, once one chain wins by getting another block on top, the block(s) in the losing chain become orphaned. They are “orphans” in the sense that their parent chain was not continued by the majority of miners, so they don’t have children in the main chain. Orphan blocks (also called stale blocks) are not included in the accepted ledger history, even though they were perfectly valid when mined.
Important points about orphan blocks and their handling:
- Transactions in orphaned blocks are usually not lost. If a transaction from an orphan block isn’t found in the winning chain, it returns to the mempool (transaction pool) of nodes and can be included in a later block. This ensures that a transaction will eventually be confirmed even if its first inclusion was on a stale fork.
- The miner of an orphan block misses out on the block reward since their block isn’t in the main chain that the network recognizes. This creates an incentive for miners to follow the chain most likely to succeed (they want their blocks to end up on the longest chain to earn rewards).
- Orphan blocks are a natural occurrence and are typically resolved quickly. In Bitcoin’s network, forks are usually only one block deep. The protocol’s design (10-minute block time, fast block relay, etc.) keeps the orphan rate low. Bitcoin’s orphan block rate is on the order of 0.1-1% in normal conditions, meaning the vast majority of mined blocks become part of the longest chain.
Fork Resolution and Network Convergence
The longest chain rule dictates how forks resolve: the fork that accumulates more Proof-of-Work will become the official chain, and the other will be abandoned.
This was described earlier in the example – basically, whichever chain gets the next block first will pull ahead and be adopted by all nodes. This rule guarantees that forks do not persist indefinitely: one chain will eventually outpace the other. The protocol doesn’t require explicit communication to resolve forks; each node independently switches to the longer chain when it learns of it.
This decentralized fork resolution is a key aspect of Bitcoin’s consensus. It may result in a brief period of uncertainty (until a new block arrives to break the tie), but it ensures that all nodes end up agreeing on one history without manual intervention.
From a user perspective, forks and orphan blocks are usually invisible. They might manifest as a transaction taking an extra block to confirm if it was in an orphaned block initially, but otherwise the system handles it behind the scenes.
However, understanding forks is important because it reveals the probabilistic nature of Bitcoin’s finality: a transaction is more secure the deeper it is in the longest chain (e.g., “6 confirmations” is a common rule of thumb for strong confidence) – that’s because with each additional block, the chance of a fork that reorders transactions becomes vanishingly small.
Impact of Orphan Rate on Security
While occasional orphan blocks are expected, a high rate of orphan blocks can be a concern. If network conditions or protocol parameters caused frequent forks, the blockchain’s growth (in terms of confirmed blocks) would slow down, and an attacker would find it easier to compete. For example, if half of all mined blocks ended up orphaned due to extreme network lag or overly fast block times, the effective growth rate of the main chain would be much lower. In that scenario, an attacker controlling significantly less than 50% of the hash power could still sometimes build a chain that overtakes the sluggish honest chain.
An analysis shows that if 50% of honest blocks are orphaned, an attacker with only ~34% of total hash power could maintain a competing chain and potentially pull off double-spend attacks. This is why Bitcoin’s protocol parameters (block time, block size, etc.) are tuned to keep orphan rates very low.
Longer block times (10 minutes) relative to network propagation times give miners a chance to hear about the latest block before finding the next, thus reducing split-chain situations. In contrast, a blockchain with very fast block generation (e.g., Ethereum’s ~12-second blocks) experiences more frequent uncles/orphans, which require adjustments to the consensus mechanism (like Ethereum’s GHOST protocol) to maintain security.
Bottom line: The longest chain rule works hand-in-hand with network design to minimize orphan forks. When forks do happen, the rule cleanly resolves them, and the occasional orphan block does not undermine trust in the system. Users and nodes can rely on the fact that eventually one chain will win out, and that is the ledger everyone accepts.
Is the Longest Chain Rule Secure?
The security of the longest chain rule is a critical aspect, as it underlies Bitcoin’s claim of being a secure, trustless system. Here we analyze how secure this rule is, what assumptions it depends on, and what potential attacks or edge cases exist.
Security Assumptions and the 51% Threshold
The longest chain rule’s security rests on an assumption: honest miners control the majority of the network’s computing power.
“Honest” in this context means miners following the protocol – they accept and extend the longest valid chain, and they do not attempt to defraud others by rewriting history. As long as this majority assumption holds, the rule ensures that honest chain growth outpaces any malicious effort to create an alternative chain.
If an attacker (or colluding group of attackers) wants to undermine the chain rule, they would need to command more hash power than the rest of the network combined (i.e., >50%). This is commonly called a 51% attack scenario.
-
Attacker with < 50% Hash Power: If an attacker has less than half the total mining power, the longest chain rule makes it extremely unlikely for them to beat the honest chain. Suppose the attacker tries to secretly create their own fork of the blockchain (for example, to double spend coins), while honest miners continue on the public chain. The honest chain will grow faster on average, since honest miners collectively mine more often than the attacker. With each new block added to the honest chain, the attacker falls further behind. The probability that a slower (minority) attacker could catch up and surpass the honest chain decreases exponentially with every block that gets added to the honest chain. Satoshi’s whitepaper includes a calculation showing that even with 10% or 30% of the hash power, the chances of ever overtaking the main chain become astronomically low after a few confirmations. Therefore, under this assumption, the longest chain rule is very secure: attackers are essentially racing against a faster competitor, and the odds are stacked against them.
-
Attacker with ≥ 50% Hash Power: If an attacker does acquire the majority of hashing power, the security guarantees break down. Such an attacker can consistently outrun the honest miners and extend their own private chain faster than the public one. Eventually, their chain will become the longest, and when they release it to the network, honest nodes will accept it (since it follows all rules and has the most work). This could enable double-spending attacks or other history rewrites at will.
In this worst-case scenario, the longest chain rule would faithfully do what it’s supposed to – accept the longest chain – but that chain would be attacker-controlled. The entire security model of Bitcoin thus hinges on the economic and practical improbability of a 51% attack on a large network (acquiring that much mining power is extremely expensive and detectable, and honest miners have every incentive to defend the chain). So, while the rule itself doesn’t prevent a majority attack, the design aims to make such attacks infeasible.
Transaction Finality and Confirmations
Because the longest chain rule is probabilistic (relying on random PoW races), Bitcoin does not have instant finality on transactions. Instead, security grows with each additional block that buries a transaction. A transaction in the latest block is confirmed, but not finalized – there’s a small chance that block could become orphaned if a competing chain overtakes it. However, as more blocks are added on top, the probability of that transaction being reversed becomes negligible.
This is why wallets and exchanges often wait for, say, six confirmations (approximately 1 hour in Bitcoin) for large transactions. Six blocks deep, the work required for an attacker to invalidate a transaction is colossal, assuming they don’t have majority hash power. In essence, the longest chain rule provides eventual consistency: given a bit of time, you can be confident the blockchain state won’t be reorganized. It’s a trade-off – high security and decentralization at the cost of immediate finality.
Historical and Theoretical Attacks
Bitcoin’s early history actually exposed the subtlety between “longest chain” and “most work.” The initial implementation literally used the longest chain by block count as the selector, which was later recognized as a potential weakness.
For instance, an attacker could produce many tiny-Proof-of-Work blocks (by manipulating difficulty) that outnumber the honest chain’s blocks while having less cumulative work.
This was quickly fixed by switching to a chainwork comparison – i.e., the node evaluates which chain has the greatest total difficulty (work) and uses that, rather than just counting blocks.
This fix, made early in Bitcoin’s development, closed off attacks that exploit the “length” terminology. Modern Bitcoin implementations store and compare a cumulative work tally for each chain fork. Thus, when we say longest chain, we truly mean the heaviest chain by work, not necessarily the one with the most blocks.
Another theoretical attack related to the longest chain rule is selfish mining, where a miner with significant hash power withholds blocks to try to get a lead on the public chain.
If done successfully, they might create a situation where they reveal a longer chain and cause others to waste effort on what becomes orphaned blocks. Selfish mining doesn’t break the longest chain rule itself; rather it’s an attempt to game the block distribution process. Research has shown that if a miner has less than 1/3 of the hash power, selfish mining is not profitable under normal conditions, and protocol adjustments can raise that threshold further. The takeaway is that the longest chain rule has been resilient, but it must be understood in context with mining incentives and network parameters.
Overall, the longest chain rule has proven secure in Bitcoin’s real-world operation because the economic incentives align miners to follow it, and no attacker has approached the power needed to consistently defeat it. As Bitcoin’s hash power and decentralization grew, the network became extremely robust against minority attacks.
Longest Chain Rule in Bitcoin’s Technical Implementation
For more technically inclined readers, this section looks at how Bitcoin Core implements the longest chain rule under the hood.
We explore the data structures and algorithms that ensure every node selects the correct chain, illustrating the interplay of difficulty, chainwork, and block organization in the software.
Chainwork: Measuring Cumulative Proof-of-Work
Bitcoin Core uses a metric called chainwork to decide the best chain. Chainwork is essentially a number representing the total expected hashes (work) expended on a given blockchain branch.
Each block header stores a nBits field, encoding the difficulty target of that block. From this, the software can calculate the work that the block represents (roughly, higher difficulty = more work per block). When a node validates a new block, it computes that block’s work and adds it to the cumulative work tally of the chain that the block extends. Thus, every possible chain (fork) has an associated total chainwork value.
The longest chain rule in code is executed by comparing these chainwork values:
- The node keeps track of the “tip” with the highest chainwork seen so far (this is the tip of the active main chain).
- When a new block comes in, the node determines where it fits (e.g., next on the current tip, or extending some earlier block creating a fork). It then updates the chainwork for that branch.
- If the new block’s addition causes its branch’s chainwork to exceed the chainwork of the current main chain, the node realizes this branch is now the heaviest chain. At that point, it will trigger a reorganization to switch the active chain to this new branch. If not, the branch is kept in a side database (as a candidate fork) but not activated.
This algorithm ensures an objective comparison: even if one fork has more blocks, it won’t win unless those blocks collectively represent more work. For example, imagine one fork has 6 blocks of relatively low difficulty, and another fork has 5 blocks but at a higher difficulty (harder to mine). The chainwork calculation might show that the 5-block chain actually has more total hashes behind it. Bitcoin would consider that chain the winner, even though it has fewer blocks.
In summary, Bitcoin nodes always follow the chain with the greatest chainwork, which usually but not always correlates with the most blocks. The software’s longest chain rule is really a “most accumulated Proof-of-Work rule.”
(Technical note: chainwork is often computed as a large integer by summing up “work” for each block, where work can be defined as 2^256 / (target + 1). This isn’t something users see, but it’s tracked internally for consensus.)
The Longest Chain Rule in the Broader Crypto Ecosystem
Bitcoin’s longest chain rule (Nakamoto Consensus) pioneered a new class of consensus algorithms. This section places the concept in a broader frame, examining how it compares or interacts with other blockchain consensus approaches and how it has evolved or been adapted in different projects.
-
Widespread Adoption in PoW Chains: Many early cryptocurrencies and Bitcoin derivatives adopted the longest chain rule due to its success. For instance, Litecoin (a Bitcoin variant with a shorter block time) uses essentially the same mechanism. Bitcoin-inspired protocols like Bitcoin-NG (which introduces microblocks for performance) and other PoW networks also rely on longest-chain consensus. The reason is simple: it’s elegant and permits open participation. Any miner can join, and consensus emerges naturally from the competition of work. This frame of “competition-driven consensus” has proven robust and relatively easy to implement and reason about (compared to more complex voting-based algorithms).
-
Ethereum and GHOST (Heaviest Subtree): While Ethereum’s original version was also Proof-of-Work with the longest chain rule, it adjusted the formula to account for shorter block times. Ethereum implemented the GHOST protocol (Greedy Heaviest Observed Subtree), which is a modification of longest chain rule that considers not just the length of the main chain but also “omerged” blocks (orphans, called uncles in Ethereum) to determine chain weight. This can be seen as preferring the heaviest chain (counting certain orphan contributions) rather than strictly the longest. The rationale was to improve security under faster blocks by partially rewarding and including information from orphaned blocks, thereby reducing the incentive to ignore them and mitigating the risk of attacks due to high orphan rates. In essence, Ethereum’s tweak still follows the spirit of the longest chain rule – it chooses one chain to follow – but refines how chain “weight” is measured.
-
Heaviest Chain and DAG Variants: Projects like Conflux and PHANTOM/DAG-based ledgers take the longest chain idea a step further by using a directed acyclic graph (DAG) of blocks instead of a strict tree. Conflux, for example, doesn’t purely use the longest chain rule; it adopts a heaviest chain rule on a Tree-Graph structure, incorporating more blocks into the history rather than orphaning them. This can allow higher throughput (more blocks per second) because the system isn’t throwing away as many orphaned blocks; instead, it finds a way to include them in a combined order. These approaches still often have an ordering rule analogous to “longest chain” (like selecting the heaviest cumulative weight subgraph as the main ledger), showing how the core idea has influenced even newer designs. However, they also introduce new complexities and usually require their own security proofs. Notably, as of 2019, longest-chain had well-established security proofs, whereas some alternate approaches were still catching up in terms of formal verification.
-
Proof-of-Stake (PoS) Longest Chain Protocols: Interestingly, the longest chain rule concept isn’t limited to Proof-of-Work. Several proof-of-stake protocols use a longest-chain style selection, but with stake replacing work as the resource. For example, Ouroboros (Cardano) and Ethereum’s current PoS (after The Merge) can be thought of as adopting a “longest chain of valid attestations” rule, combined with checkpointing/finality gadgets. The common thread is that in an open network, having a simple rule like “follow the chain with X most weight” (where X could be work or stake) allows the system to be permissionless. Nodes don’t have to trust identities; they just look at the cryptographic proof (of work or of stake votes) in the chain. However, pure longest-chain PoS protocols face challenges like the “nothing at stake” problem, so in practice they often add twists to the basic rule (e.g., finality checkpoints in Ethereum’s PoS to prevent easy reorgs).
-
Comparison with BFT Consensus: In contrast to longest-chain, Byzantine Fault Tolerance (BFT) style consensus algorithms (used in permissioned or low-validator-count systems like Hyperledger, or delegated systems like Tendermint/Cosmos) achieve finality by explicit voting rounds. Those produce final blocks quickly (no probabilistic confirmation, it’s either final or not) and don’t allow forks under normal operation. The trade-off is that they require a fixed or semi-fixed set of validators and have complexity in coordinating votes. Longest-chain protocols like Bitcoin’s, by comparison, favor scalability in participants (anyone can mine), simplicity, and robustness at the cost of probability-based finality and eventual consistency. The two approaches represent different design frames in the blockchain space: Nakamoto-style (longest chain) vs Classical BFT-style consensus. Both aim to solve the same problem—achieving agreement despite faulty or malicious actors—but with very different techniques.
Frame Semantics – How It All Fits: Within the broader crypto ecosystem, the longest chain rule can be viewed as part of the “Nakamoto consensus frame,” which also includes Proof-of-Work mining, difficulty adjustment, and economic incentives. All these elements interact: PoW makes it costly to extend the chain, difficulty adjustment keeps block production steady, miners are incentivized to follow the rule for rewards, and the longest chain rule ties it together by making the cumulative work the arbiter of truth. Alternative frames (like PoS or BFT) replace or augment parts of this picture (e.g., stake replaces work, or voting replaces the implicit race). However, the longest chain rule remains a foundational concept that any blockchain enthusiast should understand, as it underlies not only Bitcoin but also many derivatives and informs the design of newer systems.
Conclusion
The longest chain rule is a deceptively simple idea with profound implications. It enables a network of thousands of independent nodes and miners to reach agreement on a single history of transactions without any central authority. By always choosing the chain with the most Proof-of-Work, Bitcoin ensures that the history with the greatest collective investment of energy (and honest effort) wins out, making it extremely resistant to tampering.