Skip to content

SOST V16.2.0 — DTD Eligibility + Jackpot V2 (consensus unchanged from v16.1.0)

Choose a tag to compare

View all tags
@Neob1844 Neob1844 released this 22 Sep 21:47
· 423 commits to main since this release
v16.2.0
8f6b9dd

Consensus is unchanged from v16.1.0. V16 still activates at #30,000 and the first DTD Jackpot V2 is still #30,186. This release is about keeping operator credentials out of places other local users can read.

Update window — after #29,900, before #30,000

Install these binaries on your node AND your miner, and restart both, inside that window. Download and verify the hashes before the window opens, so inside it you only stop, install, restart.

A validating node still on older consensus software after #30,000 may diverge from the V16 chain.

Official SHA-256

b253e4a9c352ea4b8557eec78d57e1c7619ab267af228c3e8f24bf8d7b69b897  sost-node
2ef9d0a77f243224ac088460818d6b360c689a7a3fa9555738e2b3b3e0112fe2  sost-miner
212e37d8f925afd4d4e1f9971a86bd49120be2978e09ec1cf77b713ebc0812c5  sost-cli

sha256sum -c SHA256SUMS

Built on Ubuntu 22.04.5, gcc 11.4.0, glibc 2.35, x86_64. If you build it yourself, the build directory must be named build (cmake -S . -B build …): the source path is normalised out of the binary, the build directory name is not. A different toolchain may legitimately produce a different hash — cross-machine reproducibility is not claimed.

What changed

Every secret can now stay out of argv:

  • miner — --rpc-pass-fd, --rpc-pass-file, --wallet-passphrase-file. --rpc-pass still works and warns that ps can see it. A 401 on submit now says the credentials are wrong instead of looking like a rejected block.
  • node — --rpc-pass-file, --node-key-file, so systemd names a path instead of expanding a password into ExecStart.
  • cli — createnodebind / nodeheartbeat take --node-key-file or --node-key-fd; wallet-export / wallet-import prompt with echo off and accept --passphrase-fd.
  • A secret file must be mode 600, owned by you, one line and nothing else. Group- or world-readable is refused, not read with a warning, and no error ever echoes what it rejected.
  • Encrypted (v2) wallets work end to end and do not change your mining identity or payout address. v1 wallets keep working, with no conversion and no deadline.
  • Also in this release: hardened strict JSON parsing, listunspent reading the chain instead of a stale cache, and sost-cli sweep-plan (a planner only — it signs and broadcasts nothing).

Evidence that consensus did not move

  • a v16.1.0 node and a v16.2.0 node on one devnet accept each other's blocks; 61/61 heights hash identically, lottery audit identical at every height
  • both releases load a copy of the real production chain to height 27,544: no rejections, 959 sampled heights identical, tip block identical, 959 lottery audits identical
  • in-place upgrade and rollback both verified on the same chain file — no reindex, no migration
  • unit suite 119/119; devnet E2E 8 harnesses; credential audit 43/43 against these exact binaries

Rollback

Keep your current binaries. Nothing here changes the on-disk chain format, so rolling back is the old binary and nothing else. One caveat: a wallet you encrypted with v16.2.0 cannot be read by an older binary — keep the v1 file until the encrypted one has mined a block.

Guides

docs/v16/UPGRADE_V16_2.md · V15 → V16: docs/v16/QUICK_UPGRADE_5MIN.md · manifest: docs/v16/RELEASE_MANIFEST_V16_2.md · hashes: docs/v16/SHA256SUMS (v16.1.0's list is kept as SHA256SUMS_V16_1, for verifying a rollback binary).

Assets 6
Loading