Blackcoin Core v30.1.1 alpha 1

Blackcoin Core v30.1.1 alpha 1

This is a publisher-unsigned, unnotarized canary prerelease for controlled testing. It is not the production v30.1.1 release and has not completed the beta or production release gates. The macOS app bundles carry deterministic ad-hoc launch-integrity signatures only; those signatures identify no developer or publisher. The manifest's release.signed=false field means that the release has no publisher or identity signature; the bundle's UNSIGNED-CANARY marker separately records macos_adhoc_signed=true for the identity-free macOS launch signatures.

The prerelease tag is exactly v30.1.1-alpha1. Some tracked source prose uses alpha.1 as a descriptive channel label; it does not name a second tag or build.

• Source commit: a6dba4b5a8e6716dd7e6e859a840de2a584d8d87
• Source review: draft pull request #28
• Exact-SHA canary build: workflow run 29350122673. The workflow revision is 218e83c05260267c0ec619312c84b19c2cd550ca; every source checkout and packaged binary remains bound to the release commit above.
• Independent exact-SHA full safety matrix: workflow run 29328697818 (completed with failures; the exhaustive, sanitizer, and fuzz failures are classified below)

Included alpha fixes

• Replaces history-wide staking candidate scans with a bounded live-unspent index to address GUI and daemon stalls after PoS attempts.
• Fixes light/dark readability on the Account, Overview, and Staking pages, with automated palette, contrast, and theme-transition coverage.
• Keeps ordinary legacy PoS unrestricted for pure non-whitelisted and mixed wallets while retaining whitelist checks only for Gold Rush shadow PoS rewards, with focused functional coverage.
• Removes identified wallet startup, staking, signal-cleanup, and PSBT lock-order inversions.
• Preserves v30.1.0 transaction-time provenance during live connection, restart, and replay.
• Preserves already-mined v30.1.0 Gold Rush claim allocations. The prospective emission-neutral competing-claim rule begins at height 5,993,200.
• Adds deterministic, journaled chainstate reconstruction that preserves source databases until a separate process reopens and verifies the replacement.
• Corrects explorer RPC schemas, shadow/coinstats index schema handling, and shadow RPC CLI conversions.
• Validates the candidate against the designated legacy chain with exact historical-client block production, acceptance, restart, and reorg fixtures.

No software release can guarantee that every future fork is impossible. This alpha is limited to the concrete compatibility and failure-isolation evidence recorded in the linked runs.

The packages are labeled alpha 1. The enclosed binaries self-identify as v30.1.1rc1-a6dba4b5a8e6 so a running process can be tied to this exact source candidate.

Height 5,993,200 upgrade boundary

At height 5,993,200, v30.1.1 begins the prospective emission-neutral competing-claim reimbursement rule. v30.1.0 and v30.1.1 can still accept the same Gold Rush base chain, but they will intentionally derive different shadow recipients and balances from that boundary. Base-chain compatibility does not mean identical shadow state. Wallets, staking/mining nodes, explorers, and indexers must upgrade before that height if they need the authoritative post-boundary shadow ledger. Do not reopen or resume using a wallet/datadir that has processed post-boundary state with v30.1.1 in v30.1.0; preserve the cold pre-upgrade copy for rollback instead.

Alpha 1 is a pre-boundary canary only. Do not run it at or beyond height 5,993,200: maximum-size custom-block claim/accounting resource bounds are not proven in this source, and the bounded streaming/index correction is on the beta track. Replace this alpha with a later fixed candidate before the boundary.

Mandatory canary procedure

1. Cleanly stop v30.1.0, then back up every wallet and make a cold copy of the complete datadir before testing. Quantum keys are non-HD; an older wallet.dat does not contain quantum keys generated after that backup. Make a fresh wallet backup after every newly generated quantum key or address.
2. Test one isolated node first. Do not roll this alpha across the fleet until that canary completes both starts and its tip, wallets, GUI, RPC, peers, staking state, and rollback path are verified.
3. Use an official v30.1.0 datadir or a clean wallet created by this alpha. Preserve any wallet opened by an unpublished intermediate development build.
4. Use archival mode: prune=0. Keep staking and mining disabled during reconstruction. If the datadir still contains complete block history, run the documented protected -reindex-chainstate upgrade. If it is pruned or any required block history is missing, set prune=0 and run a full -reindex, allowing the node to redownload history. After either successful path, stop cleanly and start again without a reindex option so a separate process verifies the replacement.
5. Verify the downloaded unsigned SHA-256 manifest before launching a binary. Checksums detect corruption; they are not a publisher signature.
6. Keep stable power during Windows reconstruction. Do not force-stop the Windows process during rebuild or verification.
7. After the reconstruction and clean second start pass, runtime testing may enable PoS. If PoW is also tested, limit it to one thread and 1% CPU and use a separate PoW wallet with its own confirmed, small legacy fee UTXO. setpowmining is wallet-scoped: on a multiwallet node, enable exactly one designated PoW wallet and explicitly keep PoW disabled on every other loaded wallet. Pre-create the designated wallet's payout with getnewquantumaddress "PoW - Quantum Claim Address", complete and verify a fresh wallet backup, and only then enable PoW. Gold Rush quantum rewards are phase-locked and cannot fund claim fees. Alpha 1 can select an ordinary staking UTXO for a claim; that input stops contributing stake weight while pending, and confirmed change must mature before staking again. Do not enable built-in PoW in a high-value or whitelisted PoS wallet for this canary.

Known alpha limitations

• Linux and Windows packages have no publisher signature. The macOS bundles have deterministic ad-hoc launch-integrity signatures, no Developer ID or signing authority, and no notarization. Gatekeeper may still require the normal user-approved opening procedure for an unnotarized canary.
• The tagged alpha source contains a Windows make deploy install packaging-path defect: NSIS writes a relative output beside its recipe, and parallel top-level goals can race. The linked build uses the separately reviewed workflow revision above to run the goals sequentially and supply an absolute installer path while compiling the unchanged tagged source. This affects source packaging, not the runtime binaries; the permanent Makefile correction is on the beta track.
• The Windows portable ZIP retains compiler debug sections, while the NSIS installer contains the corresponding stripped deployment executables. Their whole-file sizes and hashes therefore differ. Before promotion, the project verifies the exact six-executable inventory, x86-64 PE identity, expected source-bound version, and byte identity of every runtime PE section between the portable and installer payloads. The production release path instead rebuilds its installer from the signed portable payload and requires literal whole-file identity.
• Do not use alpha 1 as a historical mainnet explorer indexer with -shadowindex=1. A pre-height-5,993,200 provenance defect can stop that optional index during historical replay. Base-chain consensus is unaffected; the correction is on the beta track.
• A late local allocation failure during shadow-state application is fail-stop in alpha 1, but complete atomic restart/retry isolation is not proven in this source. The transactional staging correction and retry/replay proof are on the beta track.
• The second-start chainstate check uses the normal startup verification window; it is not a full UTXO-set integrity scan before the staged source database is retired. Keep the cold pre-upgrade datadir copy. Record height, best-block hash, and non-indexed gettxoutsetinfo muhash snapshots before and after reconstruction as operator evidence, but do not treat a matching MuHash as a whole-state proof: the standard commitment omits persisted nTime and coinstake metadata. A versioned complete-Coin commit/reopen identity check is on the beta track.
• Before height 5,993,200, standard policy admits and templates at most one competing claim, but a custom block can still confirm a later valid claim without credit.
• getpowmininginfo can report enabled=true and zero hashrate without identifying that the wallet has no eligible legacy claim-fee UTXO. The explanatory readiness state and smallest-sufficient fee-input policy are on the beta track.
• A wallet opened by an unpublished intermediate build that retroactively enabled competing-claim reimbursement can retain stale synthetic payout records. Preserve it, do not stake or spend based on that displayed synthetic balance, and do not substitute an older backup unless every current legacy and quantum key has been independently verified. Direct upgrades from the official v30.1.0 release are not subject to this warning.
• Do not use migratewallet on an unnamed/default legacy wallet in alpha 1. The independent exhaustive job found that the migration can create its top-level SQLite replacement without listwalletdir rediscovering it. Preserve the entire wallet directory; the discovery correction is on the beta track.
• Windows sudden-power-loss directory-rename durability is not claimed.
• Production Blackcoin PoS pruning is not implemented or validated; use prune=0.
• The manual alpha gate exercises the staged recovery/replay path and wallet key unit coverage, but it does not run the complete feature_dbcrash.py or wallet_quantum_key_safety.py functional fixtures. The linked independent PR full matrix runs those fixtures separately. Unless that exact-SHA run is green, their end-to-end crash and restore paths remain unproven for this canary.
• The exact-SHA PR exhaustive job reported nine failures. Seven are legacy relay/accounting fixture assumptions already corrected on the beta track, and feature_dbcrash.py used witness-stripped RPC block bytes and an incomplete side-chain assertion; a corrected deterministic 40-cycle beta fixture completed with matching final UTXO hashes. The ninth failure is the default-wallet migratewallet discovery defect described above. These classifications do not turn the failed alpha job green; they define the canary limitations.
• The exact-SHA thread-sanitizer job did not report a data race; it stopped in script_assets_test because the pinned Bitcoin corpus contains 1,161 version-1 transactions whose serialization omits Blackcoin's required nTime field. The normal unit job did not set the corpus path and therefore skipped that corpus test. Of the 2,244 pinned vectors, 1,083 use the shared compatible layout and still require an explicit Blackcoin-aware sanitizer run on the beta track. The failed sanitizer job is not represented as a passing sanitizer gate.
• The exact-SHA address/undefined-sanitizer job likewise reported no sanitizer diagnostic before stopping in the same incompatible script_assets_test corpus. It did not reach its later functional-test stage and is not represented as a passing sanitizer gate.
• The exact-SHA fuzz-smoke job stopped in the block test harness at test/fuzz/block.cpp:48 because its BasicTestingSetup pointer was never initialized. This occurred before that input exercised the product block path, so it is not evidence of a node crash; it also means the pinned block corpus is not a passing fuzz gate for this alpha. The harness initialization and crashing-input regression are on the beta track.
• The remaining P0/P1 roadmap evidence, complete sanitizer/fuzz/exhaustive matrix, launch-chain replay, signed manifests, SBOM, platform signing, notarization, and operator canary remain beta/production work.
• No Unraid/noVNC container image is included in this release.

Every uploaded canary asset name contains the complete source commit. The bundle also includes per-platform source markers, byte-identical evidence from two isolated workflow builds, an unsigned JSON manifest, SHA256SUMS-UNSIGNED.txt, and an UNSIGNED-CANARY warning. GitHub's automatically generated source ZIP and tar archive are outside that manifest and checksum set; use the exact commit and uploaded canary assets for verification.

The embedded manifest's release.published=false and release.tag=null fields truthfully record the manual workflow's build-time state. This GitHub prerelease is a later promotion of those unchanged exact-SHA files; the files are not rewritten after tagging.