SubGeniusFinance/Offerings-to-Cthulhu

Watch

Fork 0

net: build banlist infrastructure (CBanList, banlist.dat, setban/listbanned/clearbanned RPCs) [epic] #17

New issue

Closed

opened 2026-06-06 22:59:26 +00:00 by dobbscoin · 0 comments

dobbscoin commented

2026-06-06 22:59:26 +00:00

Epic. Do-not-merge-pre-Codex. Tracked here for design discussion + post-Codex implementation.

Why

OFF has no banlist infrastructure today. No CBanList, no banlist.dat, no setban / listbanned / clearbanned RPCs, no Qt right-click → Ban action. Verified by searching the tree:

$ grep -nE "disconnectnode|setban|CBanList|banlist" src/rpc*.cpp src/net.cpp
(no hits)
$ ls src/banlist* src/banman* 2>/dev/null
(no files)

The misbehavior counter (CNodeState::nMisbehavior, Misbehaving()) exists and trips at -banscore=100 (default), but the consequence is just disconnect — there's no persistent record, and the peer can immediately reconnect via addrman. There's no way to manually ban a known-bad IP.

For the post-Restoration era, with the chain having a known >80%-hash attacker and external eyes increasing as the BCT announcement lands, OFF will want this. Not today, but soon.

What's needed (scope)

This is a real backend feature, ~200+ LOC across multiple files. Rough plan, modeled on modern Bitcoin Core's banman.{cpp,h}:

1. `src/banlist.{cpp,h}` or equivalent (new files)

CBanEntry — single ban record: subnet/CIDR, ban-until timestamp, reason (manual / misbehavior / consensus)
CBanList (or BanMan) — in-memory map of CSubNet → CBanEntry, persistence to banlist.dat, sweep timer to expire timed bans, thread-safe interface
Functions: IsBanned(CNetAddr), Ban(CSubNet, ban_reason, ban_time_offset), Unban(CSubNet), ClearBanned(), GetBanned()

2. `src/net.cpp` integration

Hook IsBanned check on inbound accept() path (net.cpp connection acceptance)
Hook on outbound peer-selection (don't reconnect to a banned peer via addrman)
Hook into Misbehaving() so a peer crossing the banscore threshold gets an auto-ban (existing OFF behavior is just disconnect — no persistence)

3. `src/init.cpp`

Load banlist.dat on startup
Persist before shutdown

4. RPCs

setban <subnet> <add|remove> [bantime] [absolute] [reason]
listbanned
clearbanned

5. Qt integration (much smaller)

Right-click → Ban Node action in the Peers tab context menu (depends on #15 / #16 landing first)
Maybe a banlist viewer/editor dialog (defer to a separate UI follow-up)

Why post-Codex

This touches net.cpp connection-accept and peer-selection paths. Bugs in those paths surface as network partitions or peer-discovery failures — exactly what cannot happen during the inscription window (blocks 999,991 → 1,050,666). Hard freeze: not merging until block 1,050,667 or later.

Open design questions (for future discussion)

Default auto-ban from Misbehaving()? Modern Bitcoin Core auto-bans on banscore threshold. Should OFF? Pro: shuts up sustained attackers. Con: misbehaving bots are an attack vector for partitioning honest nodes if the threshold is easy to trigger from outside.
Subnet granularity. /32 (single IP) only, or full subnet support? Modern upstream supports CSubNet; the persistence format would match.
Persistence format compat. Should banlist.dat be wire-compatible with Bitcoin Core's, or OFF-specific? Compat means external tooling (some block explorers, monitoring scripts) can read it.
Ban reasons enum — manual / misbehavior / consensus / DoS-protection / ... what set?

What this isn't

Not consensus-changing — banning is a peer-policy decision, not a consensus decision.
Not urgent. OFF is single-Conclave-miner territory today. The cost of waiting for post-Codex is zero.

References

Modern Bitcoin Core's banman.{cpp,h} — the canonical reference implementation
(BOB) / dobbscoin-source/src/banlist.{cpp,h} (if present in (BOB)'s vintage of the codebase — verify)
src/main.cpp::Misbehaving() — current OFF misbehavior counter, untriggered consequence
src/net.cpp::CNode::fDisconnect — current disconnect mechanism (one-shot, no persistence)
Companion issues #15 (Qt polish) and #16 (Disconnect right-click) for the menu plumbing this will hang off

The Sleeping God's blacklist is long but unread. Iä Iä.

**Epic. Do-not-merge-pre-Codex.** Tracked here for design discussion + post-Codex implementation. ## Why OFF has **no banlist infrastructure today.** No `CBanList`, no `banlist.dat`, no `setban` / `listbanned` / `clearbanned` RPCs, no Qt right-click → Ban action. Verified by searching the tree: ``` $ grep -nE "disconnectnode|setban|CBanList|banlist" src/rpc*.cpp src/net.cpp (no hits) $ ls src/banlist* src/banman* 2>/dev/null (no files) ``` The misbehavior counter (`CNodeState::nMisbehavior`, `Misbehaving()`) exists and trips at `-banscore=100` (default), but the consequence is just disconnect — there's no persistent record, and the peer can immediately reconnect via addrman. There's no way to manually ban a known-bad IP. For the post-Restoration era, with the chain having a known >80%-hash attacker and external eyes increasing as the BCT announcement lands, OFF will want this. Not today, but soon. ## What's needed (scope) This is a real backend feature, ~200+ LOC across multiple files. Rough plan, modeled on modern Bitcoin Core's `banman.{cpp,h}`: ### 1. `src/banlist.{cpp,h}` or equivalent (new files) - `CBanEntry` — single ban record: subnet/CIDR, ban-until timestamp, reason (manual / misbehavior / consensus) - `CBanList` (or BanMan) — in-memory map of CSubNet → CBanEntry, persistence to `banlist.dat`, sweep timer to expire timed bans, thread-safe interface - Functions: `IsBanned(CNetAddr)`, `Ban(CSubNet, ban_reason, ban_time_offset)`, `Unban(CSubNet)`, `ClearBanned()`, `GetBanned()` ### 2. `src/net.cpp` integration - Hook `IsBanned` check on inbound `accept()` path (`net.cpp` connection acceptance) - Hook on outbound peer-selection (don't reconnect to a banned peer via addrman) - Hook into `Misbehaving()` so a peer crossing the banscore threshold gets an auto-ban (existing OFF behavior is just disconnect — no persistence) ### 3. `src/init.cpp` - Load `banlist.dat` on startup - Persist before shutdown ### 4. RPCs - `setban <subnet> <add|remove> [bantime] [absolute] [reason]` - `listbanned` - `clearbanned` ### 5. Qt integration (much smaller) - Right-click → Ban Node action in the Peers tab context menu (depends on #15 / #16 landing first) - Maybe a banlist viewer/editor dialog (defer to a separate UI follow-up) ## Why post-Codex This touches `net.cpp` connection-accept and peer-selection paths. Bugs in those paths surface as network partitions or peer-discovery failures — exactly what cannot happen during the inscription window (blocks 999,991 → 1,050,666). Hard freeze: not merging until **block 1,050,667 or later**. ## Open design questions (for future discussion) - **Default auto-ban from `Misbehaving()`?** Modern Bitcoin Core auto-bans on banscore threshold. Should OFF? Pro: shuts up sustained attackers. Con: misbehaving bots are an attack vector for partitioning honest nodes if the threshold is easy to trigger from outside. - **Subnet granularity.** /32 (single IP) only, or full subnet support? Modern upstream supports `CSubNet`; the persistence format would match. - **Persistence format compat.** Should `banlist.dat` be wire-compatible with Bitcoin Core's, or OFF-specific? Compat means external tooling (some block explorers, monitoring scripts) can read it. - **Ban reasons enum** — manual / misbehavior / consensus / DoS-protection / ... what set? ## What this isn't - **Not consensus-changing** — banning is a peer-policy decision, not a consensus decision. - **Not urgent.** OFF is single-Conclave-miner territory today. The cost of waiting for post-Codex is zero. ## References - Modern Bitcoin Core's `banman.{cpp,h}` — the canonical reference implementation - (BOB) / `dobbscoin-source/src/banlist.{cpp,h}` (if present in (BOB)'s vintage of the codebase — verify) - `src/main.cpp::Misbehaving()` — current OFF misbehavior counter, untriggered consequence - `src/net.cpp::CNode::fDisconnect` — current disconnect mechanism (one-shot, no persistence) - Companion issues #15 (Qt polish) and #16 (Disconnect right-click) for the menu plumbing this will hang off --- *The Sleeping God's blacklist is long but unread. Iä Iä.*

dobbscoin closed this issue

2026-08-12 22:51:59 +00:00

No labels

enhancement

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

SubGeniusFinance/Offerings-to-Cthulhu#17

No description provided.

Rows
Columns