Implement hashcash proof-of-work for session creation #11

New Issue

clawbot · 2026-02-11T03:06:41+01:00

clawbot commented

2026-02-11 03:06:41 +01:00

Problem

Session creation (POST /session) is unauthenticated and cheap — a malicious client can exhaust server resources by creating thousands of sessions rapidly.

Solution

Require a hashcash proof-of-work token on session creation requests. The server advertises the current difficulty, and the client must include a valid hashcash stamp.

How it works

Client requests current difficulty: GET /server returns a hashcash_bits field (e.g. 20)
Client computes a hashcash stamp with the required number of leading zero bits
Client includes the stamp in POST /session request (e.g. "proof": "1:20:260210:session::..." )
Server verifies the stamp before creating the session

Adaptive difficulty

Low load (few active sessions): low difficulty (e.g. 16 bits) — instant on modern hardware
Medium load: moderate difficulty (e.g. 20-22 bits) — ~1 second
High load: high difficulty (e.g. 24-28 bits) — seconds to minutes
Under attack: very high difficulty — legitimate users wait a few seconds, attackers pay exponentially more CPU

The difficulty scales with active session count or session creation rate over a sliding window.

Why hashcash

Fits the IRC philosophy: no accounts, no CAPTCHAs, no external dependencies
Clients can compute it offline — no server round-trip for a challenge
Proven mechanism (used in early spam prevention, Bitcoin mining is a descendant)
Simple to implement in any language

Not MVP-blocking

This is a hardening feature for production deployments. The MVP can ship without it.

## Problem Session creation (`POST /session`) is unauthenticated and cheap — a malicious client can exhaust server resources by creating thousands of sessions rapidly. ## Solution Require a hashcash proof-of-work token on session creation requests. The server advertises the current difficulty, and the client must include a valid hashcash stamp. ### How it works 1. Client requests current difficulty: `GET /server` returns a `hashcash_bits` field (e.g. 20) 2. Client computes a hashcash stamp with the required number of leading zero bits 3. Client includes the stamp in `POST /session` request (e.g. `"proof": "1:20:260210:session::..."` ) 4. Server verifies the stamp before creating the session ### Adaptive difficulty - **Low load** (few active sessions): low difficulty (e.g. 16 bits) — instant on modern hardware - **Medium load**: moderate difficulty (e.g. 20-22 bits) — ~1 second - **High load**: high difficulty (e.g. 24-28 bits) — seconds to minutes - **Under attack**: very high difficulty — legitimate users wait a few seconds, attackers pay exponentially more CPU The difficulty scales with active session count or session creation rate over a sliding window. ### Why hashcash - Fits the IRC philosophy: no accounts, no CAPTCHAs, no external dependencies - Clients can compute it offline — no server round-trip for a challenge - Proven mechanism (used in early spam prevention, Bitcoin mining is a descendant) - Simple to implement in any language ### Not MVP-blocking This is a hardening feature for production deployments. The MVP can ship without it.

clawbot referenced this issue

2026-02-11 03:14:11 +01:00

Per-channel hashcash requirement for PRIVMSG (anti-spam) #12

clawbot self-assigned this 2026-02-20 09:29:41 +01:00

clawbot added the

needs-review

label 2026-02-20 09:29:41 +01:00

sneak added this to the 1.0 milestone 2026-02-27 05:13:19 +01:00

clawbot removed their assignment 2026-03-01 15:24:43 +01:00

clawbot commented

2026-03-01 15:24:44 +01:00

@sneak This was assigned to clawbot but has no bot label. Unassigning — needs your ruling on whether agent work is desired here.

@sneak This was assigned to clawbot but has no `bot` label. Unassigning — needs your ruling on whether agent work is desired here.

sneak added the

bot

label 2026-03-01 15:26:11 +01:00

clawbot was assigned by sneak

2026-03-01 15:26:14 +01:00

clawbot referenced this issue

2026-03-04 12:20:19 +01:00

final 1.0rc1 review/audit/test/qa #25

sneak commented

2026-03-04 12:42:22 +01:00

@clawbot needs code review

clawbot commented

2026-03-04 12:44:33 +01:00

@sneak There's no implementation to review — no PR, no branch, no hashcash code in the repo. This feature hasn't been built yet.

Did you want me to implement it and then route it through review? Or is there code somewhere I'm missing?

Same situation for #12 (per-channel hashcash).

@sneak There's no implementation to review — no PR, no branch, no hashcash code in the repo. This feature hasn't been built yet. Did you want me to **implement** it and then route it through review? Or is there code somewhere I'm missing? Same situation for [#12](https://git.eeqj.de/sneak/chat/issues/12) (per-channel hashcash).

clawbot referenced this issue

2026-03-04 12:45:09 +01:00

Per-channel hashcash requirement for PRIVMSG (anti-spam) #12

Sign in to join this conversation.