═══════════════════════════════════════════════════════════════════
[ANN] SOST — V12.1 hotfix release: SbPoW build-flag safety + miner
log label fix (cosmetic). Action required: optional recompile
at your convenience. Block production NOT affected.
═══════════════════════════════════════════════════════════════════
TL;DR
─────
* On 2026-05-24 the mainnet chain stalled around block 10,109
because a fresh miner build was compiled without the flag
SOST_ENABLE_PHASE2_SBPOW=ON, producing blocks that failed the
V11 Phase-2 Schnorr (SbPoW) verification path.
* The chain recovered on its own as soon as a correctly-flagged
binary was relaunched. No reorg, no loss of funds, no
consensus rule changed.
* Two defence-in-depth fixes are now in main:
1. CMake default flipped OFF -> ON so future builds are
consensus-capable by default.
2. Runtime guard in sost-node: if a mainnet binary is
started without SbPoW compiled in, it now exits with
FATAL instead of silently mining unverifiable blocks.
* Separately: a cosmetic bug in the miner's status log printed
"H13" for any cASERT profile from H14 through H35. The
miner's internal profile index (used for the actual dataset,
signing, and difficulty target) was always correct — only
the operator-facing label was wrong. Fixed in main.
What happened (block 10,109 stall)
──────────────────────────────────
A node operator rebuilt the miner from main and relaunched.
The default value of the CMake option SOST_ENABLE_PHASE2_SBPOW
was OFF, so the new binary linked the Phase-2 verification
stub instead of the real Schnorr / BIP-340 path that V11
activated at block 7,100.
The resulting binary could PRODUCE blocks but its peers could
not VERIFY them, because the network had been on Phase-2 SbPoW
for ~3,000 blocks. Block production stalled until a binary
compiled with -DSOST_ENABLE_PHASE2_SBPOW=ON came back online.
Total downtime: 9,410 s = 2 h 36 m 50 s, measured from the
timestamp of block 10,109 (the last block before the stall) to
the timestamp of block 10,110 (the first block after recovery).
The chain resumed at block 10,110 with no reorg required. No
block was orphaned, no transaction was lost, no consensus rule
was changed by this incident.
Fixes shipped in main (V12.1 hotfix series)
───────────────────────────────────────────
[P0] CMakeLists.txt — SOST_ENABLE_PHASE2_SBPOW default
changed from OFF to ON. Comment updated to read
"REQUIRED for mainnet consensus". Anyone rebuilding
from main now gets a consensus-capable binary by
default; reproducing the failure mode now requires
explicitly passing -DSOST_ENABLE_PHASE2_SBPOW=OFF.
[P1] V13 mainnet operator checklist updated. The pre-deploy
step now explicitly verifies the flag is present in
build/CMakeCache.txt before the binary is allowed to
run against mainnet.
[P1.5] Runtime guard in src/sost-node.cpp — at start-up, if
ACTIVE_PROFILE == MAINNET and the binary does NOT have
the Phase-2 SbPoW verification path compiled in, the
node now prints FATAL and exits with code 2 instead of
continuing to mine unverifiable blocks. This is a
START-UP SAFETY CHECK, not a consensus rule change.
Net effect: it is now substantially harder to repeat the
2026-05-24 incident, even for an operator who rebuilds with
the wrong flag by accident.
Cosmetic bug — miner status line says "H13" for H14..H35
─────────────────────────────────────────────────────────
The miner's diagnostic log lines used a static 21-entry name
table (E7..H13) that was correct under the pre-V12 ceiling
H13, but was never extended when V12 raised the ceiling to
H20 at block 7,350. Operator-visible symptom:
[MINING] H13 bitsQ=9.754 | <att/s> | stable=...
[LAG-CHECK] Node says H13, mining H13 -> triggering restart
[LAG-ADJUST] Profile changed: H13 -> H13. Restarting search.
Despite what the log says, the miner is mining the CORRECT
profile. The miner uses the integer stab_profile_index for
the SbPoW dataset, the signing message, and the difficulty
target. Only the text rendering of that integer was wrong.
The "H13 -> H13" restart messages are real profile changes
(e.g. H20 -> H19 -> H17) hidden by the same label collapse.
This is COSMETIC. Block production is not affected. Blocks
are accepted normally. Reward distribution is normal. The
difficulty seen on the explorer's main dashboard (which
reads the integer index directly via RPC) is the truthful
value.
Fixes in main:
eed7ec95 profile_label() now spans the full E7..H35 range
5efd1f89 the inline truncated array in the [MINING]
status line is replaced with a call to
profile_label() so every diagnostic line shares
one source of truth
A related display bug in the explorer's block-detail page
(cASERT_target was hardcoded at H13 and never updated for
V12) is also fixed:
18d95da6 the ceilingH ternary on the block-detail page
now covers V12 (H20 from 7,350+) and V13
(H35 from 12,000+)
What miners should do
─────────────────────
SHORT VERSION:
- You do NOT need to stop or restart your miner.
- You do NOT need to recompile urgently.
- Pull main and rebuild at your convenience.
LONG VERSION:
- If you rebuilt the miner between block 10,100 and 10,109
on 2026-05-24 from main without explicitly passing
-DSOST_ENABLE_PHASE2_SBPOW=ON, your binary was the wrong
one. Pull main and recompile — the default is now ON, so
a plain `cmake -B build && cmake --build build` produces
a consensus-capable binary.
- If your miner log shows "H13" while the explorer's
cASERT panel shows H17 / H18 / H19 / H20, this is the
cosmetic bug described above. Your mining is correct.
Pull main and recompile only when convenient. Existing
binaries are NOT at risk and do NOT need to be replaced
right now.
- Verification command after recompile (use -n 3 because
"H20" is three characters and the default strings
minimum length is four):
strings -n 3 build/sost-miner | grep -cE '^H[1-3][0-9]$'
Should report ~26 distinct labels (H10..H35).
- The V13 hard fork lands at block 12,000. The chain is at
block ~10,185 at time of writing, so there is a
comfortable window. The V13 pre-activation announcement
(target: block ~11,900) will include the operator
checklist with the SbPoW start-up guard listed as a
pre-flight item.
What this changes for the protocol
──────────────────────────────────
NOTHING. The incident did not require, and the fixes do not
introduce, any consensus rule change.
V13 hard-fork rules (V13_HEIGHT = 12,000), the cASERT
equalizer profiles and ceilings, the Slingshot V12 cascade,
the dynamic cap, the slew rate and the PoPC contract logic
all remain unchanged.
The HTLC atomic-swap work continues on its development
branch (feat/atomic-swap-htlc-v13-candidate). On that branch
V14_HEIGHT = 15,000 is the intended activation target, and
ATOMIC_SWAP_HTLC_ACTIVATION_HEIGHT is still pinned at
INT64_MAX (sentinel / disabled). The branch is NOT in main
and HTLC is NOT activated by this V12.1 release. Activation
will require a separate hard-fork announcement when the
pre-deploy checklist is fully signed off.
V12.1 is a build-system and operator-tooling release.
Deliberately NOT a hard fork.
Repository / commits
────────────────────
github.com/Neob1844/sost-core/commit/ed72670f (P0: CMake default OFF->ON)
github.com/Neob1844/sost-core/commit/0b3a4fda (P1.5: runtime guard in sost-node)
github.com/Neob1844/sost-core/commit/eed7ec95 (profile_label canonical 43-entry table)
github.com/Neob1844/sost-core/commit/5efd1f89 ([MINING] status line uses profile_label)
github.com/Neob1844/sost-core/commit/18d95da6 (explorer block-detail ceilingH for V12 + V13)
Contact / questions
───────────────────
Telegram (public channel) : t.me/SOSTProtocolOfficial
Website / contact form : sostcore.com
───────────────────────────────────────────────────────────────────
Apologies to operators for the 2 h 37 m of friction on 2026-05-24.
The root cause is fixed, the cosmetic noise is fixed, and the
start-up guard makes a repeat of the same mistake fail loudly
instead of silently.
— NeoB
