b3chain / Testing & Verification / Known Limitations

Known Limitations

Things this test corpus deliberately does not cover, and what an external auditor or downstream integrator should still look at. Honesty about scope is more useful than a long list of green ticks.

1. Scope of the published tests

The Phase 11 self-audit and the reproducible suites listed on this site cover the b3chain-specific changes on top of Bitcoin Core 30.2.0: BLAKE3 PoW, address prefixes, magic bytes, supply schedule, HD wallet coin_type, and the rebranding regression. They do not re-audit the upstream Bitcoin Core 30.2.0 code — that work was done by the Bitcoin Core developers and reviewers over many years.

2. What is not covered

  • External audit. No third-party security firm has reviewed b3chain. We will commission one before any mainnet launch is announced. The self-audit is a precondition, not a substitute.
  • Mainnet-only behaviour. The functional checks in the audit run on regtest. The static / source checks confirm that the mainnet code paths are correct (e.g. coin_type 9333), but live mainnet behaviour is not exercised — because there is no mainnet yet.
  • P2P fuzzing depth. The network-isolation audit verifies that Bitcoin magic bytes are rejected. A more aggressive fuzzer (libfuzzer, AFL, AFL++) on the wire-protocol parser is on the roadmap but not run yet.
  • SIMD coverage. The differential test compares the BLAKE3 SIMD implementation against a portable Python reference across edge sizes and 1 000 fuzz inputs. It does not exhaustively test every CPU feature combination on every architecture; that requires a CI matrix we have not yet built.
  • Hardware-wallet integration. The HD wallet coin_type 9333 is proposed but not yet registered with SLIP-0044. Hardware wallets will not recognise b3chain until the registration is accepted (or a manual derivation path is entered).
  • Long-running mainnet attacks. Selfish-mining, eclipse, and sustained 51% attacks need a real network to be meaningful. The regtest 51% demo only proves the consensus logic accepts the longer chain — it does not characterise the cost of attacking the live network.
  • Wallet UI. The Qt GUI was rebranded; there is no formal UX audit, accessibility review, or translation completeness check.

3. What an external auditor should look at first

  1. The diff against upstream Bitcoin Core (focus area: anything that modifies src/primitives/block.{cpp,h}, src/pow.{cpp,h}, src/kernel/chainparams.cpp, and src/wallet/walletutil.cpp).
  2. The dual-hash architecture: are there any code paths that should use GetPoWHash() but use GetHash() (or vice versa)? See H-1.
  3. The early-difficulty-guard logic in src/pow.cpp::GetNextWorkRequired. Static-analysis only catches the obvious mistakes.
  4. The genesis block: are the published constants (0xb32521b577317c19...) reproducible from the published mining tools?

4. Reporting gaps

If you find an attack vector or a bug not covered here, please follow the disclosure procedure on the reporting page.