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 proposed

Priority: High   Effort: 2–4 person-weeks

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.

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 in-progress

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

The throughput comparison (compare-pow-throughput) runs on every PR via .github/workflows/compare-bench.yml and fails if BLAKE3d throughput regresses by more than 10% versus the pinned baseline.

Future work:

• Wire up 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:

• BLAKE3 PoW integration: every diff that touches pow.cpp, validation.cpp PoW paths, chainparams.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. 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.

12. 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