Fuzzing

Fuzzing feeds generated inputs into parsers, script evaluators, P2P handlers, and other edge-heavy code. Tidecoin inherits Bitcoin Core fuzz infrastructure and adds post-quantum and transport-related coverage.

This page summarizes the workflow. The source of truth is ../tidecoin/doc/fuzzing.md.

libFuzzer Quickstart


cmake --preset=libfuzzer
cmake --build build_fuzz
FUZZ=process_message build_fuzz/bin/fuzz

Run the fuzz test runner:


build_fuzz/test/fuzz/test_runner.py --help

Use --preset=libfuzzer-nosan for throughput runs without the normal sanitizer overhead.

Useful Targets

Target	Area
`process_message`	P2P message processing
`script_interpreter` / `eval_script`	Script execution
`key_io` / `bech32`	Address and key encoding
`psbt`	PSBT parsing and mutation
`bip324_pq`	Post-quantum transport framing
`pow`	Proof-of-work related parsing/checking

Check src/test/fuzz/ for the full list.

Corpus Workflow

Run a harness until it finds new coverage or failures.
Save interesting generated inputs.
Re-run with sanitizers enabled.
Minimize crashing inputs before opening a PR.
Report security-sensitive crashes privately.

Fuzzing often needs long runs. Fast local smoke runs are useful, but deep parser coverage can take many hours or days.

Triage Rules

Finding	Action
Crash in consensus, script, PQ parsing, wallet secret handling, or P2P parsing	Treat as potentially security-sensitive until understood.
Assertion failure from invalid fuzz input	Check whether the harness should reject earlier or the code should handle it.
Timeout or OOM	Minimize input and inspect for algorithmic complexity risk.
Sanitizer report	Reproduce with the same build and preserve the input.

Do not open a public issue for a suspected vulnerability. Use Security Reporting.

See also: Testing, Functional Tests, PQ Test Vectors.