[StanCan321]

qt: add opt-in Ord installation and initial index

Summary

• add an experimental, default-off Ord option to the first-run data-directory dialog
• configure the unpruned node, transaction index, RPC server, and REST settings Ord needs while rejecting conflicting command-line arguments
• open the official Ord 0.29.0 release in the system browser, accept the downloaded archive through a file picker, verify a platform-specific pinned SHA-256 checksum, extract it, verify ord --version, and install it atomically
• wait for Bitcoin initial block download and txindex synchronization before running ord index update with cookie authentication
• keep inscription and wallet operations in the Ord command-line interface; this PR does not add inscription controls to the Qt wallet
• document storage, terminal use, security considerations, removal, and the pinned-release update procedure

Supported prebuilt targets are Linux x86_64, Windows x86_64, macOS x86_64, and macOS arm64. Other platforms receive an actionable error and continue to be supported with Ord disabled.

Security and failure handling

• the option is disabled by default
• Bitcoin Qt does not implement an additional HTTP/TLS stack; the system browser handles the official GitHub download
• the full release archive must match the checksum compiled into DogMode before extraction
• symbolic-link sources and installation destinations are rejected
• the extracted executable must report the pinned version before and after atomic installation
• archive verification, extraction, startup, and nonzero indexing failures are shown to the user
• Ord process output is bounded to 1 MiB

Test plan

• Native Qt build of bitcoin-qt and test_bitcoin-qt
• Native Qt suite passed
• Depends-built static Qt 6.8.3 package retained disabled HTTP/TLS features while enabling process support
• Qt suite built and passed against the reproducible static depends toolchain
• Local end-to-end fixture for the installation request, checksum verification, extraction, version verification, and installation
• Installer rejection tests for corrupt artifacts, wrong versions, and symbolic links
• Process success, failure, crash, cancellation, and bounded-output tests
• Settings persistence and command-line conflict tests
• Real Ord 0.29.0 regtest functional test covering initial index, resume after restart, and reorg recovery
• Clang 22 clean Docker build with warnings as errors, C++23, ASan, UBSan, integer sanitizer, and float-divide-by-zero sanitizer
• Sanitized Qt suite passed
• Sanitized real-Ord functional test passed with the repository's standard sanitizer suppressions
• Official release checksums independently verified for all four supported assets
• Relevant file, include-guard, include, Python, shell, and Qt translation linters passed or reported their documented missing optional host tools

Follow-ups

The planned Qt drag-and-drop inscription interface is intentionally excluded and should be reviewed separately after this installer/indexing foundation lands.

[Joopooranski]

I reviewed the Ord index lifecycle and found a behavior worth addressing before users rely on it for later inscriptions.

maybeStartOrdIndex() stops m_ord_sync_timer after the first launch, and OrdManager runs ord index update only once. Ord 0.29.0's index update subcommand calls index.update()? and exits. When a new Bitcoin block arrives after the initial run completes, this GUI path never starts another update until Bitcoin Qt restarts. The functional test also explicitly invokes a second index update after mining an additional block; it does not test automatic ongoing updates.

Could we either schedule later updates (and cover a post-completion block in a GUI/integration test), or make the one-time nature explicit in the “Ord synchronized” message and doc/ord.md, including how an operator refreshes it? As written, “Ord synchronized” can become false minutes later while Bitcoin Qt remains open.

I traced this against PR head 8e842fa and Ord's pinned 0.29.0 src/subcommand/index/update.rs. — Joopooranski

[Joopooranski]

I reproduced a wallet-disabled GUI CMake generation failure on this PR: bitcoinqt links Qt6::Network, but the Qt component is not loaded with ENABLE_WALLET=OFF. I opened a one-file fix against this PR’s head: StanCan321#1. With the fix, the wallet-disabled CMake configuration and generation succeed, and bitcoin.cpp.o and ordmanager.cpp.o compile locally. I did not complete the full GUI link.

[Joopooranski]

I put the proposed ongoing Ord index refresh fix in StanCan321#2. It retains the 30-second tip check and restarts ord index update after a new block or same-height reorganization, while avoiding overlapping runs and duplicate initial-success notices. The changed Qt sources compiled locally; the full Qt test executable did not link in my local build, so runtime GUI behavior still needs review.

[krsnak]

Independent Apple Silicon follow-up for the wallet-disabled Qt build issue noted by @Joopooranski: I reproduced the original Qt6::Network CMake generation failure on this PR's head (8e842fa) with macOS 26.6.2 / Qt 6.12.0, and verified that requiring the Network component for all GUI builds fixes configure/generate. Both bitcoin.cpp.o and ordmanager.cpp.o also compiled successfully with ENABLE_WALLET=OFF (full GUI link not claimed). To keep the patch scoped to one file instead of re-submitting Ord, I've opened StanCan321#3 directly against this PR's source branch, crediting Joopooranski's original report and earlier unmerged patch.