Task: reconcile process CPU and isolate the full-script differential

[metaphorics]

Parent

#16

What to build

Produce a mutually exclusive CPU ledger for the allocator-normalized 0→150,000 replay, then compare the complete legacy script-check path with Bitcoin Core rather than comparing only bare ECDSA. The result must identify the one script/kernel mechanism large enough to pursue next, or falsify script work as the source of the CPU deficit.

This ticket does not optimize production code. Diagnostic instrumentation must use the exact frozen source, allocator, compiler, flags, and feature posture from #24, and its timings must never replace the uninstrumented benchmark panel.

Blocked by

• Task: calibrate allocator parity and freeze the matched 0-150k baseline #24

Acceptance criteria

• Report whole-process wall, user CPU, system CPU, mean-core use, and peak RSS from the frozen uninstrumented baseline.
• Attribute per-thread CPU to the apply/main thread, script pool, replay producer, and storage/background workers.
• Attribute CPU, not nested wall alone, to block rules, body persistence, UTXO commit, decode, script preparation, and script execution.
• Reconcile mutually exclusive buckets to process CPU with no more than 5% unexplained remainder; record sampling loss and instrumentation overhead separately.
• Split the script path into Rust wrapper/FFI entry, kernel VerifyScript excluding sighash and ECDSA, legacy SignatureHash, and DER/pubkey parsing plus CPubKey::Verify.
• Add a same-corpus full-script Bitcoin Core comparator. The existing bare-ECDSA census remains a ceiling only.
• Preserve verdicts and deterministic first-error ordering on valid and injected-invalid corpora; make no assume-valid, cache, or consensus change.
• Graduate exactly one attributed mechanism only when its measured bitcoin-rs-specific budget can clear the recomputed 1.05× whole-process CPU gate. Otherwise close that mechanism with evidence.

[coderabbitai]

🔗 Related PRs

#7 - Parallelize block input script checks for performance improvement [merged]
#14 - feat: header timestamp consensus rules, index reorg rollback, mempool policy, fuzz targets [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[metaphorics]

Closing before instrumentation because blocker #24 falsified this ticket's premise.

The fresh allocator-normalized, local-file, full-verification panel is:

• bitcoin-rs mimalloc: 56.16s wall / 396.50 CPU-s;
• Bitcoin Core 31.0: 64.74s wall / 477.82 CPU-s.

bitcoin-rs leads 1.153x wall and 1.205x CPU. The earlier 87–92 CPU-second deficit came from a stale, differently matched panel; there is no current deficit to reconcile. The system-allocator bitcoin-rs arm also used less CPU than Core (399.63 CPU-s), so the conclusion does not depend on mimalloc.

This is the ticket's explicit falsifier: a fresh production-matched baseline moved the CPU gap away from bitcoin-rs. Adding per-thread and native script instrumentation now would optimize an unmeasured problem and contaminate the baseline. Reopen CPU attribution only if a later matched panel assigns bitcoin-rs a gate-sized CPU loss.

Evidence: #29 and docs/solutions/performance/allocator-parity-changes-wall-not-cpu.md.