SOST V30000 — MINER & NODE GUIDE

HOW TO DO IT — 4 SIMPLE STEPS (do steps 3 and 4 between #29,900 and #30,000)

# 1. GET THE NEW BINARIES  (A: recompile  -or-  B: download)
#    A) recompile (Ubuntu/Debian/WSL2):
sudo apt install -y build-essential cmake git libssl-dev libsecp256k1-dev
git clone https://github.com/Neob1844/sost-core.git sost-final && cd sost-final
git checkout v30000-final
cmake -S . -B build -DSOST_ENABLE_PHASE2_SBPOW=ON -DSOST_TESTNET_FORKS=OFF -DCMAKE_BUILD_TYPE=Release
cmake --build build --target sost-node sost-miner sost-cli -j"$(nproc)"
cd build
#    B) or download the official binaries:
#    for f in sost-node sost-miner sost-cli SHA256SUMS; do wget -q https://github.com/Neob1844/sost-core/releases/download/v30000-final/$f; done; chmod +x sost-*

# 2. VERIFY  (must match exactly)
sha256sum sost-node sost-miner sost-cli
#   ef608cf9e7f6434f8d60b29c3287ca7045cb83de1be1ddf585a9176bf45b39cd  sost-node
#   53c83836bc16e32cd0b9bdda5d15e8936a217079dacde00ca7eba8302b8a1e75  sost-miner
#   09d9a5022b3c03dfbe85df1ea728f931f5287712739921e17138e89dad14f62b  sost-cli

# 3. RESTART THE NODE on the new sost-node   (between #29,900 and #30,000)
#    systemd:  sudo systemctl stop sost-node
#              sudo install -m 0755 sost-node /path/to/your/sost-node
#              sudo systemctl start sost-node
#    by hand:  stop the old node (Ctrl+C) and start the NEW ./sost-node with your usual flags

# 4. RESTART THE MINER on the new sost-miner   (between #29,900 and #30,000)
#    stop the old miner (Ctrl+C), then start the NEW one with your usual flags, e.g.:
./sost-miner --wallet ~/sost-keys/my-wallet.json --mining-key-label "my-mining-key" \
  --genesis genesis_block.json --rpc 127.0.0.1:18232 --rpc-user <user> --rpc-pass-file ~/.sost/rpc.pass \
  --blocks 999999 --max-nonce 500000 --profile mainnet --realtime --threads <N>
#    (--realtime is mandatory. Your chain data is kept: no resync.)

Verify before you run anything

sha256sum -c SHA256SUMS

Or check them one by one against the published values:

What these binaries are

Linux x86-64 ELF executables. They are not signed installers and there is no Windows or macOS build in this release. On Windows, run them under WSL2. Building from source (MIT licence) is always an option and is how you can check the binaries yourself.

Practical requirements: the miner allocates a 4 GB dataset per block, so plan for ~6 GB of free RAM for the miner alone. A full node keeps the chain in memory; today that is under 1 GB, and it grows.

A miner does not talk to "the network". It talks to one node, over RPC, and that node is what accepts your block and relays it. So the real question is whose node.

A — Node and miner on the same machine

The simplest setup, and the one we recommend if you are starting. The miner connects to 127.0.0.1:18232, which never leaves your machine. You control the password because you set it.

B — Your node on a VPS, your miner at home

Also fine, and it is what we run. The miner still connects to 127.0.0.1:18232 — the difference is that an SSH tunnel maps that local port to the node on the server. The RPC port stays closed to the internet.

C — Someone else's node

Only if that operator has explicitly authorised you to mine against it and has given you credentials. Mining through a node means asking it for work and asking it to accept your blocks; that is not something you do to a stranger's server.

P2P and RPC are not the same port

Create one and put it in a file

umask 077
mkdir -p ~/.sost
openssl rand -hex 32 > ~/.sost/rpc.pass
chmod 600 ~/.sost/rpc.pass

That is 256 bits of randomness. It must be a single line, owned by the account that runs the node, mode 600. The binaries refuse to read a secret from a file that is group- or world-readable, and refuse a file with more than one line — that is deliberate, not a bug.

Never pass it on the command line

Keep it on loopback

The node binds RPC to 127.0.0.1 by default. Leave it there. --rpc-public exists for people who know exactly why they need it; if you are reading this guide, you do not. To reach a remote node, use SSH (next section) — it gives you an encrypted tunnel and it does not open a port to the world.

Every option below was checked against --help on the published V30000 binaries. Paths, labels and users are placeholders — replace them with yours.

Start a node

./sost-node \
  --genesis genesis_block.json \
  --chain chain.json \
  --rpc-user myuser \
  --rpc-pass-file ~/.sost/rpc.pass \
  --profile mainnet \
  --p2p-enc on

Start a miner

./sost-miner \
  --wallet ~/sost-keys/my-wallet.json \
  --mining-key-label "my-mining-key" \
  --genesis genesis_block.json \
  --rpc 127.0.0.1:18232 \
  --rpc-user myuser \
  --rpc-pass-file ~/.sost/rpc.pass \
  --blocks 999999 --max-nonce 500000 \
  --profile mainnet --realtime --threads 8

--mining-key-label must match a label that actually exists in your wallet, exactly, spaces included. Check what you have:

./sost-cli --wallet ~/sost-keys/my-wallet.json info

Miner at home, node on a VPS

ssh -N -L 18232:127.0.0.1:18232 \
  -o ServerAliveInterval=15 -o ExitOnForwardFailure=yes \
  -i ~/.ssh/your_key user@your-server

Leave that running, and point the miner at 127.0.0.1:18232 exactly as above. The RPC port on the server stays closed; the traffic travels inside SSH.

Is it actually mining?

Startup takes a minute or two — it loads the chain and builds a 4 GB dataset. You are mining when you see [DATASET] regenerated followed by [MINING] Starting N threads and a line with att/s. Compare the height and difficulty it prints against the Explorer: they should agree.

Found is not the same as accepted

People mix these up constantly. They protect different things and none of them replaces another.

P2P: what on really does

--p2p-enc takes off (the default), on or required. With on, your node offers an X25519 + ChaCha20-Poly1305 handshake and falls back to plaintext if the other node does not support it. That fallback is what keeps the network connected while operators upgrade — and it also means "on" does not guarantee an encrypted link. If you need the guarantee, required refuses plaintext peers, at the cost of connecting to fewer of them.

Wallet v2 is optional, and v1 still works

A v1 wallet holds your private keys unencrypted: anything that can read the file can spend your coins. It keeps working, and the miner will warn you on every start. Converting changes nothing about your mining identity or your payout address — same keys, different container.

./sost-cli --wallet ~/sost-keys/my-wallet.json wallet-export

For unattended restarts the miner reads the passphrase from a file or a descriptor (--wallet-passphrase-file, --wallet-passphrase-fd) instead of prompting. -fd takes the descriptor number, never the passphrase itself.

Half of every block's emission already goes to the DTD distribution, and you take part by mining. Nothing to register, nothing to sign up for.

What Jackpot V2 asks for

• Your SbPoW mining identity — the key behind --mining-key-label.
• At least 3 blocks mined in the last 2,016 (~14 days).
• An active NODE_BIND tying a node key to that mining key.
• Heartbeats, on a ramp: 0 are required for the first draw at #30,186, because no epoch has completed yet. It rises 1-of-1, then 2-of-2, then 3-of-3, and settles at the permanent rule — 3 of the last 4 epochs of 288 blocks — from #31,338.

Check your own eligibility — no keys involved

curl -s -X POST https://sostcore.com/rpc/public -d '{"jsonrpc":"1.0","id":"a",
 "method":"checkhistoricaljackpoteligibility","params":["sost1YOUR_MINING_ADDRESS"]}'

It takes a public address and returns node_bound, pow_blocks, heartbeats_valid, eligible and the reasons you are not. It never asks for a private key. Anyone who asks you for one is stealing from you.

Preparing is not registering

You can create and protect the key today. You cannot register it until V30000 is live at #30,000 — the transaction type does not exist before that height, and broadcasting it early achieves nothing.

Now: create the node key

umask 077
openssl rand -hex 32 > ~/.sost/node.key
chmod 600 ~/.sost/node.key

This is a different key from your mining key and from your wallet. It identifies your node. It cannot move coins — but whoever holds it can impersonate your node's heartbeats, so treat it as a secret and back it up (see the next section).

After #30,000: build the transaction

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

It prints which mining key it is binding and then the raw transaction hex. The label must be the same one your miner signs blocks with — if it does not exist, the command refuses and lists your wallet's labels instead of binding the wrong key. 1 is the bind sequence; it only increases if you ever replace the node key.

Then: broadcast it and check it landed

curl -s -X POST https://sostcore.com/rpc/public \
  -d '{"jsonrpc":"1.0","id":"a","method":"sendrawtransaction","params":["PASTE_HEX"]}'

If it does not return a txid, do not resend blindly — check getrawmempool first. Then restart your node with --node-key-file ~/.sost/node.key so it emits its own heartbeats.

The proof that it worked is not "I sent the transaction". It is checkhistoricaljackpoteligibility answering "node_bound": true and "eligible": true. Check it before #30,186.

Keeping the heartbeats alive

Once the node runs with --node-key-file, it does the heartbeats by itself: a thread signs and broadcasts one NODE_HEARTBEAT per epoch — an epoch is 288 blocks (~48 h), the same cadence as the jackpot — but only once the node is bound and V30000 is live (#30,000). You do not run nodeheartbeat by hand; that command exists only for unusual setups where the signing node is not the one you want emitting.

What you actually have to do is keep the node up. Miss an epoch (node down, key removed) and that epoch's heartbeat is simply absent — the permanent rule is 3 of the last 4 epochs, so one gap is survivable, two in a row are not. Check it is working:

ssh root@YOUR_VPS 'grep -a "auto-heartbeat" /var/log/sost-node.log | tail -2'

You want [NODE-HEARTBEAT] auto-heartbeat enabled for node pubkey … at startup, and later emitted heartbeat for epoch N once per epoch. Or read it back from consensus: checkhistoricaljackpoteligibility shows heartbeats_valid climbing toward heartbeats_required. Before #30,186 both are 0, which is why the first draw needs no heartbeat history at all.

How to keep a backup that is actually a backup

• Encrypt it, and store it off the machine that holds the original. A copy on the same server does not survive losing the server.
• Store the passphrase separately. On the same USB stick as the encrypted file, the encryption is decoration.
• Test the restore. An untested backup is a belief, not a backup. Recover it into a temporary folder and compare the checksum.
• chmod 600 and owned by the right account, everywhere.

The five we keep seeing

1. Password in ps — started with --rpc-pass. Every local user can read it.
2. Two miners running — usually one forgotten in another terminal. Half your work is discarded.
3. RPC exposed — --rpc-public without a firewall. That is your wallet on the internet.
4. Wrong --mining-key-label — a label that does not exist, or with different spacing.
5. Unverified binaries — downloaded and run without checking the SHA-256.

"Why is nothing asking me for an RPC password?"

Because there is nothing to ask. You create it yourself on your own node. If you are mining against someone else's node, that operator gives it to you. Nobody else can.

"UNENCRYPTED (v1) wallet" on every miner start

A warning, not an error. Your wallet file holds the keys in the clear. Mining works. Section 5 covers converting.

"Local height: 0" when it starts

Normal. It is still loading. Wait for [DATASET] regenerated and then [MINING] Starting N threads — typically one to two minutes.

"Is it really mining?"

Look for a line with att/s that keeps updating, and CPU usage near threads × 100%. A static log is a stuck miner.

"submitted to node OK" — did I earn it?

Your node accepted it. It is on your chain and being relayed. It is really yours when the Explorer shows it.

"RPC AUTHENTICATION REJECTED (HTTP 401)"

User or password does not match what the node was started with. Most often: the password file changed but the node or the miner was never restarted — both read it once, at startup.

"My node has no peers"

Check that P2P port 19333 is open inbound on your server; that is a different port from RPC. Read the status section below before assuming your node is broken.

"Am I ready for Jackpot V2?"

Run checkhistoricaljackpoteligibility (section 6). It answers with reasons.

"Do I restart at #30,000?"

No. Activation is automatic. Install the binaries in the window, and then leave your node alone. The only later restart is optional: adding --node-key-file for the Jackpot.

"What if I stay on the old version?"

Before #30,000, nothing happens. From #30,000 a pre-V30000 node applies the old rules and will reject blocks the network accepts — it follows a chain nobody else is on. Your coins are safe; your node is not useful.

• Block serving & sync rate limit. Under load a node could leave a block frame half-written, desynchronising the peer, and a freshly-synced node could ban the very peer that had just served it the chain. Fixed in main (commit cfcfe9df) and deployed to the production node on 2026-09-24 — the node accepted new blocks after the restart with zero undue bans.
• Historical revalidation. 66 blocks (19 with recomputed cASERT values, 4,160–5,410; 47 with a since-corrected profile-parameter table, 4,715–5,038), all mined in April 2026, could not be re-validated by today's rules. The fix pins each one by height and full block hash, changes no rule for any new block, and is in the same commit. Verified by a full genesis→tip sync (encrypted and plaintext): both clients reached the tip with the same hashes as the reference node, 0 rejects, all 66 exceptions used once each.

We describe as done only what is proven: the fix is merged in GitHub, running on the production node, and published as a signed binary release (V30000) whose downloaded artifacts were re-verified against their SHA-256. No external security audit of this software has been performed.