# Proof of Work (PoW)

ALTCHA Proof-of-Work (PoW) v2 is a sophisticated, client-side computational puzzle designed to protect web applications from automated abuse. Unlike traditional PoW systems that rely on simple hashing, ALTCHA PoW v2 utilizes **Key Derivation Functions (KDFs)** to create an asymmetric challenge: expensive for the client to solve, but cheap for the server to verify.

For more technical details about the PoW, visit the [Playground](https://playground.altcha.org/#/about).

## Core Algorithms

ALTCHA supports multiple cryptographic primitives to balance device compatibility with hardware resistance.

| Algorithm | GPU/ASIC Resistance | Browser Implementation | Server Verification |
| :--- | :--- | :--- | :--- |
| **PBKDF2** | Low | Native (`SubtleCrypto`) | Very Fast |
| **Argon2id** | Maximum | WASM | Moderate |
| **Scrypt** | Moderate | WASM | Moderate |
| **SHA** | Very Low | Native (`SubtleCrypto`) | Very Fast |

### Memory-Hard Protection
To counter attackers using specialized hardware (GPUs/ASICs), ALTCHA leverages **Argon2id** and **Scrypt**. These algorithms require significant RAM to compute, narrowing the performance gap between a standard smartphone and a specialized bot farm.

## Effort Modes

The mechanism operates in two distinct modes, allowing developers to prioritize either user experience consistency or server scalability.

### 1. Deterministic Effort Mode (Recommended)
The server defines the exact amount of work required. By pre-calculating a target and providing a `keySignature`, the server ensures the user spends a predictable amount of time solving the challenge.

* **User Experience:** Highly consistent and predictable.
* **Verification:** Extremely fast (uses HMAC validation).
* **Best For:** Standard web forms, login protection, and security-sensitive APIs.

### 2. Probabilistic Effort Mode
The server sets a statistical difficulty (e.g., "find a result starting with `00`"). The client solves challenges based on "luck," meaning some challenges are solved instantly while others take longer.

* **User Experience:** Variable; solving time fluctuates.
* **Server Cost:** Near-zero overhead for challenge generation.
* **Best For:** High-throughput endpoints, IoT, or edge computing.

## Technical Workflow

The PoW process follows a three-step lifecycle:

### 1. Challenge Generation
The server creates a JSON payload containing the `algorithm`, `salt`, `nonce`, and difficulty parameters (`cost`, `keyPrefix`). In **Deterministic Mode**, a `keySignature` is included.

### 2. Client Solving
The client executes a loop, incrementing a `counter` and deriving a key until the output matches the server's requirements:

`DerivedKey=KDF(Algorithm, Salt, Cost, Password)`

Where `Password` is the `nonce` appended with the `counter`.

### 3. Server Verification
The server validates the solution by checking the HMAC signature of the parameters and performing a single KDF execution to ensure the submitted `counter` produces the claimed `derivedKey`.

## Configuration & Best Practices

To ensure a smooth experience for legitimate users while deterring bots, use these recommended settings:

### For Wide Compatibility (PBKDF2)
PBKDF2 is the best default for most applications as it runs natively in the browser without extra binaries.
* **Algorithm:** `PBKDF2` (SHA-256)
* **Cost:** `5000`
* **Counter (Deterministic):** `5000` to `10000`

### For Maximum Security (Argon2id)
Use Argon2id to force attackers to exhaust physical RAM, making large-scale flood attacks expensive.
* **MemoryCost:** `65536` to `131072` (64MB to 128MB)
* **Parallelism:** `1`
* **Counter (Deterministic):** `100` to `200`