Bitcoin has this thing: blockchain. But it is not, in fact, a chain. It is a tree of chains. Bitcoin software does not determine which chain is the final one, just like it does not define which transaction is the final one. Instead, Bitcoin gives you the truth and the tools.

The truth is: in a decentralized network it is unknowable what information you miss. And more importantly, it is unknowable what information others are having. There might be a fork in the chain somewhere, or two. And you may hear about it soon enough or later, or too late, or maybe never.

The tools are: given all the information at hand you can (1) filter out invalid data, (2) switch to a most-weight chain as a source of truth, (3) decide for yourself how deep the payment transaction should be inside that chain for you to take the risk of calling it final and acting upon it (e. g. by providing the service in response).

Turns out, the protocol outlined above (“the tools”) is necessary to have a chance of achieving consensus with majority of other users on the network. Let me prove that real quick. First, filtering out invalid data is simply setting the language of the game, so all nodes agree on the basic rules and boundaries. Second, “always switching to the most-weight chain” means no one is permanently stuck on a weaker chain, so a would-be attacker has to overcome the majority of the mining nodes to affect the majority of the users. An attacker might partition the network and fool some nodes to a minority chain, but those nodes have a chance of being healed by getting the information from the majority via some roundabout means: via proxies, hum radio, pigeon post etc. Finally, the decision on finality rests with each individual user because of the openness and uncertainty in the network. If anyone, in principle, can fork the blockchain at any point in time and thus revert any subgraph of transactions, then there is no possibility for the formal definition of finality. Considering payment final is a subjective decision on behalf of a risk-taker. You can wait longer to stay safer and calculate the risk based on your own world-view against the profit and risks of acting quick and opportunity costs of acting slow.

Now, back to our tree of chains. Given the rules above there is one consequence that may surprise some people. What do you think should happen inside a Bitcoin node if it receives a single-block fork from some older block? That block would obviously be of a much lesser weight and won’t affect the current node in any way. Or would it? All Bitcoin nodes in such case would not only accept that block (if it is formally valid, of course), but also relay it to all other nodes. Because the node cannot know if that block is the beginning of a great chain which you might receive soon and switch over to. But if you ignore lesser chains than your current one you run a risk of being stuck on a weaker chain forever. That’s why, for the purpose of resilience and therefore consistency with the peers, every Bitcoin node propagates every valid fork and stores it forever.

In a way, Bitcoin’s block-tree data structure resembles a quantum particle that exists in multiple possible states and delays manifestation of a particular state until it is necessary to interact with the environment. You only need to be concerned about what chain is heavier and whether transaction is final, when you have to act upon a specific transaction of interest — that’s when you look at the most-weight chain and decide how deep you want your transaction to be in it. At all other times, Bitcoin node treats all chains as equally worthy and does not decide anything about any transaction.

Takeaway: in order to achieve consistency in the complex environment of a decentralized network, the nodes must be open to maximum uncertainty and delay decision-making as much as possible.