What must a network agree on?

The problem is more specific than keeping many copies of a database. Two transactions can each appear valid against the same starting state while being mutually incompatible.

In Bitcoin's unspent transaction output model, two instructions might attempt to spend the same output. In an account-based system, two competing instructions might use the same account nonce or depend on a balance that cannot support both. The network must determine which instruction, if either, enters the accepted history. Chapter 2 explained the accounting models; here the issue is coordination between independent observers.

A block groups proposed transactions with metadata used to verify and connect the history. Agreement cannot simply mean one vote per computer: an adversary can create many apparent participants. This is the Sybil problem. Proof of work and proof of stake attach influence to resources that are harder to multiply than online identities. They do not require every participant to trust a central membership administrator.¹

Three questions should remain separate:

Consensus mechanisms help establish agreement and progress under stated assumptions. They operate alongside rules defining valid blocks and transactions. Bitcoin nodes, for example, validate blocks and select among valid competing branches by accumulated proof of work. A branch does not become valid merely because someone devoted computing power to it.²³

In practice: two honest miners find competing blocks

Assume Alice owns one spendable output and broadcasts payment P to a supplier. Miner North and Miner South both build valid candidate blocks at the same height. North's block includes P; South's block contains other valid transactions. The miners find qualifying proof of work at nearly the same time, so some nodes initially see North's block first while others see South's.

Both blocks can be individually valid, but they cannot both occupy the same position in one accepted history. A third miner then extends North's branch. As that branch accumulates more work, nodes following Bitcoin's selection rules converge on it. P remains included. Transactions unique to South's displaced block can return to pending status and may be included later if they remain valid. If one conflicts with a transaction now accepted on North's branch, the conflicting transaction cannot also be accepted.

No attacker is required for this temporary fork. The example separates four events: valid block production, different initial network views, later branch selection and the resulting status of displaced transactions.

This separation matters operationally. A network can reject invalid transactions perfectly while becoming unavailable. It can keep producing blocks while lacking the level of finality an institution requires. A user interface can be unavailable while the underlying network remains healthy.

Safety and liveness are different promises

Distributed-systems analysis commonly distinguishes safety, avoiding incompatible accepted outcomes, from liveness, continuing to make progress. The precise guarantees depend on the protocol and assumptions about participants and message delivery.

Consider two offices receiving different network views during a communications disruption. “Use the newest transaction you can see” does not resolve the problem: each office may see a different newest transaction. Time stamps alone cannot establish an authoritative global ordering in a system with delayed messages and untrusted participants.

A protocol therefore specifies how proposals, votes or accumulated work affect the accepted history. Those rules impose trade-offs when communication deteriorates. Depending on the design and circumstances, participants may wait, continue on competing branches or produce blocks that have not yet become final.

For a capital-markets operation, the resulting exposures differ:

• A service interruption creates delay, funding and replacement-cost exposure.

• A reorganisation can invalidate a previously observed receipt and associated downstream decisions.

• An invalid state transition accepted because of a software defect can undermine the asset record itself.

• A divergence between two internal data providers can create false balances even when the network is functioning correctly.

A network risk assessment should classify these outcomes separately. A single “uptime” statistic cannot describe all four.