fix(bump): climb single-subtree compound BUMP to block root (#167)

[rafa-js]

What Changed

• BuildCompoundBUMP's single-subtree path now folds the subtree root up to the true block-header merkle root using the coinbase BUMP's left-spine siblings (new extendSubtreeToBlockRoot helper in bump/bump.go).
• Added a regression test (bump/issue167_test.go) plus the real captured inputs as fixtures (bump/issue167_fixtures_test.go) from mainnet block 950675.

Why It Was Necessary

• A single-subtree block whose coinbase sits outside the subtree has a block tree taller than the subtree STUMP (for block 950675: block height 16 vs STUMP internal height 15, 39,657 txs). The old single-subtree shortcut treated the STUMP as the full block path and returned the subtree root instead of the block root.
• ValidateCompoundRoot therefore rejected the compound (computed e0360bc5… ≠ header 32d293e3…), no BUMP was persisted, and the block's tracked transactions were stuck at SEEN_MULTIPLE_NODES and never reached MINED. The failure is deterministic, so /reprocess could not recover it.
• Fixes [Bug] Compound BUMP for single-subtree blocks computes wrong merkle root → txs stuck at SEEN_MULTIPLE_NODES, never reach MINED #167.

Testing Performed

• New test reproduces the production failure (computed e0360bc5… ≠ header 32d293e3…) before the fix and passes after; it also verifies every tracked tx's minimal path computes the canonical block-header merkle root 32d293e3….
• go test ./bump/ and go test ./services/bump_builder/: pass. go build ./...: clean.
• golangci-lint v2.12.2 (CI-pinned) on ./bump/: 0 issues. gofmt: clean.

Impact / Risk

• Low. The new fold is a no-op when the coinbase BUMP is not taller than the STUMP, so power-of-two single-subtree blocks and all multi-subtree blocks are unaffected (the full bump suite still passes). Only previously-failing single-subtree blocks change behaviour — from "rejected, no BUMP" to a valid, header-reconciling compound BUMP.

Notifications

• @mrz1836

[github-actions]

👋 Thanks, @rafa-js!

This pull request comes from a fork. For security, our CI runs in a restricted mode.
A maintainer will triage this shortly and run any additional checks as needed.

• 🏷️ Labeled: fork-pr, requires-manual-review
• 👀 We'll review and follow up here if anything else is needed.

Thanks for contributing to bsv-blockchain/arcade! 🚀

[galt-tr]

Thank you, good catch. I am surprised we didn't catch this before; I see many single subtree blocks on TTN where this isn't the case. Wondering if theres something unique about how teranode stores blocks from a legacy sv node?

regardless, I can confirm this is a real bug.