Skip to content

dgb: tip_hash() accessor + previousblockhash wire (Stage 4c) - #216

Merged
frstrtr merged 1 commit into
masterfrom
dgb/stage-4c-prevhash-accessor
Jun 19, 2026
Merged

dgb: tip_hash() accessor + previousblockhash wire (Stage 4c)#216
frstrtr merged 1 commit into
masterfrom
dgb/stage-4c-prevhash-accessor

Conversation

@frstrtr

@frstrtr frstrtr commented Jun 19, 2026

Copy link
Copy Markdown
Owner

Stacked on #212. Stage 4c continuation: wire previousblockhash into the work template via a new HeaderChain tip_hash() accessor; bits stays HELD (V37 MultiShield-V4 wall) — surfaced as [decision-needed].

What lands

  • HeaderSample gains block_hash (u256; 0 == not populated here, same sentinel as pow_hash).
  • HeaderChain::tip_hash() -> optional: newest header id, or nullopt when empty / tip hash unset.
  • get_current_work_template emits previousblockhash as GBT big-endian display hex ONLY when tip_hash() is present — truthful conditional, never fabricated.

What is HELD

  • bits: no faithful embedded V36 next-target. DGB Core retarget is MultiShield V4 (global 5-algo window) == V37; the ingest path already demotes that gate to a no-op. Emitting a digishield-derived bits = a known-wrong value. Authoritative bits is the external-daemon GBT value, not plumbed into this embedded path yet. [decision-needed] to integrator.
  • previousblockhash output: still absent on todays chain state — block_hash is only populated once the embedded P2P header ingest -> validate_and_append wiring lands (following slice). This PR is the accessor + emit-gate prereq (mirrors dgb: track absolute block height in HeaderChain (M3 §4c prerequisite) #209 tip_height).

Scope / safety

HOLD merge.

…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.
@frstrtr
frstrtr force-pushed the dgb/stage-4c-prevhash-accessor branch from fb8f91b to 30a6d78 Compare June 19, 2026 16:47
@frstrtr
frstrtr merged commit 8a8b0bf into master Jun 19, 2026
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant