perf(crypto): enable configured SHA256 acceleration

[PastaPastaPasta]

Issue being fixed or feature implemented

Dash Core's SHA-256 runtime dispatcher did not include the generated configuration header. As a result, it could not see configured ENABLE_* feature macros even when the corresponding optimized implementations were built and linked.

On ARM64 this left CSHA256 using the portable implementation instead of the configured ARMv8 SHA2 implementation. On supported x86 builds it also prevented the dispatcher from selecting configured SHA-NI and multi-way implementations, although the existing single-way SSE4 fallback remained available.

Regression history

The optimized SHA-256 implementations were inherited from Bitcoin Core and originally worked in Dash because crypto/sha256.cpp received the generated configuration macros transitively through crypto/common.h.

Bitcoin Core removed that fragile transitive dependency in bitcoin/bitcoin#29404, merged on February 20, 2024. That PR added explicit bitcoin-config.h includes to translation units that consume configuration macros, including the exact include added here to crypto/sha256.cpp.

Bitcoin subsequently merged bitcoin/bitcoin#29263 on March 1, 2024, which removed bitcoin-config.h from crypto/common.h. This was safe upstream because bitcoin#29404 had already made the direct dependencies explicit.

Dash backported bitcoin#29263 in dashpay/dash#6378, merged on February 21, 2025, without first backporting bitcoin#29404. This removed the only path by which crypto/sha256.cpp saw ENABLE_SSE41, ENABLE_AVX2, ENABLE_X86_SHANI, and ENABLE_ARM_SHANI, silently disabling those configured runtime selections while preserving correct portable SHA-256 behavior.

The regression is present in Dash Core releases v23.0.0 through v23.1.8. It is therefore a Dash backport dependency gap rather than a defect Bitcoin shipped.

dashpay/dash#7124 is an open, broader backport of Bitcoin bitcoin#29404 and contains the same sha256.cpp hunk among many configuration-include cleanups. This PR intentionally isolates the performance-critical SHA-256 fix so it can land independently.

What was done?

Include config/bitcoin-config.h from crypto/sha256.cpp when HAVE_CONFIG_H is defined, restoring the exact upstream sha256.cpp change from Bitcoin bitcoin#29404.

Runtime feature detection and the existing SHA-256 self-test remain responsible for selecting and validating the implementation. Builds using DISABLE_OPTIMIZED_SHA256, including libdashconsensus, remain unaffected.

How Has This Been Tested?

Tested on Apple Silicon using the depends-based build:

• Full make build
• Full make check
• Verified startup selection changed from standard to arm_shani(1way,2way)
• SHA-256 benchmark throughput improved from approximately 562 MB/s to 2.66 GB/s (4.7x)
• A real rust-dashcore full testnet sync through a proxy adding 50 ms in each direction (approximately 100 ms RTT) improved from a 28.402 second median to 22.943 seconds (19.2%) across three measured runs per build

The end-to-end comparison held the testnet data, rust-dashcore revision, proxy configuration, and other Dash Core changes constant; only the generated-config include differed between the two measured builds.

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone

This pull request was created by Codex.

[coderabbitai]

Walkthrough

src/crypto/sha256.cpp now checks HAVE_CONFIG_H. When defined, the file includes <config/bitcoin-config.h>. No exported or public declarations changed.

Estimated code review effort: 1 (Trivial) | ~2 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes enabling configured SHA-256 acceleration, which is the main change.
Description check	✅ Passed	The description directly explains the configuration-header fix, its performance impact, testing, and compatibility details.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

✅ Final review complete — no blockers (commit 5881f94)

[thepastaclaw]

Final validation — Codex/Sol only (Phase 2 disabled)

The exact-head diff is a focused four-line change that restores direct access to the generated SHA-256 feature macros, with optimized implementations conditionally built and linked under the same configuration flags. The guarded include exactly matches the relevant upstream bitcoin#29404 hunk, preserves DISABLE_OPTIMIZED_SHA256 behavior, and introduces no actionable defects.
Source: reviewer backends gpt-5.6-sol (general, dash-core-commit-history, and backport-reviewer); final verifier backend gpt-5.6-sol. openclaw-agent/cliproxy/gpt-5.6-sol was orchestration-only and is not reviewer evidence.

Validated zero-blocker Codex/Sol precheck evidence was promoted to final because Phase 2 (Sonnet/Opus) is temporarily disabled. This is Codex/Sol-only final validation, not Codex + Sonnet/Opus coverage.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — dash-core-commit-history (completed), gpt-5.6-sol — backport-reviewer (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet/Opus: not run (Phase 2 disabled — temporary Codex/Sol-only final)
• Secondary pass: disabled (temporary_phase2_sonnet_disable)

[knst]

utACK 5881f94