OpenPuzzle 1.0.20

OpenPuzzle 1.0.20 — Puzzle-aware engine routing and resilient solution alerts

OpenPuzzle 1.0.20 adds metadata-driven routing between linear keyspace
searches and Pollard Kangaroo workloads while preserving the existing Puzzle
71 execution path.

Puzzle-aware execution

• Puzzle 71 remains a linear workload using bundled BitCrack CUDA/OpenCL or
  KeyHunt CPU execution.
• The packaged catalogue adds puzzles 140, 145, 150, 155 and 160 with their
  compressed public keys, HASH160 values, exact keyspaces and mandatory CUDA
  routing metadata.
• Unknown, incomplete or contradictory puzzle metadata fails closed before an
  assignment is requested or an engine is launched.
• Kangaroo claims require exact power-of-two ranges and validate the returned
  assignment shape before execution.

These routing rules do not change assignment fairness. Hardware performance is
used only for compatible execution and range sizing, never for priority.

External PSCKangaroo integration

The client includes a CUDA-only PSCKangaroo adapter, command construction,
progress parsing and a protected result-file bridge into OpenPuzzle's standard
found.txt workflow.

PSCKangaroo is deliberately not bundled in the Debian package. Installation is
an explicit user-local action:

openpuzzle engine install psckangaroo

Without a validated external executable, Kangaroo routing fails closed before
registration or assignment claim. A valid external installation makes the
planner ready without changing the bundled BitCrack and KeyHunt engines.

Resilient solution reporting

A possible solution remains entirely local. OpenPuzzle preserves the protected
workspace and wallet-import file and submits only the assignment identifier and
anonymous client identifier for review. Private-key material, engine output and
filesystem paths are never transmitted.

If the metadata-only report cannot be delivered because of a temporary network
failure, the client retries automatically every 30 seconds. Local state remains
preserved across interruption or restart until reporting succeeds.

Compatibility and validation

• Existing linear clients and Puzzle 71 assignments remain compatible.
• Rusticl OpenCL selection and persistent process-identity protections from
  earlier releases remain in force.
• The complete client suite passes 98 of 98 automated tests.
• The targeted transient solution-report retry test passes.
• The validated release binary SHA-256 is
  799950bb41097b027b040616d3c3c879c2a9d93b2c124c2a13c6902369a752c4.

The Debian package contains BitCrack CUDA/OpenCL and KeyHunt. PSCKangaroo
remains an external, opt-in executor.

OpenPuzzle 1.0.19 — Persistent Rusticl and reliable release manifests

OpenPuzzle 1.0.19

OpenPuzzle 1.0.19 makes Rusticl/OpenCL diagnostics consistent with runtime execution and hardens the release update contract.

• A validated --rusticl-enable <selector> is persisted as rusticl_enable.
• Future OpenCL runs, benchmarks and openpuzzle doctor reuse that selector.
• No Rusticl driver is guessed or enabled unless the user selected it.
• scripts/create_release_manifests.sh creates both the versioned manifest and the stable SHA256SUMS.txt required by the updater.
• The manifest generator validates exactly one portable package and its SHA-256 filename prefix.

OpenPuzzle 1.0.18 — Full Linux process identity

OpenPuzzle 1.0.18

OpenPuzzle 1.0.18 hardens Linux process identity against PID reuse
within the same system boot.

Full Linux process identity

Persistent execution identity is now bound to:

• Linux boot ID;
• process ID (PID);
• /proc/<pid>/stat field 22 (starttime).

A numeric PID can be reused by Linux. The boot ID added in OpenPuzzle
1.0.17 prevents stale processes from a previous boot being mistaken for
current executions, while the process start time added in 1.0.18 also
distinguishes two different processes that receive the same PID during
one boot.

Persistent client state

client.state now stores:

pid=<pid>
boot_id=<boot-id>
process_start_time=<starttime>

States written by OpenPuzzle 1.0.17 or earlier remain readable, but an
execution state without process_start_time is not accepted as proof
that a process is still active.

Legacy or incomplete identities fail closed and enter the normal
recovery path.

Execution workspace identity

Background execution workspaces now persist:

process.pid
process.boot_id
process.start_time

The execution monitor and stopper require all three identity components
to match.

Safe process stopping

ExecutionStopper revalidates the original process identity throughout
the stop sequence.

If the original process disappears or its start time no longer matches,
the execution is treated as gone. A reused numeric PID is not treated as
the original execution.

Identity is rechecked before termination and escalation operations,
including before SIGKILL.

Runtime control

Runtime marker files now contain three fields:

<pid>
<boot_id>
<process_start_time>

OpenPuzzle 1.0.17 two-field runtime markers and older PID-only markers
fail closed and are treated as stale.

requestStop() uses Linux pidfds for signal delivery after validating
the persisted process start time. This removes the PID-reuse race
between identity verification and SIGTERM delivery without persisting a
pidfd across OpenPuzzle processes.

Update safety

The updater now considers a client execution active only when its
persisted boot ID, PID and process start time match the live process.

Runtime activity checks use the same full process identity.

Compatibility

No server API or Bitcoin puzzle protocol change is required.

The additional state and marker fields are local Linux runtime metadata.

Older state remains parseable but cannot be used as positive process
identity without the new start-time field.

Validation

OpenPuzzle 1.0.18 passed all 89 automated tests, including coverage for:

• exact live process identity;
• boot mismatch;
• same-boot PID reuse;
• missing legacy process start time;
• launcher start-time persistence;
• execution monitor identity validation;
• stopper protection against reused PIDs;
• runtime marker migration;
• pidfd signal delivery;
• updater active-execution validation.

OpenPuzzle 1.0.17

OpenPuzzle 1.0.17

OpenPuzzle 1.0.17 hardens process identity across reboot, power loss and
Linux PID reuse.

Persistent process identity now includes the system boot

Linux process identifiers are reused over time. A PID stored before a reboot
can therefore later refer to an unrelated process.

OpenPuzzle now persists the Linux system boot_id together with execution
process state. A stored process is considered potentially active only when:

• the stored boot_id exists;
• the current system boot_id can be read;
• both boot identifiers match; and
• the stored PID still exists.

If any identity check fails, the persisted PID is not trusted.

Safe handling of legacy state

OpenPuzzle 1.0.16 and earlier did not persist a boot identifier.

Legacy execution state and PID-only runtime markers are therefore handled
conservatively. OpenPuzzle does not treat a numerically live PID as proof that
the old execution still exists.

This prevents an unrelated process that happens to reuse the same PID from
being mistaken for OpenPuzzle work.

Runtime-control markers are boot-bound

The persistent runtime markers used by CPU, GPU, CUDA and OpenCL slots now
store both the runtime PID and the current boot_id.

Runtime discovery, safe-stop requests and direct stop requests validate both
values before acting on the stored PID.

A stale marker from a previous boot can be removed safely without signalling
the unrelated process that may now own that PID.

Engine supervisors are boot-bound

Background execution workspaces now persist a process.boot_id alongside
process.pid.

The background launcher reads the current system boot identity before starting
the supervisor. If boot identity cannot be determined, the execution is not
launched.

Execution monitoring and ExecutionStopper require the workspace boot
identity to match the current boot before treating the supervisor as active or
sending signals to its process or process group.

Recovery, updates and heartbeat use the same identity rules

Persistent PID checks are protected consistently across:

• interrupted-execution recovery;
• explicit execution stopping;
• runtime-control state;
• background supervisor monitoring;
• guarded update detection;
• client heartbeat status reporting.

This prevents a reboot followed by PID reuse from causing OpenPuzzle to report
an unrelated process as an active assignment or to signal it accidentally.

Direct signals to subprocesses created with fork() by the current running
OpenPuzzle process remain unchanged because those PIDs are not recovered from
persistent state.

Compatibility and fairness

Normal successful execution, failure reporting, interrupted-assignment
recovery and concurrent CUDA/OpenCL operation remain unchanged.

Assignment fairness is unchanged. Process identity has no effect on priority,
reputation, scheduling rights or access to work.

Validation

OpenPuzzle 1.0.17 passed all 88 automated tests.

Additional process-identity coverage verifies:

• persisted execution state round-trips its boot_id;
• a live numeric PID with a mismatched boot identity is rejected;
• legacy execution state without boot_id fails closed;
• stale runtime PID markers cannot signal a reused process;
• runtime markers persist the current system boot identity;
• workspace supervisors persist and validate process.boot_id;
• the execution monitor does not treat a reused PID from another boot as
  running;
• the execution stopper refuses to signal a process whose workspace boot
  identity does not match;
• heartbeat reporting ignores stale or legacy PID-only execution state;
• update safety checks require matching boot identity before reporting a
  persisted execution as active.

The complete automated suite remains at 88 passing tests.

OpenPuzzle 1.0.16

OpenPuzzle 1.0.16

OpenPuzzle 1.0.16 adds resilient recovery for client executions interrupted by
a reboot, power loss or other abrupt system shutdown.

Interrupted executions are no longer mistaken for completion

OpenPuzzle stores a local execution state while an assignment is running. The
background supervisor normally writes exit.code before it terminates.

If the stored supervisor process has disappeared and no exit.code exists,
OpenPuzzle now classifies the execution as an abrupt interruption instead of
waiting indefinitely for a file that can never appear.

Interrupted executions use the internal exit code -3 and are reported to the
coordination server with status cancelled.

Progress and assignment state are preserved safely

The most recent available engine progress is included when an interrupted
assignment is reported.

If the coordination server is temporarily unavailable, the local execution
state is retained and synchronization can be retried later. OpenPuzzle does
not discard the assignment merely because the machine restarted or the
network is unavailable.

The local state is removed only after the server accepts the final report, or
when the server explicitly rejects the assignment as no longer valid.

Concurrent CUDA and OpenCL recovery

CUDA and OpenCL runtime slots remain independent during recovery.

A failed or interrupted CUDA slot cannot remove or overwrite the OpenCL slot,
and vice versa. After a complete system restart, both stale slots can be
recovered independently.

Once each cancellation is acknowledged by the coordination server, its local
state is removed and that slot is free to request new work.

Compatibility and fairness

Normal successful executions continue to report completed with exit code
0. Normal engine failures continue to report failed with their non-zero
exit code.

Existing single-backend and concurrent CUDA/OpenCL workflows remain
compatible.

Assignment fairness is unchanged. Recovery status does not affect priority,
reputation or access to work.

Validation

OpenPuzzle 1.0.16 passed all 88 automated tests.

Additional recovery coverage verifies:

• dead process with missing exit.code is classified as interrupted;
• interrupted assignments use cancelled with exit code -3;
• temporary server failure preserves local state;
• successful server acknowledgement removes the recovered slot;
• CUDA and OpenCL states remain isolated;
• two interrupted GPU slots can be recovered independently;
• the HTTP completion payload carries the expected cancellation status,
  exit code and progress information.

The BitCrack third-party license used for release validation was also verified
against the upstream brichard19/BitCrack MIT license.

OpenPuzzle 1.0.15

OpenPuzzle 1.0.15

OpenPuzzle 1.0.15 adds safe concurrent CUDA and OpenCL GPU execution. A single
openpuzzle run command can now start one CUDA worker and one OpenCL worker on
separate physical GPUs.

One command, two GPU backends

Concurrent execution is enabled explicitly, for example:

openpuzzle run --backend cuda --device 0 --with-opencl --opencl-device 1 --rusticl-enable radeonsi

CUDA and OpenCL use independent runtime slots, assignments, workspaces, engine
processes, progress uploads and completion reporting. Either slot can finish
and request its next range without taking control of the other slot.

Validation before server contact

OpenPuzzle resolves and validates both GPU selections locally before creating
the concurrent workers or requesting an assignment. An unavailable device
index is rejected with the actionable OP-GPU-001 diagnostic.

When Rusticl is requested, its driver selection is applied before OpenCL
enumeration so the device indexes shown to OpenPuzzle match the intended
OpenCL driver.

Separate physical GPUs required

The CUDA and OpenCL selections must represent different physical GPUs. If both
backends resolve to the same PCI device, OpenPuzzle rejects the launch before
server contact. This prevents two workers from accidentally competing on one
GPU because different APIs assigned it different logical indexes.

Fair scheduling remains unchanged

Concurrent execution does not change assignment priority. Every client keeps
the same right to receive work. Device performance is used only to size each
range for its target duration; it does not affect queue position, reputation
or assignment access.

Compatibility

Existing one-backend commands and stored profiles continue to work. Concurrent
OpenCL execution is opt-in through --with-opencl; systems with only one GPU
can continue using the normal openpuzzle run workflow.

Validation

The release source passed all 88 automated tests, including focused coverage
for invalid CUDA and OpenCL indexes, duplicate physical GPU selection, Rusticl
ordering and successful independent preflight. Live negative-path validation
confirmed that rejected launches request no assignment and leave existing CUDA
and OpenCL workers undisturbed.

OpenPuzzle 1.0.14

OpenPuzzle 1.0.14

OpenPuzzle 1.0.14 adds conservative adaptive calibration for automatically
managed GPU profiles. Real completed work can now refine future range sizing
without changing the simple openpuzzle run workflow.

Sustained real-world calibration

After a confirmed successful CUDA or OpenCL assignment, OpenPuzzle reads the
speed samples recorded by the engine. It ignores the first two valid warm-up
readings, requires at least five sustained readings and uses their median so a
short spike cannot dominate the result.

The measured median receives a 0.97 planning factor. The new estimate is then
blended at 25% with 75% of the previous profile and limited to a maximum change
of 15% per completed assignment. Minimum, maximum and sample history are kept
with the same exact GPU, backend and engine profile.

Launch settings stay stable

Adaptive calibration updates only the planning speed. The benchmark-selected
blocks, threads and points are preserved and must match the completed launch.
The feature therefore learns from real sustained performance without silently
retuning a stable engine configuration.

Strict completion boundary

Calibration occurs only after assignment completion has been accepted. CPU
work, manually configured GPU launches, failures, cancellations and runtime
states created by older clients are skipped safely. A calibration error cannot
turn a successfully completed assignment into a failure.

Fair scheduling remains unchanged

Every OpenPuzzle client keeps the same right to receive work. Performance data
is used only to size a future range for the target duration; it never changes
queue priority, reputation, assignment access or scheduling preference.

Compatibility

Existing profiles remain valid. OpenPuzzle 1.0.14 begins learning only from
new automatically managed GPU assignments that carry the required profile and
launch identity. No migration or manual profile reset is required.

Validation

The release was compiled from source and all 88 automated tests passed,
including focused calibration, profile update, state persistence, completion
and client-runtime regression tests. Validation was performed while the
installed OpenPuzzle 1.0.13 CUDA runtime continued undisturbed.

OpenPuzzle 1.0.13

OpenPuzzle 1.0.13

OpenPuzzle 1.0.13 introduces comprehensive, actionable diagnostics through
openpuzzle doctor.

Complete local readiness

The doctor command now reports:

• installed version and local configuration;
• private local storage availability and write access;
• bundled CUDA, OpenCL and CPU engines;
• detected processors and GPU devices;
• usable execution backends;
• selected benchmark profile and optional profiles;
• active, preserved and stale runtime state.

The selected GPU backend determines which benchmark profile is required. A
missing profile for an unused backend is reported as optional and does not
produce a false warning.

Safe server reachability

By default, the doctor performs a lightweight HTTPS HEAD request to the
configured coordination server. It does not request an assignment, start an
engine, stop active work or transmit private solution data.

Use the fully local mode when network access is unavailable:

openpuzzle doctor --offline

Clear results and recovery actions

The final summary distinguishes READY, READY WITH WARNINGS and NOT READY.
Stable codes OP-DOCTOR-001 through OP-DOCTOR-006 identify missing backends,
configuration issues, storage failures, stale runtime state, missing selected
profiles and server reachability failures. Each finding includes a concrete
next action.

Validation

The release was compiled from source and all 86 automated tests passed. The
doctor was also validated in online mode, offline mode and with a controlled
network failure while an active runtime continued undisturbed.

OpenPuzzle 1.0.12

OpenPuzzle 1.0.12

OpenPuzzle 1.0.12 introduces safe automatic client updates.

Safe update

Run:

openpuzzle update --safe

When work is active, OpenPuzzle downloads and verifies the release, requests a
safe stop, allows the current range to finish normally, blocks new assignments
and waits for the runtime to shut down completely. It then installs the package,
checks that the expected version is active and starts openpuzzle run again in
the background.

If installation or version validation fails, OpenPuzzle attempts to resume the
client and prints a specific recovery action. The default update mode still
refuses to install while work is active. --check and --download-only retain
their previous behaviour and cannot be combined with --safe.

Safety guarantees

• Active ranges are never terminated merely to perform an update.
• Package download, checksum and Debian metadata validation happen before the
  running client is stopped.
• Installation starts only after both the active engine and runtime have ended.
• The new client version is checked before the update is reported as successful.
• Automatic resumption writes its output to a private update log.

Validation

The release was compiled with the portable CUDA, OpenCL and CPU engines and the
complete automated test suite passed before packaging.

OpenPuzzle 1.0.11

OpenPuzzle 1.0.11

One-command onboarding

The supported first-run flow remains intentionally simple:

openpuzzle run

OpenPuzzle detects and validates the local GPU engine, creates a safe GPU
profile when one does not exist, and only then contacts the coordination
server. No separate setup command is required.

The first-use output now presents four explicit stages:

1. hardware and bundled engine readiness;
2. local GPU profile detection;
3. the safe automatic benchmark;
4. permission to contact the server and request work.

If the benchmark fails, the client confirms that no assignment was requested,
prints a stable error code and gives exact recovery commands. Existing valid
profiles continue without repeating onboarding on every assignment.

This phase does not change the installed client or a running execution.