Korsh Core v0.0.6.1

Korsh Core v0.0.6.1

This hotfix addresses a Windows wallet shutdown crash after Berkeley DB reports that wallet.dat needs recovery.

In one sentence: v0.0.6.1 preserves Berkeley DB recovery files on fatal wallet errors and contains scheduler exceptions for orderly shutdown; the Windows x64 asset is refreshed in the existing v0.0.6.1 release without a version bump.

Observed failure

The affected wallet's Berkeley DB diagnostics report that wallet.dat references a log sequence number beyond the available transaction-log end, followed by failed page flushes and DB_RUNRECOVERY. During shutdown, the application then surfaced BDB error -30972 while opening wallet.dat. This confirms a wallet/environment log mismatch as the immediate failure; the event that first left the log sequence incomplete is not established. This hotfix preserves the files and prevents the shutdown exception; it does not reconstruct missing recovery logs.

What changed

• Scheduled-task failures are contained across node notifications, ChainLock handling, and ChainLock signing; fatal shutdown closes the validation callback queue, cancels pending synchronous barriers, and joins scheduler workers before dependent teardown. Normal shutdown drain exceptions are routed through the same handler.
• Removed the fallback that moved Berkeley DB environment logs aside and retried with a fresh environment based on text found in the append-only db.log. Wallet verification also no longer treats a historical unsupported DB version message as proof that the current wallet file uses a newer format.
• Berkeley DB open, transaction-abort, record, cursor, checkpoint, LSN-reset, and close failures that require recovery are latched as recovery-required; transaction-abort cleanup also fails closed on any nonzero result. Already-open batches stop normal operations after recovery is detected, and rewrite treats all nonzero Berkeley DB return codes as failures. Shutdown preserves the existing wallet and transaction-log files rather than treating the environment as clean.
• Windows rewrite temporaries now budget against every Berkeley DB data directory, including root-relative and nested DB_CONFIG set_data_dir paths, while keeping candidate collision checks and DB_EXCL protection intact. Both the wallet-suffixed name and short sibling fallback leave path headroom for Berkeley DB's transactional rename/commit. If no safe collision-resistant name fits, rewrite fails before closing, checkpointing, or replacing the original database file; an encryption operation reports failure rather than claiming a successful rewrite.
• A transient Berkeley environment teardown during automatic wallet backup is reported without setting the process-wide backup count to a permanent failure value; the failed backup is not retried in that call, but later backup attempts and CoinJoin remain enabled.
• Automatic Windows Berkeley DB file conversion now serializes the full close/reset/convert/reopen sequence against other database opens and refuses conversion while a database batch is active, preventing replacement of an environment handle while another wallet operation can use it.
• The wallet-directory lock now remains held across conversion, environment reload, and shutdown log cleanup. If conversion or shutdown enters recovery-required state, the lock is retained rather than exposing the wallet directory to a second process during uncertain cleanup.
• Recovery-required state is now sticky for a wallet directory for the lifetime of the process. Unloading and retrying a failed wallet in that same process cannot reopen its recovery files; a fresh process is required before another recovery attempt.
• Berkeley environment, recovery-latch, and directory-lock identities now use weakly canonical paths, so a symlinked wallet-directory alias reuses the same environment and cannot bypass the same-process recovery latch.
• Best-block locator persistence failures are logged and latch the wallet's flush fail-stop. Chain-state flush/close paths surface failures without throwing through the chain callback or continuing later flushes. A rescan's status still describes the block scan itself; if saving its locator fails, the previous locator may cause a later rescan.
• Wallet loading, transaction-hash enumeration, and wallet dumps now fail if an explicit database-cursor close fails. Wallet-load cursor failures return a generic load failure unless a more specific corruption or version error was already detected.

Windows x64 asset refreshed (October 11, 2026)

The replacement Windows x64 ZIP, korsh-0.0.6.1-win64.zip, is run07, SHA-256 8086470c814035413d99d6e3b0fb46990bd54fc6e683778da35fa8022cb885dd (207,121,050 bytes). The earlier run05 ZIP (47244eaf768ee0cf8955fb6fae68a369644cb4de532f00a970618a9e4958be74) was withdrawn after review; run06 (188780e86ce0749d96392d8e2907c2e4be4f4b316b631543f3f4269be7d808ba) was never uploaded and was superseded after review found its close-failure fallback could publish fatal state without closing the queue. The v0.0.6.1 tag and version remain unchanged; the run07 replacement passed independent review and is available in this release.

• ChainlockHandler::Stop() now requests scheduler stop and joins its separate worker before validation callbacks or dependencies are torn down.
• Fatal-state publication uses the callback-queue close hook under the queue lock. Pending callbacks are detached/cancelled before lock release; a callback already dequeued may still start or finish. A cancelled SyncWithValidationInterfaceQueue() barrier can return before those in-flight callbacks finish, so that return is not proof of a complete drain. If queue locking fails, the process terminates instead of publishing NodeAborted while the queue may remain open.

The v0.0.6.1 tag and Linux/macOS assets are unchanged; only the Windows ZIP is replaced. Windows product build and full make check passed on the physical Mini PC. The targeted scheduler, validation-interface, and chain-state-manager suites passed 17/17 cases (219 assertions). The exact package smoke used Berkeley DB 6.2.32 and disposable data: zero peers, height 101→102, persisted transaction count 103→103 and address, two clean shutdowns, real_wallet_touched=false. The Qt wizard harness reported 53 PASS, 1 SKIP, 0 FAIL using mocked RPC; it is not visible-desktop acceptance. No production wallet was used.

Important wallet-safety note

This is a shutdown-safety fix, not a repair utility. If a wallet already reports that Berkeley DB requires recovery, keep the original wallet and logs together, make a verified copy, and perform any recovery attempt only on that copy. Do not delete the database directory or its log files.

Compatibility and package

• No consensus, genesis, activation-height, or network-port changes; the legacy wallet data format is unchanged.
• No peer-discovery or connection code changed. Prior connection-refusal diagnostics are outside this wallet hotfix and remain unresolved.
• Each platform retains the Berkeley DB backend used by v0.0.6: Windows 6.2.32, Linux 5.3, and macOS 4.8.30. This does not establish cross-platform wallet portability.
• macOS bundle metadata uses Apple-compatible version fields: the short version is 0.0.6 and the build version is 6.1, while Korsh's full application/package version remains 0.0.6.1. Windows installer/resource metadata uses all four numeric components (0.0.6.1).
• The Windows ZIP places six executables under bin/, setup guides under docs/, and Sapling parameter files under params/. Windows Qt and Berkeley DB 6.2.32 are statically linked; keep the complete archive together and do not extract only an executable.

Validation scope

All node and wallet smoke tests use disposable data; no production wallet was opened or modified. No consensus, genesis, activation, or network-parameter files changed.

• Windows x64: MSYS2 MINGW64 / GCC 16.1.0, static Qt 5.15.19, static Berkeley DB 6.2.32. The complete static build and make check passed (exit 0); wallet/DB/util suites and the configured-data-directory rewrite regression passed.
• Linux x86_64: WSL2 Ubuntu 22.04, Berkeley DB 5.3. Build, wallet/DB/util suites, and make check passed. The tested package smoke verified two clean shutdowns, zero peers, and wallet transaction/address persistence across restart.
• macOS arm64: Berkeley DB 4.8.30. The v0.0.6.1 build and make check passed.
• Masternode wizard: Windows Qt scripted-flow harness reported 53 PASS, 1 SKIP, 0 FAIL using mocked RPC. This exercises the wizard flow but is not visual desktop acceptance and does not submit a mainnet registration.
• Exact release archive SHA-256 values and extracted-package smoke results are listed in the accompanying VALIDATION.md.

Korsh Core v0.0.6

Korsh Core v0.0.6

Release date: 2026-10-05
Commit: 28c1635
Consensus: unchanged from v0.0.5 — no chain reset, no reindex, no mainnet parameter changes.

What's new in v0.0.6

This release bundles the v0.0.6 masternode service-port feature with the wallet,
network, and test-suite fixes that landed between the v0.0.5 tag and HEAD. It is
a wallet/UI, configuration-parsing, and documentation release.

Masternode wizard (Qt wallet)

• Update service to the current network port — right-click an existing
  masternode whose ProTx advertises an outdated endpoint and submit
  protx update_service for that ProTx. Existing collateral is reused; payout
  address is unchanged. A second registration for the same collateral is refused.
• Register a new masternode — generates a BLS key, creates fresh collateral
  (1,500 KSH regular, 7,500 KSH Evo), validates the raw transaction in the
  mempool, then publishes a private recovery journal before broadcast.
• Private recovery journal — written to <conf>.mnsetup-<network>.json via
  a single atomic hard-link publish (no overwrite window). On Windows the file
  is created with a private NTFS DACL owned by the operator; on POSIX it is
  staged in a private temporary directory and hard-linked into place. A previous
  unresolved journal is detected on reopen and blocks silent re-registration.
• Fail-closed operator-key handling — the wizard never rotates an existing
  masternodeblsprivkey. If one is already configured and differs from the
  registration secret, registration is refused.
• UTF-8 BOM parsing — configuration files with a UTF-8 BOM (including files
  whose first line is a comment) now parse correctly.

Wallet

• Shared Berkeley DB environment is kept alive through final wallet writes,
  fixing a deterministic shutdown crash in multi-wallet setups. macOS 4.8.30,
  Linux 5.3, Windows 6.2 backends retained.

Network

• Node now advertises NODE_HEADERS_COMPRESSED, so compressed headers
  (getheaders2) are negotiated with peers instead of legacy getheaders.
• Address-fetch respects the peer's advertised roles and the DNS-seeding policy.

Updating an existing masternode

On the masternode host, listen on port 9777 and allow it through the firewall.
In the wallet's Masternodes tab, right-click the affected entry and choose
Update service to the current network port. Review the old and new endpoints,
confirm the transaction.

Requirements: the operator BLS key on the node submitting it, a loaded and
unlocked wallet, and a confirmed spendable output to pay the fee.

Wallet balance and collateral

The service update changes only the registered endpoint. It does not unlock or
move collateral, deregister the masternode, or restore a missing balance. If
collateral is absent from the displayed balance, verify its outpoint is still
unspent and controlled by the loaded, synchronized wallet.

Consensus and economics

No consensus, subsidy, or collateral rules changed in v0.0.6.

Regression coverage

• test/functional/feature_assumevalid.py — burial bumped 8400 → 21000 blocks
  and header batching looped in ≤2000-entry chunks to satisfy the assume-valid
  2-week gate under Korsh's 60s regtest spacing.
• test/functional/feature_shield_activation.py — Sapling export-key prefix
  corrected to rkshsecret / rkshview.
• src/init.cpp — NODE_HEADERS_COMPRESSED service flag.
• src/wallet/bdb.cpp / bdb.h — shared BDB environment lifecycle.
• src/qt/test/masternodewizard_config_test.py and
  src/qt/test/masternodewizard_flow_test.py — wizard persistence and
  fail-closed admission (28 assertions, all pass).

Assets

File	Platform
korsh-0.0.6-src.tar.gz	Source (all platforms)
korsh-0.0.6-macos-arm64.tar.gz	macOS arm64 (daemon + CLI + GUI)
korsh-0.0.6-linux-x86_64.tar.gz	Linux x86_64 (CI)
korsh-0.0.6-win64.zip	Windows x86_64 (CI)
SHA256SUMS-006.txt	Checksums

Verify

sha256sum -c SHA256SUMS-006.txt

Korsh Core v0.0.5 — consensus fix + new GUI

Korsh Core v0.0.5

Consensus fix — update before block 14000.

What's new

Consensus split fixed (issue #1)

A masternode registration still using the old pre-rebrand port (:8383) could split the network:
nodes running the original v0.0.2 binaries rejected it while v0.0.3/v0.0.4 accepted it, producing
orphaned blocks. v0.0.5 gates the legacy port (and the legacy message-magic signatures) to the
historical chain (blocks <= 3515), so every node agrees on the rules for new blocks.

• New ProRegTx/ProUpServTx with :8383 are rejected (bad-protx-netinfo-port)
• Legacy message-magic signatures are rejected (bad-protx-sig)
• Historical sync (blocks <= 3515) still accepts both, so fresh nodes sync the whole chain
• If your masternode registration used :8383, re-register with :9777

Fresh GUI

The desktop wallet includes the full v0.0.5 redesign.

Sporks permanently disabled on mainnet

All mainnet sporks stay hardened to 2099 (same behavior as v0.0.4) — there is no activation height, no signer-key override and no spork governance on Korsh mainnet. The v0.0.5 retarget/spork upgrade is set to height 999999999 and never activates; the only scheduled activation remains V19 (the masternode wizard fix) at block 14000. PoW, rewards, masternode collateral, UTXO validation and chain selection are not gated by spork keys.

Everything from v0.0.4

• Masternode database self-healing on every startup (reorg / restart-loop fix)
• No reindex needed

Upgrading

Block 14000 (~Oct 1, 2026) activates the V19 network upgrade (wizard) — update before that block.

IMPORTANT: do NOT start your node with -reindex-chainstate. 0.0.5 self-repairs on a normal start.

Assets

• korsh-0.0.5-macos-arm64.tar.gz — macOS (Apple Silicon)
• korsh-0.0.5-win64.zip — Windows x64
• korsh-0.0.5-linux-x86_64.tar.gz — Linux x86_64
• SHA256SUMS.txt — verify your download

Korsh Core v0.0.2 - network identity (KSH)

Korsh Core v0.0.2 - KSH

Network-identity release. Korsh becomes fully Korsh-only: the P2P network
magic, the default ports and every user-visible string are now Korsh's own.
Nodes running v0.0.1 use the old Smartiecoin-era network identity, so they can
no longer see or connect to v0.0.2 nodes.

Build update - fresh-sync fix (Sep 25, 2026)

The binaries in this release were rebuilt on Sep 25, 2026 to fix a
fresh-sync bug in the first v0.0.2 builds. The version string is unchanged
(still v0.0.2) - if you downloaded earlier, re-download.

The bug. Every fresh node or wallet (empty datadir, sync from scratch)
stalled at block 3515 with bad-protx-netinfo-port / bad-protx-sig
validation errors, then dropped the peer. Already-synced nodes were
unaffected - that is why the seed and the pools kept running while every
new install could not sync at all.

The cause. The network-identity rebrand touched two checks that
re-validate historical data:

• The chain's masternode (registered at block 3515) advertises the old
  P2P port (8383); the new validation required the new default port
  (9777), so its registration transaction was rejected on re-validation.
• Historical ProTx payload signatures were signed with the old
  "DarkCoin Signed Message" prefix; verification with the new Korsh prefix
  failed.

Since every node re-validates the whole chain from genesis, both checks
retroactively rejected already-mined history on any fresh sync.

The fix. Verification now also accepts the legacy values for data
already on the chain, while signing, advertising and all new transactions
use the new Korsh values only. No consensus rule, genesis, tokenomics or
address change: this build accepts exactly the same chain the earlier
v0.0.2 build mined.

Verified live. A fresh node synced genesis ? tip in seconds, and the
seed host's companion node - stuck at block 3514 for a day - caught up to
the live tip immediately after the binary swap.

Why update

	v0.0.1 (old)	v0.0.2 (this release)
P2P magic (mainnet)	Smartiecoin legacy	cb4b5348 ("KSH")
P2P port (mainnet)	8383	9777
RPC port (mainnet)	8282	9776
Signed-message magic	"DarkCoin Signed Message:\n"	"Korsh Signed Message:\n"
Bootstrap seed	195.26.244.209:8383	195.26.244.209:9777
Version string	v0.0.1	v0.0.2

What did NOT change (on purpose)

• The genesis block and the whole chain - no reset, no reindex, no fork.
  Genesis is still 000017ec1f2f978429db70495ec7653aedca360e5f251bfe2a780ae5e731d7eb,
  Block 0 is still In honor of my uncle Satoshi Nakamoto, and every block,
  balance and transaction mined so far is untouched.
• Consensus and tokenomics - YesPower 1.0 (N=256, r=8), 2 KSH block
  subsidy, 60 s blocks, 10,000,000 KSH cap, halving every 2,500,000 blocks,
  masternode collateral and payments, retarget every 20 blocks.
• Addresses and wallets - base58 prefixes are untouched and every platform
  keeps the exact Berkeley DB version v0.0.1 already used:
  macOS = BDB 4.8.30 (static), Linux = BDB 5.3 (system library, dynamic),
  Windows = BDB 6.2 (static). Existing wallet.dat files open with the new
  binaries - no conversion, no migration.
• Mining - the stratum endpoint (:3333) and the pool configuration are
  unchanged; pool miners do not need to do anything.

Upgrading

Node operators: stop the node, replace the binaries, and update the ports
if they are pinned in korsh.conf (port=9777, rpcport=9776,
externalip=<ip>:9777). You can simply delete those three lines to use the
new defaults. Do not pass -reindex - the chain data is compatible as-is.

Solo miners and tools: the RPC endpoint is now http://127.0.0.1:9776/ by
default. The bundled korsh-miner already defaults to it; if you run your own
tools, point them at the new port.

Pool miners: nothing changes - keep mining on the same stratum endpoint.

Downloads

Platform	File
Linux x86_64	korsh-0.0.2-linux-x86_64.tar.gz (daemon, CLI, tools + Qt wallet)
macOS (Apple Silicon)	korsh-0.0.2-macos-arm64.tar.gz (daemon, CLI, tools + Qt wallet)
Windows x64	korsh-0.0.2-win64.zip (daemon, CLI, tools + Qt wallet)
Checksums	SHA256SUMS

Verification (this release)

• Shipped binaries report Korsh Core version v0.0.2 with Korsh-only credits.

• Binary string audit: zero "Smartiecoin" identifiers remain in the shipped
  binaries (headers, strings, ports and magic were scrubbed from the source).

• Mainnet genesis hash re-checked after the changes: unchanged
  (000017ec.1d7eb); no checkpoint, base58 prefix or spork was modified.

• Regtest smoke test on the built binaries before packaging; the Linux set is
  additionally smoke-tested on the Korsh seed node host.

• Fresh-sync acceptance test after the fix: a scratch node synced from genesis to the live tip with zero validation errors.