dgb: wire get_current_gbt_prevhash() through tip_hash() SSOT (Stage 4b) - #217
Merged
Conversation
This was referenced Jun 19, 2026
…rk template (Stage 4c) HeaderSample gains a sha256d block-id slot (block_hash, u256; 0 == not populated here, the same sentinel pow_hash uses) and HeaderChain gains a tip_hash() accessor returning the newest header's id or nullopt when the chain is empty / the tip carries no hash. get_current_work_template emits previousblockhash as GBT-conventional big-endian display hex ONLY when tip_hash() is present -- a truthful conditional, never a fabricated hash. The embedded P2P header-download -> validate_and_append ingest that populates block_hash lands in a following slice; until then tip_hash() is nullopt and previousblockhash is held back exactly as before. bits stays HELD BACK: the only embedded next-target source is the DigiShield damped multiply, which DGB Core runs as MultiShield V4 (a global window across all 5 algos == V37); a Scrypt-only walk cannot reconstruct it, so the ingest path demotes that gate to a no-op. Emitting a digishield-derived bits would be a known-wrong value. The authoritative bits is the external-daemon GBT value, not plumbed into this embedded path yet -- surfaced as [decision-needed]. Fenced to src/impl/dgb (4 files); test cases added to existing targets header_chain_test (31 -> 35) and dgb_work_source_test (15 -> 16), no new gtest target so the build.yml allowlist is unchanged. Both green.
The Stage-4b prevhash getter still returned {} while get_current_work_template
emits previousblockhash from chain_.tip_hash() (#216). Route the getter through
the SAME tip_hash() accessor and u256_be_display_hex formatter so the dedicated
getter and the assembled template cannot silently diverge: one truthful source.
Empty string when tip_hash() == nullopt (empty chain / unpopulated block_hash
sentinel) -- a truthful absence, never a fabricated id. Non-consensus read-only
getter, fenced to src/impl/dgb. +1 test asserting getter == template field on a
seeded tip and joint-absence with no tip; dgb_work_source_test 17/17.
frstrtr
force-pushed
the
dgb/stage-4b-prevhash-getter
branch
from
June 19, 2026 16:47
a36257d to
aad2050
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #216. The Stage-4b prevhash getter still returned an empty string while get_current_work_template() emits previousblockhash from chain_.tip_hash() (#216). This routes the getter through the SAME tip_hash() accessor + u256_be_display_hex formatter so the dedicated getter and the assembled template can never silently diverge — one truthful source.
Test target already in both ctest + build.yml allowlists (no #143 trap). HOLD merge — stack base #216 is itself held behind #211 operator tap.