> For the complete documentation index, see [llms.txt](https://www.notbank.com/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.notbank.com/learn/academy/en/bitcoin/applied-cryptography.md).

# Applied Cryptography

***

> "Without cryptography, Bitcoin would literally be impossible."\
> — *Hal Finney (Bitcointalk, 2009)*

***

## 1. Introduction

Bitcoin is, in essence, an economic system backed by mathematics.\
It does not rely on institutions, authorities or interpersonal trust: it relies on **cryptographic functions** that guarantee:

* irreversibility
* non-counterfeiting
* public verifiability
* digital ownership
* attack resistance

This chapter covers the three fundamental cryptographic pillars:

1. **Hash functions (SHA-256, RIPEMD-160)**
2. **Digital signatures (ECDSA)**
3. **Elliptic curves (secp256k1)**

Each one plays a specific role within Bitcoin's design.

***

## 2. Cryptographic hashing in Bitcoin

### 2.1. What is a hash?

A **cryptographic hash function** is a transformation:

$$
H: {0,1}^\* \rightarrow {0,1}^n
$$

with the following properties:

* **Preimage resistance**
* **Second-preimage resistance**
* **Collision resistance**
* **Determinism**
* **Efficiency**

Bitcoin primarily uses:

* **SHA-256**
* **RIPEMD-160**

And occasionally combinations like **SHA-256(SHA-256(x))** (*double SHA-256*).

***

### 2.2. Key properties applied to Bitcoin's design

#### 1. Collision resistance

Makes it impossible to find two different messages that produce the same hash.

This is essential for:

* ensuring block integrity
* preventing malicious reorganizations
* guaranteeing transaction uniqueness

#### 2. One-wayness

It is not possible to recover the original information from a hash.

It facilitates:

* addressing without revealing public keys
* resistance to future-spend attacks
* protection against preimage collisions

***

### 2.3. Hashing in the system's different components

| Component       | Hash algorithm       | Purpose                     |
| --------------- | -------------------- | --------------------------- |
| Block header    | SHA-256d             | To prove PoW                |
| Merkle tree     | SHA-256d             | To aggregate transactions   |
| Bitcoin address | SHA-256 + RIPEMD-160 | To create short identifiers |

***

## 3. Merkle trees: compression and verifiability

The transactions within each block are organized into a **Merkle tree**.

### 3.1. Formal definition

A Merkle tree is a binary structure where:

<p align="center"><span class="math">H_{l1} = SHA256d(tx1)</span><br><span class="math">H_{l2} = SHA256d(tx2)</span><br><span class="math">H_0 = SHA256d(H_{l1} | H_{l1})</span><br><br><span class="math">H_{l3} = SHA256d(tx3)</span><br><span class="math">H_{l4} = SHA256d(tx4)</span><br><span class="math">H_1 = SHA256d(H_{l3} | H_{l4})</span><br><br><span class="math">Root = SHA256d(H_{0} | H_{1})</span></p>

<figure><img src="/files/180deccd9374988473e5e71b275cf905109e1af1" alt=""><figcaption></figcaption></figure>

### 3.2. Advantages

* They provide efficient proofs of inclusion (Merkle proofs)
* They enable lightweight nodes (SPV)
* They reduce the need for storage

These proofs are fundamental for mobile devices and light clients.

***

## 4. Digital signatures (ECDSA)

### 4.1. What are they for?

Bitcoin uses digital signatures to verify:

* that the owner of a private key authorized a transaction
* that the transaction was not modified
* that the signature is publicly valid

### 4.2. Mathematical basis

If:

* $$d$$ = private key
* $$Q = dG$$ = public key (point on curve)

then the signature (r, s) satisfies:

$$r = (kG)\_x \mod n$$

$$s = k^{-1}(H(m) + dr) \mod n$$

where:

* $$k$$ = random number per signature
* $$G$$ = generator point
* $$n$$ = order of the elliptic group

***

### 4.3. Security

ECDSA is secure as long as:

$$k \text{ sea único y aleatorio}$$

If reused, the private key can be derived:

$$d = \frac{s\_1k - H(m\_1)}{r} \mod n$$

This has caused hacks in defective implementations in the past.

***

## 5. Elliptic curves: the algebraic foundation

Bitcoin uses the elliptic curve **secp256k1**.

### 5.1. Mathematical definition

It is the curve:

$$y^2 = x^3 + 7$$

over the finite field:

$$\mathbb{F}\_p, \quad p = 2^{256} - 2^{32} - 977$$

### 5.2. Properties

* non-random curve (unlike NIST curves)
* efficient operations
* proven security
* resistant to state manipulation (according to many cryptographers)

### 5.3. Point multiplication

The fundamental operation is:

$$Q = dG$$

where:

* $$d$$ = 256-bit number
* $$G$$ = generator point
* $$Q$$ = public key

It is easy to compute $$Q$$, but **practically impossible to compute** $$d$$.

This is based on the difficulty of the **Elliptic Curve Discrete Logarithm Problem (ECDLP)**.

***

## 6. Bitcoin addresses: from the hash to the Base58Check representation

### 6.1. Full generation process

1.

<p align="center"><span class="math">\text{Clave pública} = Q</span></p>

2.

<p align="center"><span class="math">\text{hash160}(Q) = \text{RIPEMD160}(\text{SHA256}(Q))</span></p>

3.

<p align="center">Add version:<br><span class="math">00 + hash160</span></p>

4.

<p align="center">Calculate checksum:<br><span class="math">\text{SHA256d}(00 + hash160)</span></p>

5.

<p align="center">Encode in <strong>Base58Check</strong>.</p>

***

### 6.2. Simplified example in pseudocode

```python
pub = get_public_key(priv)
h160 = RIPEMD160(SHA256(pub))
payload = 0x00 + h160
checksum = SHA256(SHA256(payload))[:4]
address = Base58Encode(payload + checksum)
```

## 7. Cryptographic security against modern attacks

### 7.1. Quantum attacks

Bitcoin partially resists quantum attacks:

| Function | Quantum risk | Impact                         |
| -------- | ------------ | ------------------------------ |
| SHA-256  | Low          | Grover reduces security by 50% |
| ECDSA    | Medium       | Shor could derive public keys  |

Current mitigation:

* public keys not exposed until spent
* future possibility of changing algorithm

### 7.2. Collision attacks

SHA-256 has no known collisions.

A collision implies:

<p align="center"><span class="math">H(x)=H(y)</span></p>

<p align="center">with <span class="math">x \neq y</span></p>

The probability is astronomically low ($$\approx 2^{-256}$$).

### 7.3. Implementation attacks

The most common attacks:

* poor randomness generation
* defective wallets
* side-channel attacks
* compromised hardware

Bitcoin as a protocol is secure; implementations may not be.

## 8. Cryptography applied on the blockchain

Bitcoin uses cryptography to secure:

| Component               | Mechanism     |
| ----------------------- | ------------- |
| Block integrity         | SHA-256d hash |
| Transaction integrity   | Merkle Root   |
| Digital ownership       | ECDSA         |
| Double-spend prevention | PoW           |
| Pseudonymous identities | Hash160       |
| Initial block zeros     | PoW target    |

## 9. Chapter conclusion

Cryptography in Bitcoin is not decorative. It is the source of:

* security
* decentralization
* mathematical trust
* irreversibility
* censorship resistance
* digital ownership

Bitcoin does not work because "everyone agrees" on its validity. It works because **mathematics do not take bribes**.

***

> Bitcoin does not use cryptography to "hide" data.\
> It uses cryptography to **guarantee economic rules without intermediaries.**

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://www.notbank.com/learn/academy/en/bitcoin/applied-cryptography.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
