Skip to content

SOST V16.2.3 — createnodebind binds the key your miner signs with (node/miner unchanged)

Choose a tag to compare

View all tags
@Neob1844 Neob1844 released this 23 Sep 08:35
· 265 commits to main since this release
v16.2.3
7fd495f

Install this one. Only sost-cli changes; sost-node and sost-miner are byte-identical to every other v16.2.x — same published hashes — so a node or miner already on v16.2.x replaces just the CLI and never restarts.

Consensus untouched since v16.1.0: V16 activates at #30,000, first DTD Jackpot V2 #30,186.
Update window: node and miner, after block #29,900 and before #30,000 — step-by-step guide.

Why this release exists

The NODE_BIND procedure could not be followed. sost-cli had no --mining-key-label flag, and createnodebind always bound the wallet key labelled default — so an operator whose mining key carries any other label (the normal case) could not produce a valid bind for the #30,186 jackpot, and would have discovered it only when the draw passed them by.

It now takes the label, prints which mining key it bound, and lists the labels in your wallet when the one you asked for is not there:

sost-cli --wallet ~/sost-keys/your-wallet.json \
  --mining-key-label "your-label" \
  createnodebind 1 --node-key-file ~/.sost/node.key

This was found by running the published procedure rather than reading it — the same audit rewrote the public guides, which had been teaching operators to type their RPC password straight into the command line, where ps shows it to every other local user.

Official SHA-256

b253e4a9c352ea4b8557eec78d57e1c7619ab267af228c3e8f24bf8d7b69b897  sost-node   (unchanged since v16.2.0)
2ef9d0a77f243224ac088460818d6b360c689a7a3fa9555738e2b3b3e0112fe2  sost-miner  (unchanged since v16.2.0)
489f43741437a08b2d617c21020061c042f42d4609bbe6547d28f08ca5e07d07  sost-cli    (new in v16.2.3)

sha256sum -c SHA256SUMS

Linux x86_64, Ubuntu 22.04.5 toolchain (gcc 11.4.0, glibc 2.35). Building it yourself: the build directory must be named build. Measured again from two directories. Cross-machine reproducibility is not claimed.

Verified

  • unit suite 119/119
  • tests/audit_v162_operator_procedures.sh — 35/35: every command in the public guides, run against these binaries, including NODE_BIND on a devnet past activation with a mining label that is not default
  • audit_v162_listunspent.sh 24/24 · audit_v162_secrets.sh 43/43 · audit_v162_rbf.sh 10/10
  • JSON parser under ASan + UBSan + LeakSanitizer: 46/46 and 17/17, no findings
  • devnet E2E 8 harnesses · cross-version equivalence · in-place upgrade and rollback · the real production chain replayed identically

Rollback

v16.2.2, v16.2.1, v16.2.0 and v16.1.0 stay downloadable, each with its own hash list in docs/v16/. One caveat: a wallet encrypted with v16.2.x cannot be read by a pre-v16.2 binary — keep the v1 file until the encrypted one has mined a block.

Assets 6
Loading