Skip to content

Add save/resume of scan progress (finish interrupted range on restart) - #2

Open
timon174174174174-source wants to merge 1 commit into
ilkerccom:masterfrom
timon174174174174-source:pr/save-resume-progress
Open

Add save/resume of scan progress (finish interrupted range on restart)#2
timon174174174174-source wants to merge 1 commit into
ilkerccom:masterfrom
timon174174174174-source:pr/save-resume-progress

Conversation

@timon174174174174-source

Copy link
Copy Markdown

Summary

Adds opt-in save/resume of GPU scan progress so an interrupted range isn't lost on restart.

While scanning a pool range, the client periodically writes a crash-safe checkpoint (range identity + per-thread scan offset + found proof keys) to progress/checkpoint_gpu<idx>.txt. On startup, before requesting a new range, it finishes the interrupted range from the saved offset, submits its proof keys, then continues normally.

Why finish-and-submit: the pool assigns a new range on restart and the same range can't be re-requested, so resuming the exact pool range isn't possible. Instead the client completes the interrupted range — exact resume when the GPU thread count matches the checkpoint, full re-scan otherwise — and submits it.

Changes

  • Pool/Checkpoint.{h,cpp} — atomic checkpoint (temp + rename) serialization
  • RangeMath.{h,cpp} — GPU partition arithmetic, kept in sync with getGPUStartingKeysMT
  • VanitySearch — resume offset applied per GPU thread; periodic progress callback (single-GPU)
  • PoolClientstd::mutex around foundKeys (now read concurrently by the monitor thread) + getFoundProofPairs
  • main.cpp — resume branch + checkpoint write/clear lifecycle
  • save_progress flag — pool.conf / -saveprogress / Docker SAVE_PROGRESS (default on)
  • Build wiring: Makefile, VS project, .gitignore (/progress), README, Dockerfile, btcpuzzle.sh

Privacy: the checkpoint never stores the target private key (only proof keys, which already go to the pool), so untrusted-computer mode's guarantee is preserved.

Testing

  • Unit tests for Checkpoint (round-trip, atomicity, corrupted file) and RangeMath (partition tiling, floor offset) under tests/ — each builds & runs with a single g++ command (in-file).
  • Full CUDA build verified on Linux (Docker) and Windows (MSBuild).
  • End-to-end on puzzle 71 (RTX 5070): checkpoint written with advancing offset; after kill+restart the client logs [RESUME] resumed from per-thread offset 0x... and finishes the range.

Notes

  • save_progress defaults to true; set save_progress=false to disable.
  • Removes a dead saveProgress() stub that was never wired up.

🤖 Generated with Claude Code

Periodically persist a crash-safe checkpoint (range identity + per-thread
scan offset + found proof keys) while scanning a pool range. On startup,
before requesting a new range, finish the interrupted range from the saved
offset and submit its proof keys, then continue.

The pool hands out a new range on restart and the same range cannot be
re-requested, so the client completes the interrupted range (exact resume
when the GPU thread count matches the checkpoint, full re-scan otherwise)
and submits it.

- Pool/Checkpoint.{h,cpp}: atomic checkpoint serialization (+ unit tests)
- RangeMath.{h,cpp}: GPU partition arithmetic in sync with
  getGPUStartingKeysMT (+ unit tests)
- VanitySearch: per-thread resume offset; periodic progress callback (single-GPU)
- PoolClient: mutex around foundKeys; getFoundProofPairs accessor
- main: resume branch + checkpoint write/clear lifecycle
- save_progress flag (pool.conf / -saveprogress / SAVE_PROGRESS), default on
- never persists the target private key (only proof keys)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@brookehoward2008-droid

Copy link
Copy Markdown

Ok

@brookehoward2008-droid brookehoward2008-droid left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

@theone4200 theone4200 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good

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.

5 participants