# Proof-of-Work and HASH-256

#### What is Proof-of-Work?

As described in the **Bitcoin white paper (that BSV is based on)**, a **proof-of-work (PoW) system** is a **signaling mechanism**. It requires participants to prove they have performed a **necessary amount of computational work** before they can carry out a desired action.

In BSV:

* Nodes apply **HASH-256** (double SHA-256) to the **serialized block header**.
* They repeat this process until they find a **hash value lower than the current difficulty target**.

The properties of **SHA-256** — **preimage resistance, second preimage resistance, and collision resistance** — ensure there is **no shortcut**. The only way to succeed is by **brute force hashing**, cycling through nonce values until a valid digest is discovered.

👉 **Key takeaway:** Proof-of-work ensures fairness by making block discovery dependent on **computational effort**, not trust.

***

#### How Proof-of-Work is Used in BSV

1. **Nodes collect transactions** and organize them into a **Merkle Tree**.
2. They construct a **block header template**, including the Merkle Root and timestamp.
3. This template becomes a **mining candidate**.
4. **Hashing pools** request candidates using a **Get Mining Candidate (GMC)** call.
5. Mining candidates are updated about **10 times per second**; pools typically poll nodes every **30 seconds**.

Nodes and miners then iterate through **nonce values**, hashing the block header repeatedly, searching for a proof-of-work solution.

***

#### Difficulty and Block Discovery

To maintain a block discovery interval of **\~10 minutes**:

* The **difficulty target** is adjusted by changing the number of **leading zeroes** required in the hash.
* Increasing leading zeros = **harder difficulty**.
* Reducing leading zeros = **easier difficulty**.

This balance keeps the network stable:

* **Fast enough** to keep miners competitive.
* **Slow enough** to minimize orphan races (conflicting block discoveries).

***

#### Evolution of Mining

* **Early Bitcoin:** Difficulty was low enough that proof-of-work could be solved with a **CPU**.
* As difficulty rose, miners shifted to **GPUs**.
* Today, **ASICs (Application-Specific Integrated Circuits)** purpose-built for SHA-256 dominate mining.

Originally, difficulty was recalculated every **2,016 blocks (\~2 weeks)**. In 2017, it shifted to **per-block adjustments**. BSV node operators plan to restore the **2,016-block cycle**.

***

#### Consensus and Incentives

A block is only considered **“won”** when:

* The majority of nodes begin using its **hash as the previous block hash** to mine the next block.
* This action — building on top of the block — is the **only consensus mechanism in BSV**.

👉 For a participant to be recognized as a **node**, they must:

1. Accept valid blocks.
2. Successfully find proof-of-work solutions for new blocks.

This design creates strong **economic incentives** for nodes to be:

* **Efficient** in hashing.
* **Interconnected** for rapid block propagation.

✅ **Result:** The network can **scale transaction throughput and block sizes** to meet **any level of growth — even exponential expansion**.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hub.bsvblockchain.org/higher-learning/bsv-academy/bitcoin-primitives-hash-functions/sha256/proof-of-work-and-hash-256.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.