---
title: Block Chain
description: "# [Block](https://bitcoindevelopers.org/encyclopedia/block/) Chain The [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain provides Bitcoin’s public ledger, an ordered and timestamped record of transactions. This system is used to protect against double spending and modification of previous transaction records. ## Introduction Each full [Node](https://bitcoindevelopers.org/encyclopedia/node/) in the Bitcoin…"
url: "https://bitcoindevelopers.org/docs/developer-guides/block-chain/"
updated: "2025-05-13"
category: Developer Guides
---

# Block Chain

# [Block](https://bitcoindevelopers.org/encyclopedia/block/) Chain

The [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain provides Bitcoin’s public ledger, an ordered and timestamped record of transactions. This system is used to protect against double spending and modification of previous transaction records.

## Introduction

Each full [Node](https://bitcoindevelopers.org/encyclopedia/node/) in the Bitcoin network independently stores a [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain containing only blocks validated by that [Node](https://bitcoindevelopers.org/encyclopedia/node/). When several nodes all have the same blocks in their [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, they are considered to be in [Consensus](https://bitcoindevelopers.org/encyclopedia/consensus/). The validation rules these nodes follow to maintain [Consensus](https://bitcoindevelopers.org/encyclopedia/consensus/) are called [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/). This section describes many of the [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/) used by Bitcoin Core.

  ![Block Chain Overview](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-blockchain-overview.svg)

[Block](https://bitcoindevelopers.org/encyclopedia/block/) Chain Overview

The illustration above shows a simplified version of a [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. A [Block](https://bitcoindevelopers.org/encyclopedia/block/) of one or more new transactions is collected into the transaction data part of a [Block](https://bitcoindevelopers.org/encyclopedia/block/). Copies of each transaction are hashed, and the hashes are then paired, hashed, paired again, and hashed again until a single hash remains, the [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) of a [Merkle tree](https://bitcoindevelopers.org/encyclopedia/merkle-tree/).

The [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) is stored in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/). Each [Block](https://bitcoindevelopers.org/encyclopedia/block/) also stores the hash of the previous [Block](https://bitcoindevelopers.org/encyclopedia/block/)’s [Header](https://bitcoindevelopers.org/encyclopedia/header/), chaining the blocks together. This ensures a transaction cannot be modified without modifying the [Block](https://bitcoindevelopers.org/encyclopedia/block/) that records it and all following blocks.

Transactions are also chained together. Bitcoin [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) software gives the impression that [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) are sent from and to wallets, but [Bitcoins](https://bitcoindevelopers.org/encyclopedia/bitcoins/) really move from transaction to transaction. Each transaction spends the [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) previously received in one or more earlier transactions, so the [Input](https://bitcoindevelopers.org/encyclopedia/input/) of one transaction is the [Output](https://bitcoindevelopers.org/encyclopedia/output/) of a previous transaction.

  ![Transaction Propagation](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-transaction-propagation.svg)

Transaction Propagation

A single transaction can create multiple outputs, as would be the case when sending to multiple addresses, but each [Output](https://bitcoindevelopers.org/encyclopedia/output/) of a particular transaction can only be used as an [Input](https://bitcoindevelopers.org/encyclopedia/input/) once in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. Any subsequent reference is a forbidden [Double spend](https://bitcoindevelopers.org/encyclopedia/double-spend/)—an attempt to spend the same [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) twice.

Outputs are tied to transaction identifiers (TXIDs), which are the hashes of signed transactions.

Because each [Output](https://bitcoindevelopers.org/encyclopedia/output/) of a particular transaction can only be spent once, the outputs of all transactions included in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain can be categorized as either Unspent Transaction Outputs (UTXOs) or spent transaction outputs. For a payment to be valid, it must only use UTXOs as inputs.

Ignoring [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transactions (described later), if the value of a transaction’s outputs exceed its inputs, the transaction will be rejected—but if the inputs exceed the value of the outputs, any difference in value may be claimed as a [Transaction fee](https://bitcoindevelopers.org/encyclopedia/transaction-fee/) by the Bitcoin [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) who creates the [Block](https://bitcoindevelopers.org/encyclopedia/block/) containing that transaction. For example, in the illustration above, each transaction spends 10,000 [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) fewer than it receives from its combined inputs, effectively paying a 10,000 satoshi [Transaction fee](https://bitcoindevelopers.org/encyclopedia/transaction-fee/).

## [Proof of work](https://bitcoindevelopers.org/encyclopedia/proof-of-work/)

The [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain is collaboratively maintained by anonymous peers on the network, so Bitcoin requires that each [Block](https://bitcoindevelopers.org/encyclopedia/block/) prove a significant amount of work was invested in its creation to ensure that untrustworthy peers who want to modify past blocks have to work harder than honest peers who only want to add new blocks to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain.

Chaining blocks together makes it impossible to modify transactions included in any [Block](https://bitcoindevelopers.org/encyclopedia/block/) without modifying all subsequent blocks. As a result, the cost to modify a particular [Block](https://bitcoindevelopers.org/encyclopedia/block/) increases with every new [Block](https://bitcoindevelopers.org/encyclopedia/block/) added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, magnifying the effect of the [Proof of work](https://bitcoindevelopers.org/encyclopedia/proof-of-work/).

The [Proof of work](https://bitcoindevelopers.org/encyclopedia/proof-of-work/) used in Bitcoin takes advantage of the apparently random nature of cryptographic hashes. A good cryptographic hash algorithm converts arbitrary data into a seemingly random number. If the data is modified in any way and the hash re-run, a new seemingly random number is produced, so there is no way to modify the data to make the hash number predictable.

To prove you did some extra work to create a [Block](https://bitcoindevelopers.org/encyclopedia/block/), you must create a hash of the [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) which does not exceed a certain value. For example, if the maximum possible hash value is 2256 − 1, you can prove that you tried up to two combinations by producing a hash value less than 2255.

In the example given above, you will produce a successful hash on average every other try. You can even estimate the probability that a given hash attempt will generate a number below the [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold. Bitcoin assumes a linear probability that the lower it makes the [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold, the more hash attempts (on average) will need to be tried.

New blocks will only be added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain if their hash is at least as challenging as a [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) value expected by the [Consensus](https://bitcoindevelopers.org/encyclopedia/consensus/) protocol. Every 2,016 blocks, the network uses timestamps stored in each [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) to calculate the number of seconds elapsed between generation of the first and last of those last 2,016 blocks. The ideal value is 1,209,600 seconds (two weeks).

- If it took fewer than two weeks to generate the 2,016 blocks, the expected [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) value is increased proportionally (by as much as 300%) so that the next 2,016 blocks should take exactly two weeks to generate if hashes are checked at the same rate.
- If it took more than two weeks to generate the blocks, the expected [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) value is decreased proportionally (by as much as 75%) for the same reason.

(Note: an off-by-one error in the Bitcoin Core implementation causes the [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) to be updated every 2,01*6* blocks using timestamps from only 2,01*5* blocks, creating a slight skew.)

Because each [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) must hash to a value below the [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold, and because each [Block](https://bitcoindevelopers.org/encyclopedia/block/) is linked to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) that preceded it, it requires (on average) as much hashing power to propagate a modified [Block](https://bitcoindevelopers.org/encyclopedia/block/) as the entire Bitcoin network expended between the time the original [Block](https://bitcoindevelopers.org/encyclopedia/block/) was created and the present time. Only if you acquired a majority of the network’s hashing power could you reliably execute such a [51 percent attack](https://bitcoindevelopers.org/encyclopedia/51-percent-attack/) against transaction history (although, it should be noted, that even less than 50% of the hashing power still has a good chance of performing such attacks).

The [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) provides several easy-to-modify fields, such as a dedicated nonce field, so obtaining new hashes doesn’t require waiting for new transactions. Also, only the 80-byte [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) is hashed for proof-of-work, so including a large volume of transaction data in a [Block](https://bitcoindevelopers.org/encyclopedia/block/) does not slow down hashing with extra I/O, and adding additional transaction data only requires the recalculation of the ancestor hashes in the [Merkle tree](https://bitcoindevelopers.org/encyclopedia/merkle-tree/).

## [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/) And Forking

Any Bitcoin [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) who successfully hashes a [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) to a value below the [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold can add the entire [Block](https://bitcoindevelopers.org/encyclopedia/block/) to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain (assuming the [Block](https://bitcoindevelopers.org/encyclopedia/block/) is otherwise valid). These blocks are commonly addressed by their [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/)—the number of blocks between them and the first Bitcoin [Block](https://bitcoindevelopers.org/encyclopedia/block/) ([Block](https://bitcoindevelopers.org/encyclopedia/block/) 0, most commonly known as the genesis [Block](https://bitcoindevelopers.org/encyclopedia/block/)). For example, [Block](https://bitcoindevelopers.org/encyclopedia/block/) 2016 is where [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) could have first been adjusted.

  ![Common And Uncommon Block Chain Forks](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-blockchain-fork.svg)

Common And Uncommon [Block](https://bitcoindevelopers.org/encyclopedia/block/) Chain Forks

Multiple blocks can all have the same [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/), as is common when two or more miners each produce a [Block](https://bitcoindevelopers.org/encyclopedia/block/) at roughly the same time. This creates an apparent [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, as shown in the illustration above.

When miners produce simultaneous blocks at the end of the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, each [Node](https://bitcoindevelopers.org/encyclopedia/node/) individually chooses which [Block](https://bitcoindevelopers.org/encyclopedia/block/) to accept. In the absence of other considerations, discussed below, nodes usually use the first [Block](https://bitcoindevelopers.org/encyclopedia/block/) they see.

Eventually a [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) produces another [Block](https://bitcoindevelopers.org/encyclopedia/block/) which attaches to only one of the competing simultaneously-mined blocks. This makes that side of the [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) stronger than the other side. Assuming a [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) only contains valid blocks, normal peers always follow the most difficult chain to recreate and throw away stale blocks belonging to shorter forks. (Stale blocks are also sometimes called orphans or orphan blocks, but those terms are also used for true orphan blocks without a known parent [Block](https://bitcoindevelopers.org/encyclopedia/block/).)

Long-term forks are possible if different miners work at cross-purposes, such as some miners diligently working to extend the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain at the same time other miners are attempting a [51 percent attack](https://bitcoindevelopers.org/encyclopedia/51-percent-attack/) to revise transaction history.

Since multiple blocks can have the same [Height](https://bitcoindevelopers.org/encyclopedia/height/) during a [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain [Fork](https://bitcoindevelopers.org/encyclopedia/fork/), [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/) should not be used as a globally unique identifier. Instead, blocks are usually referenced by the hash of their [Header](https://bitcoindevelopers.org/encyclopedia/header/) (often with the byte order reversed, and in hexadecimal).

## Transaction Data

Every [Block](https://bitcoindevelopers.org/encyclopedia/block/) must include one or more transactions. The first one of these transactions must be a [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction, also called a [Generation transaction](https://bitcoindevelopers.org/encyclopedia/generation-transaction/), which should collect and spend the [Block reward](https://bitcoindevelopers.org/encyclopedia/block-reward/) (comprised of a [Block](https://bitcoindevelopers.org/encyclopedia/block/) subsidy and any transaction fees paid by transactions included in this [Block](https://bitcoindevelopers.org/encyclopedia/block/)).

The [UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/) of a [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction has the special condition that it cannot be spent (used as an [Input](https://bitcoindevelopers.org/encyclopedia/input/)) for at least 100 blocks. This temporarily prevents a [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) from spending the transaction fees and [Block reward](https://bitcoindevelopers.org/encyclopedia/block-reward/) from a [Block](https://bitcoindevelopers.org/encyclopedia/block/) that may later be determined to be stale (and therefore the [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction destroyed) after a [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain [Fork](https://bitcoindevelopers.org/encyclopedia/fork/).

Blocks are not required to include any non-[Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transactions, but miners almost always do include additional transactions in order to collect their transaction fees.

All transactions, including the [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transaction, are encoded into blocks in binary [Raw transaction](https://bitcoindevelopers.org/encyclopedia/raw-transaction/) format.

The [Raw transaction](https://bitcoindevelopers.org/encyclopedia/raw-transaction/) format is hashed to create the transaction identifier ([Txid](https://bitcoindevelopers.org/encyclopedia/txid/)). From these txids, the [Merkle tree](https://bitcoindevelopers.org/encyclopedia/merkle-tree/) is constructed by pairing each [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) with one other [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) and then hashing them together. If there are an odd number of txids, the [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) without a partner is hashed with a copy of itself.

The resulting hashes themselves are each paired with one other hash and hashed together. Any hash without a partner is hashed with itself. The process repeats until only one hash remains, the [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/).

For example, if transactions were merely joined (not hashed), a five-transaction [Merkle tree](https://bitcoindevelopers.org/encyclopedia/merkle-tree/) would look like the following text diagram:

```
       ABCDEEEE .......Merkle root
      /
   ABCD        EEEE
  /          /
 AB    CD    EE .......E is paired with itself
/    /    /
A  B  C  D  E .........Transactions
```

As discussed in the [Simplified Payment Verification](https://bitcoindevelopers.org/encyclopedia/simplified-payment-verification/) ([SPV](https://bitcoindevelopers.org/encyclopedia/spv/)) subsection, the [Merkle tree](https://bitcoindevelopers.org/encyclopedia/merkle-tree/) allows clients to verify for themselves that a transaction was included in a [Block](https://bitcoindevelopers.org/encyclopedia/block/) by obtaining the [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) from a [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) and a list of the intermediate hashes from a full [Peer](https://bitcoindevelopers.org/encyclopedia/peer/). The full [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) does not need to be trusted: it is expensive to fake [Block](https://bitcoindevelopers.org/encyclopedia/block/) headers and the intermediate hashes cannot be faked or the verification will fail.

For example, to verify transaction D was added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/), an [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client only needs a copy of the C, AB, and EEEE hashes in addition to the [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/); the client doesn’t need to know anything about any of the other transactions. If the five transactions in this [Block](https://bitcoindevelopers.org/encyclopedia/block/) were all at the maximum size, downloading the entire [Block](https://bitcoindevelopers.org/encyclopedia/block/) would require over 500,000 bytes—but downloading three hashes plus the [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) requires only 140 bytes.

Note: If identical txids are found within the same [Block](https://bitcoindevelopers.org/encyclopedia/block/), there is a possibility that the [Merkle tree](https://bitcoindevelopers.org/encyclopedia/merkle-tree/) may collide with a [Block](https://bitcoindevelopers.org/encyclopedia/block/) with some or all duplicates removed due to how unbalanced merkle trees are implemented (duplicating the lone hash). Since it is impractical to have separate transactions with identical txids, this does not impose a burden on honest software, but must be checked if the invalid status of a [Block](https://bitcoindevelopers.org/encyclopedia/block/) is to be cached; otherwise, a valid [Block](https://bitcoindevelopers.org/encyclopedia/block/) with the duplicates eliminated could have the same [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) and [Block](https://bitcoindevelopers.org/encyclopedia/block/) hash, but be rejected by the cached invalid outcome, resulting in security bugs such as CVE-2012-2459.

## [Consensus](https://bitcoindevelopers.org/encyclopedia/consensus/) Rule Changes

To maintain [Consensus](https://bitcoindevelopers.org/encyclopedia/consensus/), all full nodes validate blocks using the same [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/). However, sometimes the [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/) are changed to introduce new features or prevent network abuse. When the new rules are implemented, there will likely be a period of time when non-upgraded nodes follow the old rules and upgraded nodes follow the new rules, creating two possible ways [Consensus](https://bitcoindevelopers.org/encyclopedia/consensus/) can break:

1. A [Block](https://bitcoindevelopers.org/encyclopedia/block/) following the new [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/) is accepted by upgraded nodes but rejected by non-upgraded nodes. For example, a new transaction feature is used within a [Block](https://bitcoindevelopers.org/encyclopedia/block/): upgraded nodes understand the feature and accept it, but non-upgraded nodes reject it because it violates the old rules.
2. A [Block](https://bitcoindevelopers.org/encyclopedia/block/) violating the new [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/) is rejected by upgraded nodes but accepted by non-upgraded nodes. For example, an abusive transaction feature is used within a [Block](https://bitcoindevelopers.org/encyclopedia/block/): upgraded nodes reject it because it violates the new rules, but non-upgraded nodes accept it because it follows the old rules.

In the first case, rejection by non-upgraded nodes, [Mining](https://bitcoindevelopers.org/encyclopedia/mining/) software which gets [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain data from those non-upgraded nodes refuses to build on the same chain as [Mining](https://bitcoindevelopers.org/encyclopedia/mining/) software getting data from upgraded nodes. This creates permanently divergent chains—one for non-upgraded nodes and one for upgraded nodes—called a hard [Fork](https://bitcoindevelopers.org/encyclopedia/fork/).

  ![Hard Fork](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-hard-fork.svg)

Hard [Fork](https://bitcoindevelopers.org/encyclopedia/fork/)

In the second case, rejection by upgraded nodes, it’s possible to keep the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain from permanently diverging if upgraded nodes control a majority of the hash rate. That’s because, in this case, non-upgraded nodes will accept as valid all the same blocks as upgraded nodes, so the upgraded nodes can build a stronger chain that the non-upgraded nodes will accept as the best valid [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. This is called a soft [Fork](https://bitcoindevelopers.org/encyclopedia/fork/).

  ![Soft Fork](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-soft-fork.svg)

Soft [Fork](https://bitcoindevelopers.org/encyclopedia/fork/)

Although a [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) is an actual divergence in [Block](https://bitcoindevelopers.org/encyclopedia/block/) chains, changes to the [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/) are often described by their potential to create either a hard or soft [Fork](https://bitcoindevelopers.org/encyclopedia/fork/). For example, “increasing the [Block](https://bitcoindevelopers.org/encyclopedia/block/) size above 1 MB requires a hard [Fork](https://bitcoindevelopers.org/encyclopedia/fork/).” In this example, an actual [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) is not required—but it is a possible outcome.

[Consensus](https://bitcoindevelopers.org/encyclopedia/consensus/) rule changes may be activated in various ways. During Bitcoin’s first two years, Satoshi Nakamoto performed several soft forks by just releasing the backwards-compatible change in a client that began immediately enforcing the new rule. Multiple soft forks such as BIP30 have been activated via a flag day where the new rule began to be enforced at a preset time or [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/). Such forks activated via a flag day are known as User Activated Soft Forks ([UASF](https://bitcoindevelopers.org/encyclopedia/uasf/)) as they are dependent on having sufficient users (nodes) to enforce the new rules after the flag day.

Later soft forks waited for a majority of hash rate (typically 75% or 95%) to signal their readiness for enforcing the new [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/). Once the signalling threshold has been passed, all nodes will begin enforcing the new rules. Such forks are known as [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) Activated Soft Forks ([MASF](https://bitcoindevelopers.org/encyclopedia/masf/)) as they are dependent on miners for activation.

**Resources:** BIP16, BIP30, and BIP34 were implemented as changes which might have lead to soft forks. BIP50 describes both an accidental hard [Fork](https://bitcoindevelopers.org/encyclopedia/fork/), resolved by temporary downgrading the capabilities of upgraded nodes, and an intentional hard [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) when the temporary downgrade was removed. A document from Gavin Andresen outlines how future rule changes may be implemented.

## Detecting Forks

Non-upgraded nodes may use and distribute incorrect information during both types of forks, creating several situations which could lead to financial loss. In particular, non-upgraded nodes may relay and accept transactions that are considered invalid by upgraded nodes and so will never become part of the universally-recognized best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. Non-upgraded nodes may also refuse to relay blocks or transactions which have already been added to the best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, or soon will be, and so provide incomplete information.

Bitcoin Core includes code that detects a hard [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) by looking at [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain [Proof of work](https://bitcoindevelopers.org/encyclopedia/proof-of-work/). If a non-upgraded [Node](https://bitcoindevelopers.org/encyclopedia/node/) receives [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain headers demonstrating at least six blocks more [Proof of work](https://bitcoindevelopers.org/encyclopedia/proof-of-work/) than the best chain it considers valid, the [Node](https://bitcoindevelopers.org/encyclopedia/node/) reports a warning in the “getnetworkinfo” RPC results and runs the `-alertnotify` command if set. This warns the operator that the non-upgraded [Node](https://bitcoindevelopers.org/encyclopedia/node/) can’t switch to what is likely the best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain.

Full nodes can also check [Block](https://bitcoindevelopers.org/encyclopedia/block/) and transaction version numbers. If the [Block](https://bitcoindevelopers.org/encyclopedia/block/) or transaction version numbers seen in several recent blocks are higher than the version numbers the [Node](https://bitcoindevelopers.org/encyclopedia/node/) uses, it can assume it doesn’t use the current [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/). Bitcoin Core reports this situation through the “getnetworkinfo” RPC and `-alertnotify` command if set.

In either case, [Block](https://bitcoindevelopers.org/encyclopedia/block/) and transaction data should not be relied upon if it comes from a [Node](https://bitcoindevelopers.org/encyclopedia/node/) that apparently isn’t using the current [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/).

[SPV](https://bitcoindevelopers.org/encyclopedia/spv/) clients which connect to full nodes can detect a likely hard [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) by connecting to several full nodes and ensuring that they’re all on the same chain with the same [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/), plus or minus several blocks to account for transmission delays and stale blocks. If there’s a divergence, the client can disconnect from nodes with weaker chains.

[SPV](https://bitcoindevelopers.org/encyclopedia/spv/) clients should also monitor for [Block](https://bitcoindevelopers.org/encyclopedia/block/) and [Transaction version number](https://bitcoindevelopers.org/encyclopedia/transaction-version-number/) increases to ensure they process received transactions and create new transactions using the current [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/).