Security Roadmap

1. Status legend

2. Roadmap items

Status pills update from doc/SECURITY-ROADMAP.md on each release. If the table here disagrees with the source doc, the doc wins.

3. OSS-Fuzz integration scaffold landed (v1.1.2)

Priority: High   Effort: 2–4 person-weeks (scaffold shipped; OSS-Fuzz onboarding pending)

Bitcoin Core ships 60+ libFuzzer harnesses under src/test/fuzz/ — B3Chain inherits all of them. Two harnesses specifically belong to B3Chain:

• BLAKE3 SIMD dispatcher: random-input differential test of SIMD vs portable, fail on any mismatch (the audit-simd-blake3.py assertion, running 24/7).
• Any new consensus parser code introduced by the PoW swap.

Status (v1.1.2). The libFuzzer harnesses for the B3Chain-specific paths landed and run locally via the standard Bitcoin Core build flags. What remains is the OSS-Fuzz project-onboarding step (Google's side, plus the project.yaml upstream).

Why it matters. OSS-Fuzz runs on Google's infrastructure with thousands of CPU-hours. A reachable bug is found in days rather than years.

4. Reproducible Guix builds proposed

Priority: High   Effort: 1–2 person-weeks

Bitcoin Core's Guix pipeline produces byte-identical binaries on any machine. B3Chain inherits this. The B3Chain-specific additions:

• Pin the vendored BLAKE3 C library to a specific upstream SHA; Guix manifest verifies it at build time.
• Each release publishes binary SHA-256s; anyone can rebuild and verify byte-for-byte.

Why it matters. Defends against compromise of any single maintainer's build environment (CCleaner 2017, SolarWinds 2020).

5. Continuous benchmark CI live (v1.1.2)

Priority: Medium   Effort: 1 person-week (shipped)

The dedicated benchmark workflow at .github/workflows/benchmark.yml (v1.1.2) runs on every PR alongside the comparison harness compare-bench.yml and fails if BLAKE3 primitive throughput regresses by more than 10% versus the pinned baseline. The throughput-comparison page (compare-pow-throughput) is regenerated from that same workflow's output.

Future work:

• Wire up the block-validation benchmark on a nightly cadence.
• Result-over-time chart on this site.
• Add a physical power meter to the runner for an energy regression curve.

6. External cryptographic audit proposed

Priority: Critical (blocks mainnet launch)   Effort: 4–8 wk audit firm + 2 wk internal   Cost: $40K–$120K USD

Engage a reputable cryptography firm (Trail of Bits, NCC Group, Cure53, Quarkslab, Least Authority) for a focused review of:

• B3PoW-Scratch v1.1.1 integration: every diff that touches pow.cpp, validation.cpp PoW paths, chainparams.cpp, crypto/b3pow_scratch.cpp, crypto/b3pow_cache.cpp, crypto/blake3/.
• Address format changes (key_io.cpp, base58/bech32 wiring).
• HD wallet coin_type swap.

The firm is not asked to re-audit Bitcoin Core itself — that is Bitcoin's reviewers' job.

Deliverable. Public audit report hosted on b3chain.org, with all findings and remediations linked.

7. Bug bounty programme proposed

Priority: High (post-launch)   Effort: 1 wk setup + ongoing triage   Cost: tiered ($250–$50K per finding)

Hosted on Immunefi, HackerOne, or self-hosted with a published scope and disclosure policy.

8. Post-quantum signature experiment proposed

Priority: Low (nothing breaks if deferred)   Effort: 4–6 person-weeks

Add a separate, non-activated transaction version that uses Falcon-512 or Dilithium-2 alongside ECDSA. Measure:

• Transaction size (PQC sigs are 1–4 KB vs ECDSA's 71 bytes).
• Verification CPU cost.
• UTXO set growth.
• Mempool behaviour with full PQC-tx workloads.

Measurement only. No consensus change. Data informs a future decision about whether/when/how to deploy PQC-protected outputs.

Why it matters. When (not if) capable quantum hardware appears, ECDSA preimages can be recovered from public keys exposed by spent outputs. Bitcoin and forks share this exposure. Doing the measurement now means we are not surprised later.

9. Mainnet checkpoint key ceremony proposed

Priority: Medium (else deferred)   Effort: 1 wk ceremony + per-checkpoint ongoing

If the project decides to ship maintainer-signed checkpoints:

• Multi-party, M-of-N (e.g. 3-of-5 maintainer keys).
• In-person ceremony with attendees, video, and post-ceremony attestation hashes.
• Geographically-distributed hardware wallets, scheduled key rotation.
• Published checkpoint-publication policy: when, by whom, under what process.

Status note. Deferred unless and until 51% attack probability becomes a real operational concern. Documented here so we have the procedure ready if needed.

10. Hardware-rooted miner integrity proposed

Priority: Low (research-grade)   Effort: 6–10 person-weeks

Mining pools today have no clean way to verify that a connected miner runs the agreed-upon software. A TPM-based attestation could let a pool require a signed unmodified miner binary, enforce version policy, and bind suspicious behaviour to a hardware identity rather than just an IP.

Research-grade — no industry deployment we can copy. Listed as a long-term direction, not a launch blocker.

11. Continuous 51%-attack monitoring live (v1.1.2)

Priority: High   Effort: 2 person-weeks (shipped)

A long-running Python daemon (contrib/monitoring/51attack-watch.py) that polls b3chaind RPC and tails its debug.log, emitting JSONL alerts (and optional webhook POSTs) for eight distinct 51%-attack signatures. Operator-deployment notes are in doc/security/51-MONITORING-OPS.md, and a one-page summary lives at testing/operator-tools.html#watch.

Status (v1.1.2). Shipped with unit tests and an end-to-end smoke test covering all 8 alert kinds. Running in production on every operator-run seed.

12. M-14 operator-pinned chain recovery live (v1.1.3)

Priority: High   Effort: 3 person-weeks (shipped)

Five RPCs (finalizeblock, unfinalizeblock, parkblock, unparkblock, getfinalizedblockhash) that let the operator declare the canonical tip and refuse any deeper reorg from a competing fork. Wired in src/rpc/blockchain.cpp, enforced in src/validation.cpp, persisted via src/node/blockstorage.cpp. Detailed in testing/operator-tools.html#m14; response procedure in doc/security/RESPONSE-RUNBOOK-51ATTACK.md.

Status (v1.1.3). Shipped with the A-10 Phase 11 audit entry and persistence-plus-bypass-path coverage. Item 7 above (mainnet checkpoint key ceremony) is the multi-party, out-of-protocol counterpart and remains deferred unless and until 51% attack probability becomes an operational concern; M-14 is the in-protocol single-operator primitive that does not wait on the ceremony to be useful.

13. How this list evolves

1. New items are opened as a GitHub issue with the roadmap-proposal label, then merged into the source document at the next maintainers' review.
2. Items move through proposed → in-progress → done with a brief note in the row.
3. Items can move to deferred with a written reason; never silently removed.
4. This page regenerates from the source doc on each release.

14. Source files

• doc/SECURITY-ROADMAP.md — the master roadmap document
• doc/SECURITY-AUDIT.md — the Phase 11 self-audit master checklist
• doc/SECURITY-INHERITANCE.md — the Bitcoin inheritance inventory