SLQ notes: 10. Blockchain and Bitcoin – Consensus, Forks, and the Security Model

Blockchain and Bitcoin – Consensus, Forks, and the Security Model

By now you already have a mental picture of Bitcoin that includes transactions, UTXOs, blocks, fees, scripts, wallets, privacy, and nodes. There is still a crucial question:

If thousands of different machines around the world all keep their own copy of the blockchain, how do they agree on which chain is correct, which blocks are valid, and which payments are final?

The answer lives in three closely related ideas:

Consensus
Forks
The security model

This article first gives short definitions of these concepts. Then it goes deeper into how proof of work based consensus operates, why forks happen, what they mean for users, and what assumptions support Bitcoin’s security.

1. Core ideas in brief

1.1 Consensus

Consensus in Bitcoin is the process by which independent nodes converge on the same view of the blockchain.

It has two parts:

A set of consensus rules that define what counts as a valid transaction and a valid block.
A chain selection rule that tells nodes which branch to treat as the current history when there are several valid branches.

Each node applies these rules locally. There is no central authority that tells nodes what to accept.

1.2 Consensus rules

Consensus rules are the strict rules that define valid history. Examples include:

The block subsidy schedule and total supply limit.
The rules for transaction syntax and script execution.
The maximum block weight and other structural constraints.
The requirement that each block’s proof of work hash be below a certain target.

If a block breaks any consensus rule, every honest full node must reject it.

1.3 Chain selection and proof of work

When there are several different valid chains of blocks, nodes use a rule to select which one to follow.

In Bitcoin, nodes select the valid chain that has the most accumulated proof of work. Informally this is often described as the longest chain, but the real criterion is total work rather than simple length.

This rule lets nodes independently converge on the same chain, even though they hear about blocks in different orders.

1.4 Fork

A fork is a situation where there is more than one possible chain or more than one possible set of rules.

There are two main technical senses:

A temporary chain fork, when two different valid blocks appear at roughly the same height, which later resolves when one branch becomes longer.
A rule change fork, when some nodes enforce one set of consensus rules and others enforce a different set.

Rule change forks are further divided into soft forks and hard forks, which we will describe later.

1.5 Security model

The security model is a description of:

What kinds of attacks we are worried about.
What assumptions we make about miners, nodes, and the network.
What guarantees users can expect about finality, double spend resistance, and rule stability.

Bitcoin’s security model is probabilistic. It does not promise that anything is absolutely impossible. Instead it makes some attacks economically and computationally infeasible under reasonable assumptions.

2. Layers of rules

Before talking more about consensus, it is important to separate different kinds of rules that software may enforce.

2.1 Consensus rules

Consensus rules are the rules that all honest full nodes must agree on to remain compatible.

If two nodes disagree about even one consensus rule, they may accept different sets of blocks as valid and end up on different chains. Persistent disagreement here is a true protocol level fork.

Examples of consensus rules include:

Maximum block weight.
Maximum money that can be created in a coinbase transaction at a given height.
Valid opcodes and limits on script execution.
Structure and format of headers and transactions.

Changing these rules is a serious matter because it can split the network if not everyone adopts the same change.

2.2 Policy rules

Policy rules are local choices that nodes make about how to handle unconfirmed transactions, mempools, and relaying.

For example:

Minimum fee rate a node is willing to accept into its mempool.
Which non standard transactions a node refuses to relay.
Limits on the size of the mempool or on certain transaction patterns.

Nodes are allowed to disagree on policy rules. They may accept slightly different sets of unconfirmed transactions. As long as everything that miners include in blocks obeys the stricter consensus rules, differences in policy do not split the chain.

2.3 Network rules

Network rules are about how nodes communicate over the peer to peer network.

They include:

Message formats and sequences.
Limits on how many connections a node keeps.
Rules for disconnecting peers that misbehave.

These rules do not define validity of blocks and transactions, they define how information flows. Different implementations can structure their networking code differently, as long as they can still speak the common protocol well enough.

3. How consensus works in practice

We can now describe what happens when a new block appears and how nodes decide whether to accept it.

3.1 The life of a candidate block

When a node receives a block from a peer:

It checks that the block header is well formed.
It verifies that the block’s previous hash refers to a block it knows.
It checks that the block’s difficulty target matches what the rules say it should be at that height.
It hashes the header and checks that the hash is less than or equal to the target.
It verifies each transaction in the block, updating a temporary copy of the UTXO set.
It checks coinbase rewards and fees.

Only if all these checks pass does it add the block to its local view of the chain and update the real UTXO set.

3.2 Competing branches and chain selection

Because miners work independently, there can be more than one valid chain at a time.

A node maintains a block tree internally. Some branches may share a long common prefix and then diverge. The node considers one branch to be active based on accumulated work.

If a new block extends the active branch, the node simply connects it and moves the tip forward.

If a new block extends a side branch:

The node calculates the total work of the branch that would result from adding this block.
If this new branch has more total work than the current active branch, the node switches to it.

Switching involves undoing some blocks from the previous branch and applying blocks from the new branch, which rearranges the UTXO set accordingly. This is a reorganization.

3.3 Why independent nodes agree

Even though each node hears about blocks and transactions at slightly different times and from different peers, they share:

The same consensus rules for validity.
The same rule that the valid chain with the most accumulated work is the one to follow.

Under these conditions, and assuming the network is not permanently partitioned, nodes tend to converge on the same active chain.

Consensus is not a voting process in the human sense. Miners do not vote on what is valid, and nodes do not vote either. Miners propose candidate blocks. Nodes accept or reject them based on rules. Proof of work makes it expensive to build long chains, so it is rational for miners to extend the chain that most nodes are likely to accept.

4. Probabilistic finality and confirmations

Bitcoin does not promise instant certainty. Instead, it offers increasing confidence as more blocks are built on top of a transaction.

4.1 What a confirmation means

When a transaction is in the mempool and not yet in any block, it has zero confirmations.

When it is included in a block, we say it has one confirmation. Each new block that builds on top of that block increases the depth of the transaction in the chain by one. A transaction that is six blocks deep has six confirmations.

The deeper a transaction is, the more work an attacker would need to redo in order to produce an alternative chain in which that transaction never happened.

4.2 Risk of reorganization

There is always a small chance that recent blocks will be reorganized away due to:

Two miners finding blocks nearly simultaneously and resolving the conflict later.
Natural random variations in mining and propagation.

The chance that a single confirmation disappears due to an ordinary short reorganization is small but not negligible. The chance that six or more confirmations disappear purely by accident is extremely small.

An attacker who controls some fraction of the network’s hash power can deliberately attempt to reorganize the chain. The probability of success falls rapidly as the number of confirmations increases, unless the attacker controls a very large fraction of total hash power.

4.3 Practical policies

Because finality is probabilistic, different users adopt different confirmation policies:

For small amounts or low risk situations, some people accept zero confirmation transactions, knowing that there is some double spend risk.
For ordinary payments, one or two confirmations are often considered enough.
For large, high value transfers, users may wait for more confirmations before considering the payment final.

There is no magic threshold that fits every case. The right number depends on threat level, value at risk, and how patient you can be.

5. Natural forks and reorganizations

Chain forks are not only pathological events. Short lived forks are a normal part of the system.

5.1 How short forks appear

Imagine the following:

Miner A finds a valid block and broadcasts it.
Before that block reaches every miner, Miner B, working on the previous tip, also finds a valid block.

Now the network has two different valid blocks at the same height. Some nodes see A first and treat it as the tip. Others see B first and treat it as the tip.

Each of these blocks defines a branch of the chain that is one block longer than before.

5.2 How short forks resolve

Miners continue to work on the branch they see as the tip.

Sooner or later:

One branch will receive a new child block first.
That branch will now have more work than the other branch.

Nodes that see this longer branch will switch to it as the active chain. The block on the losing branch becomes an orphan in practice, even though it was valid when created.

Transactions that were only in the orphaned block but not in the winning branch return to mempools if they are still valid. They can then be included in later blocks.

5.3 Impact on users

In most cases, users do not notice short reorganizations because they happen quickly and transactions are eventually included in some block in the winning branch.

The main effect is that a transaction that seemed to have one confirmation in an orphan block may briefly return to zero confirmations before gaining a new confirmation in the winning branch.

Waiting for several confirmations reduces exposure to this effect.

6. Rule change forks: soft forks and hard forks

So far we have talked about forks created by timing. There is another sense in which people use the word fork, namely when the consensus rules themselves change.

6.1 Soft fork

A soft fork introduces new rules that are stricter than the old rules. Blocks that obey the new rules still obey the old rules. Blocks that disobey the new rules are still disallowed by upgraded nodes, but may appear valid to old nodes.

For a soft fork to be safe:

A large majority of miners must enforce the new rules.
Upgraded and non upgraded nodes must still agree on which chain is valid.

Because the new rules are a subset of the old ones, non upgraded nodes will not accept blocks that break the old rules. However, they may fail to notice some blocks that break new rules if they rely on a miner that does not enforce them, which is why miner enforcement is important.

Examples of rule changes that can be implemented as soft forks include:

Tightening some limits on script or block contents.
Adding new script forms that old nodes treat as unspendable but new nodes can interpret.

6.2 Hard fork

A hard fork introduces rules that are not stricter than the old ones. They may allow blocks that are invalid under the old rules.

If some nodes upgrade to the new rules and others remain on the old rules, then:

Blocks that are valid under the new rules but invalid under the old ones will be accepted by upgraded nodes and rejected by old nodes.
The network can split into two groups that follow different chains indefinitely.

To avoid a permanent chain split, every economically relevant node would need to upgrade in sync. In practice this is very difficult to coordinate and carries significant risk, which is why hard forks are approached with extreme caution in Bitcoin.

6.3 Social layer and governance

Technically, this article focuses on the mechanical distinction between soft and hard forks. The decision of whether to adopt any rule change is a social process among users, miners, developers and businesses.

From a pure security model perspective, the key point is that:

Consensus rules are what nodes enforce.
If different groups enforce different rules, there is no longer one Bitcoin chain, there are two separate systems.

7. The security model in broad strokes

The security model explains why Bitcoin can resist attackers and what failure modes still exist.

7.1 Main goals

At a high level, the system aims to provide:

Resistance to double spending.
Stability of the monetary supply schedule.
Protection against arbitrary or hidden rule changes.
Censorship resistance, at least to some degree.

These goals are achieved if certain assumptions hold about who controls hash power, how nodes behave, and how the network functions.

7.2 Key assumptions

Some central assumptions are:

Most of the hash power that mines blocks is controlled by entities who follow the consensus rules because it is in their interest to do so.
The peer to peer network is not permanently partitioned into large, isolated islands that never reconnect.
A meaningful number of users run their own full nodes and enforce the rules independently.
The cost of obtaining and operating a large fraction of total hash power is high compared to the short term value of attacking the system.

The security model is not that Bitcoin is unbreakable. It is that under these assumptions it is very expensive and risky to break in profitable ways.

8. What attackers can try to do

There are several broad categories of attack against consensus and the chain.

8.1 Simple double spend without majority hash power

An attacker can try to:

Send a payment to a victim.
Broadcast a competing transaction that spends the same inputs to themselves.
Hope that the victim accepts the payment after zero confirmations and that the attacker’s transaction wins the race into the first block.

This is called a race attack. It mainly affects zero confirmation transactions.

It does not require majority hash power, only speed and a bit of luck. Merchants who care about this risk usually wait for at least one confirmation.

8.2 Majority hash power attack

If an attacker controls more than half of the total hash rate, they can attempt a deeper double spend.

They can:

Create a transaction that pays a victim and broadcast it.
At the same time, start secretly mining a private chain that includes a conflicting transaction that pays themselves instead.
Wait for the victim to see the public chain and accept some number of confirmations.
Continue mining in private until their hidden chain becomes longer than the public chain.
Broadcast their private chain.

If enough nodes see that the attacker’s chain has more proof of work, they will accept it as the active chain. In that chain, the payment to the victim never happened. The victim has been double spent.

8.3 Limitations of majority attacks

Even with majority hash power, an attacker cannot:

Create coins out of thin air beyond the allowed subsidy and fees.
Break the maximum supply or inflation schedule.
Spend someone else’s coins without their private keys.
Change consensus rules unilaterally without convincing nodes to accept new rules.

They can only build alternative chains of valid blocks that follow the existing rules and choose which transactions to include.

This is because full nodes independently verify block contents. They will not accept invalid blocks, no matter how much work they claim to contain.

8.4 Censorship attacks

An attacker with significant hash power can attempt to censor transactions by:

Refusing to include certain transactions in blocks they mine.
Attempting to persuade or force other miners to do the same.

If they control less than half of the hash power, other miners can still include censored transactions in their own blocks, so censorship is imperfect and may only delay transactions.

If they control almost all hash power, they can enforce very strong censorship for as long as they maintain control. Nodes will still enforce rules about validity, but they cannot force miners to include any particular transactions.

9. Selfish mining and miner incentives

Even miners who do not want to attack the system may try to maximize their own revenue in ways that affect consensus dynamics.

9.1 Selfish mining idea

In a selfish mining strategy, a miner or pool with significant hash power:

Does not immediately broadcast found blocks.
Tries to stay ahead of the public chain by keeping a private branch.
Reveals private blocks at carefully chosen times to override blocks found by honest miners.

The goal is to waste other miners’ efforts and increase the selfish miner’s share of blocks over time, even without controlling more than half of total hash power.

9.2 Impact on security

Selfish mining mainly changes who gets the block rewards, not which transactions are confirmed. The selfish miner can still only produce chains that obey consensus rules.

In extreme scenarios, selfish mining could contribute to centralization pressure if more miners are incentivized to join the largest pool to avoid being penalized.

The deeper question is whether such strategies significantly reduce the effective fraction of hash power that behaves in a straightforward, honest way, and whether protocol changes or pool behavior limit this risk. This is an area where game theory and practice interact.

10. Network level attacks and partitions

Attacks on consensus do not always involve hash power directly. Some target the network layer that connects nodes.

10.1 Eclipse attacks

In an eclipse attack, an attacker attempts to control all network connections of a target node.

If successful, they can:

Feed the node a false view of the chain.
Delay or censor transactions visible to that node.
Try to trick the node into accepting a forked chain that the rest of the network does not see.

Defenses include:

Limiting connections per IP range.
Using multiple peers and connection strategies.
Avoiding reliance on a single network path.

10.2 Network splits

An attacker might attempt to split the network into two large parts that cannot talk to each other, for example by exploiting routing infrastructure.

If each side continues to mine blocks, two valid chains can grow independently. When the split heals, nodes will see two branches and must switch to the one with more accumulated work.

During the split, confirmations on each side are only secure relative to miners on that side. When reconnecting, some blocks may be reorganized.

This is a difficult attack to execute on a global scale for long periods, but it is part of the threat model.

11. Role of full nodes in the security model

Full nodes are central to Bitcoin’s security because they define what counts as valid.

11.1 Nodes as guardians of the rules

Miners propose blocks, but nodes decide whether to accept them.

If miners try to:

Increase the block subsidy beyond what the rules allow.
Spend coins that do not exist.
Use invalid script operations.

Honest full nodes will reject those blocks.

From a security perspective, this means that an attacker who controls most hash power still cannot change the rules without convincing users to run different software. Hash power controls ordering and inclusion of valid transactions, not the definition of validity itself.

11.2 User sovereignty

When you run your own full node:

You decide which software version and which rules to enforce.
You choose which chain to consider real based on those rules and proof of work.

If a proposed rule change is not acceptable to you, you can simply decline to upgrade. If enough users make the same choice, miners who want to keep their blocks valuable are under pressure to follow the rules that users enforce.

This feedback loop between users and miners, mediated by full nodes, is a key part of Bitcoin’s security model at the social and economic level.

12. Practical meaning of security for users

All these mechanisms and assumptions translate into concrete expectations for ordinary users.

12.1 What you can reasonably rely on

Under normal conditions, you can expect that:

A transaction that has received several confirmations on the main chain will not be reversed, unless an extremely powerful and motivated attacker spends enormous resources to reorganize the chain.
Miners cannot arbitrarily create new coins or steal coins without corresponding private keys, because full nodes would reject such blocks.
The monetary schedule, including the maximum supply, is enforced by consensus rules that are very hard to change without broad agreement.

These expectations are not mathematical certainties, but they are supported by the current distribution of hash power, economic incentives, and the cost of attack.

12.2 Where caution is still needed

You should still be careful about:

Accepting large payments with zero confirmations.
Treating low confirmation payments as final in environments where an attacker might control substantial hash power or social engineering.
Relying entirely on third party nodes without understanding that they can alter your view of the chain.

Bitcoin provides strong tools, but your security also depends on how you use them and what threat model applies to your situation.

13. Summary

Consensus, forks, and the security model are the glue that holds the rest of the Bitcoin design together.

We have seen that:

Consensus is defined by strict consensus rules and a chain selection rule based on accumulated proof of work.
Full nodes independently verify blocks and transactions against these rules and select the chain with the most work.
Short term forks arise naturally when miners find blocks at similar times and are resolved by the chain selection rule through reorganizations.
Rule change forks come in two forms, soft forks that tighten rules and can remain compatible with old nodes, and hard forks that can split the network into different systems if not everyone upgrades.
The security model assumes that a large portion of hash power is honest in the sense of following the rules and that users run full nodes that enforce those rules.
Attackers with majority hash power can reorder and censor transactions and perform deep double spends, but they cannot break the supply cap or spend coins without keys as long as nodes enforce the rules.
Network level attacks and game theoretic strategies such as selfish mining are part of the threat model, but their impact is limited by protocol design and decentralization.
Running a full node is how individual users participate directly in consensus and protect their own view of the system.

With this understanding, the behavior of confirmations, forks, and security assumptions is no longer mysterious. It becomes a logical consequence of the way blocks, proof of work, nodes, and incentives fit together. This sets the stage for looking at higher layer constructions such as payment channels and lightning, which build on the base layer’s probabilistic finality and security guarantees.

December 25, 2025

10. Blockchain and Bitcoin – Consensus, Forks, and the Security Model