Bitcoin Forum
June 16, 2026, 07:46:59 PM *
News: Latest Bitcoin Core release: 31.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 [8] 9 »  All
  Print  
Author Topic: [ANN] SOST — Native PoW Chain | ConvergenceX | CPU-First | 8 GB | Gold Reserve  (Read 2291 times)
Neob1844 (OP)
Newbie
*
Offline

Activity: 84
Merit: 0


View Profile WWW
May 25, 2026, 08:00:33 AM
Last edit: May 25, 2026, 08:18:28 AM by Neob1844
 #141

  ═══════════════════════════════════════════════════════════════════
  [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
Neob1844 (OP)
Newbie
*
Offline

Activity: 84
Merit: 0


View Profile WWW
May 25, 2026, 02:53:14 PM
Last edit: May 25, 2026, 04:08:37 PM by Neob1844
 #142

      SOST OTC / P2P — Trustless Cross-Chain Atomic Swaps
        V14 preview · gates still safety-closed · live target: block 15,000

        

        TL;DR

        SOST is building a truly non-custodial OTC / P2P board where two users can swap SOST for another cryptoasset without trusting each other and
        without SOST ever holding their funds
      . Either both legs of the swap settle, or both refund. There is no escrow operator, no admin key, no upgrade
        path. The mechanism is the same primitive that powers the Lightning Network: a Hashed Time-Locked Contract (HTLC) on both chains.

        Seven supported asset pairs

        
      • SOST ↔ BTC  — native, no issuer freeze
      • SOST ↔ ETH  — native, no issuer freeze
      • SOST ↔ BNB  — native, no issuer freeze
      • SOST ↔ USDTissuer-risk (Tether can freeze)
      • SOST ↔ USDCissuer-risk (Circle can freeze)
      • SOST ↔ PAXGissuer-risk (Paxos can freeze)
      • SOST ↔ XAUTissuer-risk (TG Commodities can freeze)

        The issuer-risk label is surfaced explicitly in the wallet UI before every swap. Atomic-swap atomicity holds on the SOST side regardless of any
        issuer behaviour on the counterparty leg.

        

        How it works — plain language

        Alice has SOST, wants BTC. Bob has BTC, wants SOST. They agree price and amounts on the OTC / P2P board. From that point on, no intermediary touches
        either coin
      :

        [list=1]
        
      • Alice locks her SOST in a SOST-side HTLC, redeemable by Bob with a secret only Alice knows (she just generated it). Refundable to Alice after
          timeout T1.
      • Bob locks his BTC in a Bitcoin-side HTLC, redeemable by Alice using the same secret. Refundable to Bob after timeout T2 (T2 < T1 by a
          safety margin enforced by the wallet).
      • Alice claims the BTC by revealing the secret on the Bitcoin chain.
      • Bob reads the secret from the Bitcoin chain and uses it to claim the SOST.

        End state:
        
      • Happy path: both legs settle. Alice gets BTC, Bob gets SOST.
      • One side stalls: timeouts fire. Each party recovers their own coin.
      • Partial settlement: not reachable — the state machine on each chain enforces this without any external coordinator.

        

        Four security pillars

        ⚙ Decentralised. No SOST Foundation custody. No broker. No centralised matching engine. The OTC / P2P board lets two parties find each other; the
        swap itself is bilateral and cryptographic.

        ✓ Atomic. Either both legs complete or both refund. No partial settlement is reachable. The state machine on each chain enforces this without any
        external coordinator.

        🔒 Non-custodial. Neither SOST nor any third party ever holds the funds. The HTLC IS the escrow. There is no owner, no admin, no pause switch,
        no upgrade path, no emergency drain
      in either chain's contract.

        🔍 Verifiable. Every step is a public on-chain transaction. Anyone running a SOST node + a Bitcoin / EVM node can replay the swap and verify that
        the cryptographic conditions held. No off-chain trust required.

        

        Two technical paths

        BTC path
        Native Bitcoin HTLC using a BIP-199-style P2WSH redeem script (SegWit v0). Signing delegated to libwally-core (the Blockstream library used
        in Liquid and Green wallet, continuously fuzzed via OSS-Fuzz since 2019). No Bitcoin script written from scratch by SOST. BIP-143 sighash, BIP-173 Bech32,
         low-S signatures all delegated to the upstream-audited code path. The libwally submodule is pinned to release_1.5.3 (commit
        000137393a436d55a18971ca93a2d20a54d55437), maintainer signature verified.

        EVM path (ETH / BNB / ERC-20)
        Single 273-line Solidity contract AtomicSwapHTLC.sol. No owner, no upgrade, no pause, no drain. 52 Foundry tests covering:
        
      • Exact balance conservation (native + ERC-20)
      • Reentrancy via malicious receiver and via malicious token
      • Weird-ERC-20 behaviour (false-return, no-return, fee-on-transfer)
      • EIP-6780 forced-ETH selfdestruct
      • Claim / refund ordering and double-spend prevention
      • Fuzz: wrong-preimage never claims (256 runs)
      • Fuzz: refundTime boundary is sharp at the exact block (256 runs)

        

        Issuer-risk notice (important, transparent)

        Atomic swap protects against counterparty theft in the swap itself. It cannot stop a token issuer from freezing addresses.
        The four issuers above (Tether, Circle, Paxos, TG Commodities) retain the legal ability to freeze any holder, including a HTLC contract's balance. If a
        freeze fires mid-swap, the SOST side still refunds correctly — cryptographic atomicity on the SOST chain is unaffected — but the counterparty-chain side
        may become uncollectible until the issuer unfreezes.

        BTC, ETH and BNB pairs do not carry this issuer risk — they are native chain currencies with no freeze authority.

        

        Current state of the gates (verifiable in repo)

        ATOMIC_SWAP_HTLC_ACTIVATION_HEIGHT = INT64_MAX — SOST consensus gate, sentinel OFF.
        SOST_BTC_HTLC_SIGNING = OFF — CMake flag, no real BTC signing compiled in.
        V14_HEIGHT = 15,000 — intended activation height (NOT yet active).

        All atomic-swap wallet / RPC / CLI commands refuse --sign --broadcast while the gate stays at INT64_MAX. Mainnet behaviour is
        unchanged today.


        

        What's done, what's pending

        ✓ Done
        
      • SOST-side consensus: LOCK / CLAIM / REFUND validation with adversarial tests
      • Wallet helpers + RPC handlers + CLI commands (all gated)
      • Coordinator state machine (pure local, no IO / no signing / no keys)
      • EVM contract hardened: 52 Foundry tests all green
      • End-to-end local simulation: 10 scenarios, 43 assertions PASS
      • OTC / P2P wizard UI preview (every action button disabled)
      • Pre-deploy operator checklist (15 items)
      • libwally-core vendored and signature-verified (release_1.5.3)

        ⏳ Pending (in this order)
        [list=1]
        
      • Wire libwally wally_* calls into the BTC signing backend (currently disabled stub)
      • Turn the PENDING BIP-143 / BIP-173 test vectors into passing assertions
      • Testnet harnesses: SOST ↔ BTC regtest, SOST ↔ ETH Sepolia, SOST ↔ ERC-20
      • External cryptographic audit (BTC signing usage, Solidity contract, timeouts/economy)
      • Coordinated V14 hard fork activation (flip both gates, operator + miner + wallet recompile)

        Each step is its own commit on the feat/atomic-swap-htlc-v13-candidate branch. Nothing ships to mainnet until ALL of the above are green AND
        signed off by the external review.

        

        Why this matters

        The OTC / P2P space is dominated by custodial brokers (you send first, hope they send back), escrow services (an operator can disappear with
         the funds), and centralised matching engines (single point of failure, single point of regulatory pressure). SOST's atomic swap removes all three
        roles. Two strangers, two chains, one shared secret, two timeouts — or both walk away with their own coins. That is the entire surface of trust. No more,
        no less.

        

        Links

        
        Contact
        
        

        SOST is an experimental native Proof-of-Work project in pre-market testing. Atomic swap is a planned V14 feature; nothing in this post
        represents a guarantee of activation timing, listing, or value. All gates remain safety-closed at the time of writing. — NeoB
      [/list][/list]
      vostokzyf
      Newbie
      *
      Offline

      Activity: 33
      Merit: 0


      View Profile
      May 25, 2026, 03:51:39 PM
      Last edit: May 25, 2026, 04:05:41 PM by vostokzyf
       #143

      Failed to download the file https://sostcore.com/bootstrap-chain.json while trying to resync.


      root@vostok:~# curl -o /root/sost-core/build/chain.json https://sostcore.com/bootstrap-chain.json -f
        % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                       Dload  Upload   Total   Spent    Left  Speed
      100  109k  100  109k    0     0  33611      0  0:00:03  0:00:03 --:--:-- 33615

      The downloaded file does not match.


      2026-05-25 23:55:15 [FORK] Block h=4 bid=5b6169b4c6ad7ae5 does not extend tip (our height=0, delta=-4).
      2026-05-25 23:55:15 [FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0x7e8 vs 0xcda
      2026-05-25 23:55:16 [FORK] Block h=5 bid=7e620ad21dd7e5b5 does not extend tip (our height=0, delta=-5).
      2026-05-25 23:55:16 [FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0x9f1 vs 0xcda
      2026-05-25 23:55:16 [FORK] Block h=6 bid=63907120ec8391f4 does not extend tip (our height=0, delta=-6).
      2026-05-25 23:55:16 [FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0xb51 vs 0xcda
      2026-05-25 23:55:16 [FORK] Block h=7 bid=dfe44fa7aabe48d6 does not extend tip (our height=0, delta=-7).
      2026-05-25 23:55:16 [FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0xc45 vs 0xcda
      2026-05-25 23:55:16 [FORK] Block h=8 bid=fb1c967d0ad9ed84 does not extend tip (our height=0, delta=-8).
      2026-05-25 23:55:16 [FORK] Alternative chain has MORE cumulative work! Fork tip h=8, active tip h=0. Attempting reorg.

      It's stuck and cannot proceed.
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      May 25, 2026, 08:46:51 PM
      Last edit: May 25, 2026, 10:03:18 PM by Welsh
       #144

      vostokzyf, thanks for the report. This looks like a bootstrap-chain.json snapshot issue, not a private-key or wallet issue.

      Please do not delete your wallet files and do not send any private keys, seed phrases, passwords, or wallet data.

      For now, stop using the bootstrap file. Also, please keep the bad file for comparison instead of deleting it:

      systemctl stop sost-node 2>/dev/null || true
      mv /root/sost-core/build/chain.json /root/sost-core/build/chain.json.bad-bootstrap-20260525 2>/dev/null || true

      Then start the node again from a clean chain state and let it sync normally from peers.

      Before deleting anything else, please also send me the output of:

      ls -lh /root/sost-core/build/chain.json.bad-bootstrap-20260525
      sha256sum /root/sost-core/build/chain.json.bad-bootstrap-20260525

      I am checking the public bootstrap-chain.json now. The file currently served appears to be incomplete/stale for a full resync, so I will either regenerate it from the live chain or temporarily remove that bootstrap instruction until the snapshot is verified.

      The log you posted:
      [FORK] Block h=4 ... does not extend tip (our height=0)

      means your node is at genesis/height 0 and is seeing later blocks without a valid local chain base. That matches a bad or mismatched bootstrap snapshot.


      vostokzyf, confirmed and fixed. Thank you for the careful report.

      This was a server-side issue on my end, not a problem with your node, wallet, or keys.

      Root cause:
      https://sostcore.com/bootstrap-chain.json was accidentally serving the website HTML page instead of the real chain snapshot. The bad response was about 110 KB and started with <!DOCTYPE html>, while the real bootstrap snapshot is about 124 MB.

      That explains your log:

      [FORK] Block h=4 ... does not extend tip (our height=0)

      Your node was starting from an invalid/empty local chain state because the downloaded chain.json was not actually chain JSON.

      Fix applied:
      - Restored the real bootstrap-chain.json to the public web path.
      - Verified the served file is JSON, not HTML.
      - Verified size: 129,031,101 bytes.
      - Verified chain_height=10231.
      - Added an hourly refresh cron with JSON validation before publish.
      - The refresh uses tmp + atomic mv, so users should never receive a half-written file.

      You can now retry:

      curl -L -o /root/sost-core/build/chain.json https://sostcore.com/bootstrap-chain.json -f

      The file should be around 124 MB now, not 110 KB.

      Then start your node again.

      If you prefer not to use bootstrap, that is also fine: move the bad chain.json out of the way and let the node sync from peers from genesis.

      Please do not delete wallet files and do not share private keys, seed phrases, passwords, or wallet data.

      This report fixed a real bootstrap deployment bug that would have affected the next users trying to resync.

      — NeoB

      SOST Protocol — Technical Status & Listing Verification
      Sovereign Stock Token · native Proof-of-Work · ConvergenceX consensus · constitutional gold reserve



      Listing verification
      A market-data listing application for SOST has been submitted to CoinMarketCap. This post, published from the official SOST BitcoinTalk ANN, serves as public verification that the request is authentic and originates from the protocol itself.

      CMC application ticket: #1366213

      SOST is a native Layer-1 Proof-of-Work coin — not an ERC-20 or smart-contract token. There is no contract address. Any "SOST contract address" published anywhere is fake.



      Consensus — ConvergenceX
      • Original memory-hard Proof-of-Work written from scratch — not a fork of Bitcoin, Monero, RandomX, Ethash or any existing algorithm.
      • Mining is memory-hard (4 GB dataset + 4 GB scratchpad, ~8 GB RAM) and CPU-oriented — ASIC-resistant by construction.
      • Node verification is lightweight: Transcript V2 compact proof, ~0.2 ms per block, ~500 MB RAM. Anyone can run a full validating node.
      • Chain selection by cumulative work; atomic reorg with full rollback; MAX_REORG_DEPTH = 500.

      Difficulty — cASERT
      • bitsQ Q16.16 fixed-point encoding, 40 equalizer profiles (E4–H35).
      • avg288 retarget: compares the average of the last 288 block intervals against the 600 s target.
      • Dynamic delta cap scaled by deviation, with a median288 sanity check.

      Miner identity — SbPoW
      Signature-Bound Proof-of-Work is active since block 7,100. Every block is cryptographically bound to the miner's key, providing miner identity binding and anti-pool resistance. Mining requires --wallet + --mining-key-label.

      Economics
      • Coinbase split 50 / 25 / 25 — miner / Gold Funding Vault / PoPC Pool. Hardcoded at genesis, immutable.
      • 25% of every block's issuance is allocated by consensus to an on-chain gold reserve (XAUT/PAXG).
      • Max supply: 4,669,201 SOST, hard cap enforced at consensus level.
      • Block time: 10 minutes. Initial reward 7.85100863 SOST, smooth exponential decay.
      • No premine. No ICO. No VC allocation.

      Chain snapshot (as submitted with the CMC application)

      Mainnet genesis      2026-03-15 18:00 UTC
      Block height         #9,807
      Total emitted        77,002.6926 SOST
      Gold Vault balance   15,707.9320 SOST
      PoPC Pool balance    15,707.9320 SOST
      Max supply           4,669,201 SOST

      Live figures are available on the explorer linked below.

      V13 release candidate
      V13 (v13-rc1) activates at block 12,000; upgrade window blocks 11,900–11,999. It brings the full cASERT E7–H35 profile range, SbPoW preimage hardening, and the advisory-only Beacon notice layer. V13 does not change the coinbase split, the emission schedule or the supply cap. SHA256SUMS for the RC are signed with the SOST release key.

      Atomic-swap OTC/P2P (V14, block 15,000) remains in development with all consensus gates safety-closed (ATOMIC_SWAP_HTLC_ACTIVATION_HEIGHT = INT64_MAX) — mainnet behaviour is unchanged today.



      Official resources

      Security
      The protocol does not send direct messages first and never requests funds. All official information is published on the channels above and on this ANN thread. Trust only links cross-checked against sostcore.com.



      SOST is experimental, unaudited software and a native Proof-of-Work protocol still in pre-market testing. ConvergenceX has not been audited by an external security firm. SOST may never obtain market value or be listed on any exchange. Nothing in this post is financial advice. Participate only if you understand the risks. — SOST Protocol
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      May 28, 2026, 03:21:56 PM
      Last edit: May 28, 2026, 07:01:27 PM by Neob1844
       #145

      Hi everyone,

      If you've noticed, in the last 288 blocks there are 5 addresses
      mining almost everything.

      That is NOT a pool. In SOST there are no pools — sbPoW makes it
      unfeasible at the protocol level. They're simply 5 miners with
      stronger machines running solo, just like you or me.

      And yes, that's PoW. It's like a track race: you can't disqualify
      the one who trains harder or has better gear. Whoever puts in more
      work earns more blocks. Penalising that would break the essence of
      Bitcoin and of any honest PoW.

      But here's what matters for those of you mining with a regular CPU:

        · ConvergenceX is memory-hard and CPU-friendly. Your machine counts.
        · Sooner or later, even with a small CPU, you're going to hit a
          block. 24h, 48h, whatever the statistics give you — but it comes.
        · With JUST ONE block you're already in the DTD Lottery, and from
          that point on you start receiving automatic recurring rewards
          without having to win again.
        · On top of that, SOST also has PoPC — Proof of Personal Custody.
          Every block allocates 25% to the PoPC Pool by consensus, as part
          of the 50% miner / 25% Gold Vault / 25% PoPC constitutional split.

      DTD exists precisely for that: so the small miner who genuinely
      participates gets paid, even if the big one mines more blocks. It's
      not charity, it's design. The big miner takes his share by raw force
      and more hashrate, and the small miner takes his by being there, by
      sustaining the network, by having entered the draw.

      PoPC makes that design even more interesting. It gives ordinary users
      and holders another protocol-level path to receive SOST rewards by
      proving personal custody, without needing to out-hash the strongest
      miners. It is not a promise of profit, and it is not a shortcut around
      the rules — but it means SOST participation is not limited to raw
      hashpower alone.

      That is the key point: mining gets you into the block race, DTD gives
      small miners recurring protocol-side upside after their first valid
      block, and PoPC opens a separate custody-based reward path for people
      who actually hold and participate.

      I'm saying this so nobody loses heart — every miner matters to keep
      the chain alive, the big ones and the small ones. So if you're mining
      from home: fire up the node, get your first block, enter DTD, and keep
      an eye on PoPC. The protocol is designed for people who show up.

      See you on the chain.

      — NeoB
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      May 31, 2026, 08:39:37 AM
      Last edit: June 01, 2026, 06:16:46 PM by Welsh
       #146

        SOST Protocol — Useful Compute, Scientific Work and Why Rewards Are Not Being Rushed

        SOST is a native Proof-of-Work chain built around ConvergenceX, a custom memory-hard mining system, protocol-level reserve allocation, PoPC design, a public explorer, a wallet, a DEX alpha surface, an AI research engine and a Useful Compute layer that is already implemented as public dry-run infrastructure.

        This post is not a listing announcement, not a price statement and not an investment invitation.

        SOST is still experimental, unaudited software. There is no active market yet, no exchange listing yet, no guaranteed value and no promise that the protocol will succeed.

        What already exists today

        SOST is not a whitepaper-only idea.

        The current stack already includes:

        Native Proof-of-Work blockchain live since genesis.ConvergenceX memory-hard mining.No premine.No ICO.No dev tax.Public GitHub repository.Public explorer.Browser wallet.Encrypted P2P transport.Dynamic difficulty system.Protocol-level allocation: miner / Gold Funding Vault / PoPC Pool.SOST DEX alpha.Useful Compute public dry-run API.Useful Compute worker.Useful Compute task queues.Worker submission system.Ranking endpoint.Verification and dispute tracking.Public audit export.Automatic queue replenishment.Automatic database backups.Automatic scientific reports.Automatic public snapshots.Private SOST AI Engine v0.25.0 with 1,402 tests green.Materials Engine with a large computational materials corpus.GeaSpirit mineral intelligence stack.
        The Useful Compute layer is already live as infrastructure.

        However, rewards are intentionally postponed.

        Why Useful Compute rewards are postponed

        The crypto industry is currently overloaded with AI narratives.

        There is a lot of marketing around artificial intelligence, GPU compute, useful work and decentralized computation. Some of it may become real and important. But the hard part is not saying that a task is useful.

        The hard part is proving that the work is:

        genuinely useful;deterministic;auditable;hard enough to justify rewards;safe to verify;not fake busywork;not symbolic computation dressed as scientific value;not a reward system that pays for noise.
        SOST does not want to reward weak, artificial or meaningless CPU work just to claim that Useful Compute is active.

        The goal is not to burn CPU cycles.

        The goal is to produce scientific and protocol-level output that can be checked, audited and justified.

        That is why the current Useful Compute worker is testing-only. It can connect, receive tasks, submit results, update rankings and appear in the public audit layer, but current activity is not reward-eligible.

        There will be no payout manifest for the dry-run phase.

        What Useful Compute is intended to become

        Future reward-bearing workloads may include carefully defined task families from the SOST scientific stack.

        For Materials Engine, future tasks may include:

        large-scale deterministic materials screening;candidate prioritization for later DFT;formula ranking;substitution and dopant exploration;PGM-free catalyst screening;photovoltaic candidate filtering;membrane and battery material pre-screening.
        For GeaSpirit, future tasks may include:

        deterministic mineral-target scoring;zone and commodity ranking;false-positive filtering;geospatial feature analysis;heavier raster-based processing when the worker environment is ready.
        Each future Heavy task family must be documented before activation.

        Each future reward window must have clear eligibility rules, verification rules and audit logic.

        Useful Compute is not cancelled. It is being held back until the task layer is strong enough to deserve rewards.

        SOST AI Engine

        SOST also includes a private autonomous research system called the SOST AI Engine.

        It is not a public chatbot and not a public API. It is a private, localhost-only research lab that helps organize Materials Engine, GeaSpirit and Useful Compute planning.

        The AI Engine can generate hypotheses, classify candidate Heavy tasks, plan experiments, maintain research memory and prepare operator decisions.

        But it cannot:

        publish to the website by itself;touch consensus;activate rewards;run DFT;approve its own decisions;use the network by default.
        The golden rule is simple:

        The AI may ask for permission. The AI cannot grant permission to itself.

        Roadmap

        SOST is being developed in stages.

        Current and planned milestones include:

        Genesis — completed.
        Mainnet live — completed.
        Public explorer — completed.
        Wallet — completed.
        Encrypted P2P transport — implemented.
        DEX alpha — live alpha.
        Useful Compute infrastructure — live dry-run / testing only.
        Useful Compute rewards — postponed until real task definitions are ready.
        PoPC — planned activation after technical and network readiness conditions.
        Gold Vault governance — planned as a later protocol phase.
        Physical gold extension — future phase, condition-dependent.
        ZK R&D — future research initiative.
        ZK physical custody proofs — aspirational, dependent on production-grade cryptographic maturity.
        Post-quantum direction — long-term research direction, not marketed as an active deployed feature.
        Heritage Reserve — indefinite long-term protocol objective.
        The ZK and post-quantum items are deliberately presented as research and roadmap items, not as deployed claims.

        Physical custody verification without revealing identity, location or quantity is still an open research problem. SOST will not deploy partial cryptographic solutions just to satisfy a timeline.

        What SOST is trying to avoid

        SOST is trying to avoid three common problems:

        marketing before infrastructure;rewards before verification;claims before proof.
        Useful Compute rewards will only make sense if the work is real, measurable and auditable.

        Until then, the infrastructure remains open for public dry-run testing, but reward activation stays postponed.

        Summary

        SOST already has a live Proof-of-Work chain, custom mining architecture, public explorer, wallet, DEX alpha, Useful Compute dry-run infrastructure, Materials Engine, GeaSpirit and a private AI research engine.

        The protocol is not rushing Useful Compute rewards because useful work must be proven, not advertised.

        The roadmap includes PoPC, Gold Vault governance, scientific Heavy tasks, ZK research, future privacy-preserving custody proofs and long-term post-quantum research direction.

        SOST is experimental.

        SOST is unaudited.

        SOST may fail.

        But the objective is clear:

        Code first. Proof first. Rewards only when the work deserves them.


      SOST V13 — Release Candidate Signed, Activation at Block 12,000 + V14 Scope Announced

        Last updated: 2026-05-30. Current block: ~10,949. V13 activation: block 12,000 (~7 days). V14
        activation: block 15,000 (~28 days, ~2026-06-27).

        This post consolidates V13 + V14 in one place so every operator and node has the same view.

        V13 — CONFIRMED, WIRED, MERGED TO MAIN

        Six consensus items ship at block 12,000:

        cASERT equalizer E7–H35 — full profile range active (rises from H20 to H35). Closes the V6 calibration cycle.
        DTD lottery cooldown 5 → 6 blocks — tighter exclusion under the permanent 1-of-3 cadence.
        Future-timestamp drift cap 60 s → 30 s — NTP synchronisation strongly recommended; a host more than 30 s
        ahead produces blocks every validator rejects.
        Beacon Phase II-A, II-B (3-of-5 threshold sigs) and Phase III P2P gossip — all three advisory only (MAY inform,
        MAY NOT restart, MAY NOT block, MAY NOT change consensus, MAY NOT execute commands). Hard limits on P2P: 4 KB max notice,
        32-notice LRU dedup, 8 notices/peer/min rate limit.


      ⚠ SOST V13 RELEASE CANDIDATE (v13-rc1) — ACTIVATION AT BLOCK 12,000
        UPGRADE WINDOW: blocks 11,900 – 11,999. Update and restart your node before block 12,000.

      What activates at block 12,000
        cASERT equalizer ceiling rises H20 → H35 (full E7–H35 range).DTD lottery recent-winner cooldown 5 → 6 blocks.Future-timestamp drift cap 60 s → 30 s. A host whose clock is more than 30 s ahead of real time will produce blocks that validators
        REJECT. Run NTP.Beacon Phase II-A (operator-signed advisory notices) + Phase III (P2P gossip). Advisory only — never affects consensus, mining, or block
        validity. Phase II-B (threshold) ships implemented but default-off (sentinel) until five independent custodians exist.
        What auto-activates at block 12,100 — NO action needed
        DTD lottery cadence 2-of-3 → 1-of-3 permanent.Anti-dominance gate: any miner address holding ≥ 30 % of the previous 288 blocks is excluded from DTD lottery eligibility until its rolling share
        drops below 30 %. Dominant miners keep their full 50 % miner reward on every block they mine — they only miss the redistributed protocol-side share on
        DTD-triggered blocks. Reversible per-block, no slash, no admin authority.
        
        1) NODE OPERATORS — upgrade sost-node
        During the upgrade window (blocks 11,900–11,999):
        Code:Copy Code  cd <your sost-core directory>
        git pull origin main

        cd build
        cmake -DCMAKE_BUILD_TYPE=Release -DSOST_ENABLE_PHASE2_SBPOW=ON ..
        make -j$(nproc) sost-node

        # restart however you run it, e.g.:
        sudo systemctl restart sost-node
        
        Verify the binary is V13-capable:
        Code:Copy Code  strings build/sost-node | grep -c 'POW-SIG/v13'    # must be > 0
        
        Pre-fork readiness check (NEW in V13 — read-only RPC, touches no consensus):
        Confirms your node can observe the last 288 coinbases (needed for the 12,100 anti-dominance gate):
        Code:Copy Code  curl -s -X POST http://127.0.0.1: (http://127.0.0.1/)<your_rpc_port> \
          -H "Content-Type: application/json" \
          -d '{"method":"getv13readiness","params":[],"id":1}'
          "ready": true → your node sees the full window. You're set for the fork."ready": false → re-sync your node before block 12,000.
        2) MINERS (e.g. WSL miner bridged via RPC tunnel to your node)
        Code:Copy Code  cd <your sost-core directory>
        git pull origin main
        cd build
        make -j$(nproc) sost-miner

        # restart the miner pointing at your UPGRADED node's RPC, using your own
        # --address / --rpc / --rpc-user / --rpc-pass / --threads
          NTP is mandatory for miners. With the 30 s drift cap, an unsynchronised clock will get your blocks rejected.

      Beacon II-A operator key — published
        Canonical fingerprint:
        Code:Copy Codebbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b  = sha256 of the lowercase uncompressed pubkey hex (BEACON_PUBKEY_HEX in src/beacon.cpp). Cross-published in the README, whitepaper and
        this thread so a substituted key is detectable. Beacon is advisory-only — it can MAY inform, MAY NOT restart, block, or change consensus.

        No coordination needed: the upgrade is backward-compatible at validation level — old and new nodes agree up to block 12,000, where the new rules
        take effect by height. Upgrade any time within the window.

        Source: github.com/Neob1844/sost-core (https://github.com/Neob1844/sost-core) (branch main)

      ⚠ SOST V13 RELEASE CANDIDATE (v13-rc1) — ACTIVATES AT BLOCK 12,000
        Upgrade window: blocks 11,900 – 11,999 · Source: github.com/Neob1844/sost-core (branch main)
        Update and restart your node BEFORE block 12,000. The change is backward-compatible at validation level — old and new nodes agree up to 12,000,
        where the new rules take effect by height — so you can upgrade any time inside the window, node by node, no coordination required.

      What activates at block 12,000
        cASERT equalizer ceiling H20 → H35 (full E7–H35 range).DTD lottery recent-winner cooldown 5 → 6 blocks.[/li]
        [li]Future-timestamp drift cap 60 s → 30 s. Run NTP. A host whose clock is more than 30 s ahead of real time will produce
        blocks that validators REJECT.[/li]
        [li]Beacon Phase II-A (operator-signed advisory notices) + Phase III (P2P gossip). Advisory only — never affects consensus, mining,
        or block validity. Phase II-B (3-of-5 threshold) ships implemented but default-off until five independent custodians exist.[/li]
        [/list]

        What auto-activates at block 12,100 — NO action needed
        DTD lottery cadence 2-of-3 → 1-of-3 permanent.Anti-dominance gate: any miner address holding ≥ 30 % of the previous 288 blocks is excluded from DTD lottery eligibility until its rolling
        share drops below 30 %. Dominant miners keep their full 50 % miner reward on every block they mine — they only miss the redistributed protocol-side share
        on DTD-triggered blocks. Reversible per-block, no slash, no admin authority.
        
        1) NODE OPERATORS — upgrade sost-node
        Code:Copy Code  cd <your sost-core directory>
        git pull origin main

        cd build
        cmake -DCMAKE_BUILD_TYPE=Release -DSOST_ENABLE_PHASE2_SBPOW=ON ..
        make -j$(nproc) sost-node

        # restart however you run it, e.g.:
        sudo systemctl restart sost-node
        
        Confirm the binary is V13-capable:
        Code:Copy Code  strings build/sost-node | grep -c 'POW-SIG/v13'     # must be > 0
        
        Pre-fork readiness check (NEW in V13 — read-only RPC, touches no consensus):
        Confirms your node can observe the last 288 coinbases (needed for the 12,100 anti-dominance gate):
        Code:Copy Code  curl -s -X POST http://127.0.0.1: (http://127.0.0.1/)<your_rpc_port> \
          -H "Content-Type: application/json" \
          -d '{"method":"getv13readiness","params":[],"id":1}'
          "ready": true → your node sees the full window. You're set for the fork."ready": false → re-sync your node before block 12,000.
        2) MINERS (e.g. WSL miner bridged via RPC tunnel to a node)
        Code:Copy Code  cd <your sost-core directory>
        git pull origin main
        cd build
        make -j$(nproc) sost-miner

        # restart the miner pointing at your UPGRADED node's RPC, using your own
        # --address / --rpc / --rpc-user / --rpc-pass / --threads
          NTP is mandatory for miners. With the 30 s drift cap, an unsynchronised clock will get your blocks rejected.

      Beacon II-A operator key — now anchored on-chain
        The V13 operator advisory key is published, and its fingerprint is now the first OFFICIAL entry in the SOST Protocol Registry, committed to the
        chain itself:
        Fingerprint: bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186bAnchored at block: 11,034 — txid c6ade3c635d0e5f8814e3512db7974d70908d6bf5000ddc7aafa708452f810a1Signer: SOST Protocol developer address (OFFICIAL whitelist)Manifesto: sostcore.com/api/sost-protocol-beacon-iia-v13-fingerp
        rint-v1.json (https://sostcore.com/api/sost-protocol-beacon-iia-v13-fingerprint-v1.json)
        How you know a Beacon notice is really from the operator
        The operator holds a secret key (offline, encrypted USB — never online). The matching public key is baked into the node software you already run
        (BEACON_PUBKEY_HEX in src/beacon.cpp). Every notice is signed with the secret key; your node automatically verifies the signature
        against the public key and silently drops anything that doesn't verify. A valid notice is still advisory-only — it MAY inform, but it can NEVER
        restart your node, block anything, or change consensus.

        Verify it yourself (anyone can):
        Code:Copy Code  # 1) the published key fingerprint matches the source code:
        grep -A3 'BEACON_PUBKEY_HEX =' src/beacon.cpp | grep -oE '"[0-9a-f]+"' | tr -d '"\n' | sha256sum
        # expected: bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b

        # 2) the on-chain anchor matches the manifesto:
        curl -s https://sostcore.com/api/sost-protocol-beacon-iia-v13-fingerprint-v1.json | sha256sum
        # expected: ceb19dd6b5fd676f0ec8aa97d1514f09b01a8b000f183afa9a8a0aaf9c135c48
        # (its first 16 hex are the anchor carried in the on-chain capsule)
          If either value does not match, do not trust that copy.

      Links
        Source: github.com/Neob1844/sost-core (https://github.com/Neob1844/sost-core) (branch main)Protocol Registry: sostcore.com/protocol-registry.html (https://sostcore.com/protocol-registry.html)Explorer: sostcore.com/sost-explorer.html (https://sostcore.com/sost-explorer.html)

      SOST Protocol Registry — First Official Entry: V13 Beacon II-A Operator Key Anchored On-Chain

      The canonical SOST Beacon Phase II-A operator-key fingerprint is now anchored on the SOST chain itself, as the first OFFICIAL entry in the Protocol Registry. The fingerprint was already cross-published (source code, README, whitepaper, this forum); this commits it to the ledger, so the operator advisory key has a permanent, independently-verifiable on-chain timestamp.

      On-chain record
      • Block: 11,034 — 2026-05-31 06:17:21 UTC
      • Txid: c6ade3c635d0e5f8814e3512db7974d70908d6bf5000ddc7aafa708452f810a1
      • Signer: sost1a8eae8f80fedd8d86187db628a0d81e0367f76de (SOST Protocol developer address, on the OFFICIAL whitelist)
      • Capsule (Open Note): sost-protocol beacon-iia-v13 ceb19dd6b5fd676f
      • Manifesto: sostcore.com/api/sost-protocol-beacon-iia-v13-fingerprint-v1.json
      • Manifesto SHA-256: ceb19dd6b5fd676f0ec8aa97d1514f09b01a8b000f183afa9a8a0aaf9c135c48
      • Beacon II-A key fingerprint: bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b

      How the anchor works
      The on-chain capsule carries the first 16 hex of the manifesto's SHA-256 (ceb19dd6b5fd676f). The manifesto JSON in turn publishes the full Beacon II-A key fingerprint. The fingerprint is the SHA-256 of the lowercase uncompressed public-key hex (BEACON_PUBKEY_HEX in src/beacon.cpp). Two independent links, both verifiable by anyone.

      Independent verification — anyone can run this

      1) The on-chain anchor matches the published manifesto:
      Code:
      curl -s https://sostcore.com/api/sost-protocol-beacon-iia-v13-fingerprint-v1.json | sha256sum
      # expected: ceb19dd6b5fd676f0ec8aa97d1514f09b01a8b000f183afa9a8a0aaf9c135c48
      # the first 16 hex (ceb19dd6b5fd676f) are exactly the anchor in the on-chain capsule.

      2) The published key fingerprint matches the source code on GitHub:
      Code:
      curl -s https://raw.githubusercontent.com/Neob1844/sost-core/main/src/beacon.cpp \
        | grep -A3 'BEACON_PUBKEY_HEX =' | grep -oE '"[0-9a-f]+"' | tr -d '"\n' | openssl dgst -sha256
      # expected: bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b

      (sha256sum and openssl dgst -sha256 are equivalent; use whichever your system has.)

      If either value does not match, do not trust that copy.

      Scope — what Beacon is and is NOT
      Beacon is an authenticated advisory channel for the protocol operator. The operator key can sign notices that nodes display, but it can NEVER:
      • restart a node
      • reject or alter a block
      • slash a miner or freeze funds
      • change any consensus rule
      Phase II-A (single-signature advisory notices) is active from V13 (block 12,000), together with Phase III (peer-to-peer gossip). Phase II-B (3-of-5 threshold signatures) is implemented and tested but ships default-off (BEACON_IIB_THRESHOLD_ACTIVATION_HEIGHT = INT64_MAX) until five independent custodians exist.

      Why this matters
      Cross-publishing the Beacon fingerprint across multiple independent channels (source code, README, whitepaper, BitcoinTalk, and now the chain itself) makes silent key substitution detectable. An attacker who replaces the key in any one channel produces a mismatch with the others; a verifier comparing two channels detects the fraud. The on-chain anchor is the immutable, permanent channel of last resort.

      Links

      — SOST Protocol
      unnamed0simple
      Jr. Member
      *
      Offline

      Activity: 145
      Merit: 1


      View Profile
      June 01, 2026, 02:48:06 AM
       #147


      https://sostcore.com/sost-wallet.html
      This layout makes the wallet difficult to use.
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 01, 2026, 09:02:25 AM
       #148

      https://sostcore.com/hide-nav-button.png

      Please click the HIDE NAV button and the navigation menu will disappear completely.
      unnamed0simple
      Jr. Member
      *
      Offline

      Activity: 145
      Merit: 1


      View Profile
      June 01, 2026, 12:41:50 PM
       #149

      Thanks.
      What should I do if I don't want to participate in the DTD lottery?
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 01, 2026, 08:43:50 PM
      Last edit: June 01, 2026, 09:17:45 PM by Welsh
       #150

      Thanks for the question.

      The DTD lottery is not an external program, pool, staking product or optional side-service. It is part of the protocol-level reward distribution rules.

      So, technically, there is no separate registration step and no manual “join” action. If a miner is eligible under the consensus rules, the node can include that miner in the DTD lottery eligibility set.

      However, the DTD lottery does not affect the normal miner reward.

      The block finder still receives the normal miner-side block reward. The DTD lottery only concerns the redistributed protocol-side allocation on scheduled DTD lottery blocks.

      From block 12,100, the DTD lottery becomes much more restrictive:

      • It applies only to 1 out of every 3 blocks.
      • Only miners with proven SbPoW activity are eligible, meaning the miner must have mined at least one block under SbPoW rules, from block 7,100 onward.
      • A miner with 10% or more of the previous 288 blocks is excluded from DTD lottery eligibility.
      • The exact boundary is: 28/288 blocks remains eligible, 29/288 blocks is excluded.
      • A recent-winner cooldown also applies: a wallet that won recently is excluded during the cooldown window.
      • If no eligible miner exists, the lottery amount is not paid out and rolls over.

      This means the DTD lottery is intended to reduce variance and support smaller miners, not to increase dominance by already-dominant miners.

      If someone does not want to actively participate in the DTD lottery, there is currently no separate opt-out switch, because the mechanism is consensus-level and deterministic. But there is also no additional action required from the miner and no external custody, no registration, no pool and no separate contract.

      Later, depending on community feedback and observed behavior, the DTD lottery can be adjusted, kept, further restricted or removed completely. I prefer to treat this as an empirical protocol mechanism: test it, measure it and only keep it if it improves fairness and decentralization.

      For now, the important point is that from block 12,100 the DTD lottery is no longer a broad redistribution mechanism. It is narrowly targeted, temporary in design, and restricted to miners that satisfy the small-miner and SbPoW eligibility rules.


      GeaSpirit — Second-Chance Mining Intelligence
      Open-data scoring of overlooked, abandoned and underused mining assets
      https://geaspirit.com

      Many mines were abandoned for economic reasons — not because the geology ran out.
      Low metal prices, bankruptcy, dated technology, shallow historical drilling: the ore is often still there. Yet that information is scattered across hundreds of pages and nobody scores it.

      So we built GeaSpirit — Second-Chance Mining Intelligence.

      What it does
      • A live dark world map (the Asset Atlas) of overlooked, abandoned, historic, care-and-maintenance and tailings mining assets.
      • An explainable GeaSpirit Score (0–100) split into four named dimensions — Signal · Access/Depth · Precision · Certainty — each with a HIGH / MEDIUM / LOW confidence band.
      • A free Basic Asset Scan: an instant, system-generated printable PDF for any asset.
      • On-demand intelligence reports, 16 languages, open data, no hype.

      What it is NOT
      • Triage and prioritization — not a guaranteed discovery. Only drilling confirms a deposit.
      • Not a marketplace, not investment advice, no ownership verification.

      Ecosystem
      GeaSpirit is powered by the GeaSpirit Engine and connected to the SOST ecosystem. SOST may support future payment / verification infrastructure, but GeaSpirit is fully usable without any blockchain and holding SOST is not required.

      Take a look: https://geaspirit.com
      Demo report: read a sample
      Contact: contact@geaspirit.com

      If you work with abandoned mines, tailings, dormant concessions or revival projects, I'd value your feedback.
      Koriaz98
      Newbie
      *
      Offline

      Activity: 24
      Merit: 0


      View Profile
      June 04, 2026, 10:20:31 AM
       #151

      Hi, I discovered your interesting and original project with great potential a week ago, and I've been mining it ever since.

      Thank you for your transparent work and your transparent involvement in this great project.

      Indeed, the project is in mainnet but still under development due to the successive V releases and the problems that need fixing along the way.

      But personally, I believe in this project, your project, and it's great to see someone so involved in the POW world.

      That's why I'm giving you my full support.

      V13 is coming soon!

      Keep up the good work and congratulations on all the work already done.
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 04, 2026, 05:24:21 PM
      Last edit: June 04, 2026, 05:44:34 PM by Neob1844
       #152

      Koriaz98, thank you very much for your kind words. It is really encouraging to read messages like this after so many hours and late nights working on the protocol.

      SOST is still very young, and every release is part of the process of strengthening the network. After V14 at block 15,000, probably the most important milestone, if everything goes well, the core protocol should be largely complete, except for possible minor adjustments.

      The priority remains mainnet stability, fair distribution among miners, and long-term resilience. This does not mean the project is moving slowly, quite the opposite, but SOST is designed to last for decades, so every step must be solid.

      I hope that with the Discord launch around block 12,000, more people will gradually join the community and the protocol will gain the visibility it honestly deserves. I have been so focused on protocol security and code review that marketing has remained secondary for now.

      See you on-chain.
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 08, 2026, 04:31:04 PM
      Last edit: June 09, 2026, 02:40:02 PM by Welsh
       #153

      // SECURITY UPDATE — ACTION REQUIRED
      SOST V14 — update your NODE and MINER as soon as possible
      Activation: block #15,000
      Current chain: ~#12,060 (rising)
      Status: height-gated · safe to update now
      A new SOST binary is ready for the V14 consensus hardening. You must COMPILE the new binary first (rebuild from the commit below) and then restart BOTH sost-node and sost-miner — as soon as possible, well before block #15,000 — to stay on the network after activation. Do not wait for #15,000: build and restart now.

      Required commit (main): ef74e885997a1770c5e60977fa0813bc8a831bd3
      “consensus: gate H3/H4 block validation hardening at V14”
      cd /opt/sost
      git fetch origin && git checkout main && git pull origin main
      cd build && cmake .. && make -j"$(nproc)"
      sudo systemctl restart sost-node
      sudo systemctl restart sost-miner
      # if launched manually: stop them and start the newly compiled
      # sost-node AND sost-miner from the same commit
      Why now: nodes/miners still on the old binary may reject V14-valid blocks after #15,000, risking a chain split or mining on an orphaned fork. The new rules are height-gated and do nothing before #15,000 — so updating today is safe and keeps you connected to the network.


       SOST Roadmap Update — V14 ships at block #15,000; full automation grouped into V15 at #20,000

        A short, transparent update on the SOST roadmap.

        V14 — block #15,000 (on track, no action needed)
        V14 ships as planned: the H3/H4 block-validation hardening. (The dynamic fee floor has been live since block #10,000.) This is already included in the current node
        binaries, so operators do not need to do anything — the chain continues normally.

        V15 — block #20,000 (the full automation release)
        Rather than rush the larger systems into V14, we are grouping them into a dedicated automation release, V15:
        
      • PoPC (Proof-of-Personal-Custody) Model A and Model B — full automation
      • OTC / P2P Atomic Swap
      • Gold Vault governance upgrade (90% consensus) — stronger security, decentralization and protection of the protocol's reserve-value mechanism
      • Testnet, replay and coordinated activation before any mainnet flip

        These are some of the most critical building blocks of the network. They will activate together, only after being fully integrated, validated and tested.

        For node / miner operators
        Nothing to do now. Keep running your current V14 binary. A node update enabling the V15 features will be published well before block #20,000, with clear instructions.

        This is not an emergency. The chain continues normally. Automation first — no half-activated protocol systems

      ═══════════════════════════════════════════════════════════════════
      [SOST] Protocol Resilience Demo — Miner survives RPC outage,
             wins block mid-failure, no operator intervention
      ═══════════════════════════════════════════════════════════════════

      Sharing a live operational observation from earlier today that
      illustrates a property of SOST that is hard to demonstrate
      without an actual failure: graceful degradation under transient
      network conditions.

      WHAT HAPPENED
      ─────────────
      At block 12,235, a mining node on the network experienced a
      ~15-second RPC outage to its sost-node. The miner could not
      reach the node for getinfo, fetch_lottery_state, or
      submitblock during that window.

      The on-chain evidence and the captured miner log show the
      following sequence:

        [BLOCK 12235] candidate found (1e5ef868...)
        [LAG-CHECK] RPC getinfo failed (empty response)
          -> node REJECTED block        ← submit failed, RPC down

        [MINER] fetch_lottery_state failed: rpc connection failed
        [MINER] fetch_lottery_state failed: rpc connection failed
        ...   (13 retries over ~15 seconds)

        [DIAG] profile: scale=1 k=1 margin=200 steps=1   ← collapsed
                                                           to minimum
                                                           emergency profile
        [BLOCK 12235] new candidate found (0fd85e51...)
        -> submitted to node OK (1 txs)  ← RPC recovered, block accepted

        [MINING] H11 bitsQ=11.979 | 100.3 att/s   ← back to normal

      Block 12,235 was ultimately mined and accepted by the network
      (hash 0fd85e51...) despite the RPC interruption. The chain
      advanced cleanly to 12,236, 12,237, etc. without any visible
      artefact for other nodes.

      WHAT THE PROTOCOL DID (NO OPERATOR ACTION)
      ──────────────────────────────────────────
      1. The miner detected the RPC failure, did NOT crash.
      2. It continued nonce search using the last known profile,
         then collapsed to the minimum emergency profile (E7) to
         keep working with whatever local state it had.
      3. It retried the RPC every ~1-2 seconds.
      4. It found a second candidate block during the outage.
      5. When the RPC came back, it submitted the candidate cleanly.
      6. It reverted to normal operation on the next height.
      7. The chain itself never noticed: blocks 12,235 → 12,236 →
         12,237 advanced normally for all nodes.

      WHY THIS MATTERS
      ────────────────
      A miner crashing or losing a found block during a 15-second
      network hiccup is a common failure mode in immature PoW
      implementations. SOST's miner:
        - Survives the outage.
        - Keeps doing useful work during it.
        - Recovers the candidate block when connectivity returns.
        - Does not require operator intervention.

      This is the kind of behaviour you cannot prove with unit tests
      — you only see it when a real intermittent failure happens.
      Today the network produced one, and the protocol handled it
      cleanly. Anyone can independently verify block 12,235 on the
      explorer and see that the chain advanced without reorg or
      orphan.

      CONTEXT
      ───────
      SOST is currently past block 12,237, beyond the V13 hard fork
      activation at block 12,000. ConvergenceX PoW + cASERT
      difficulty + V11 Phase-2 SbPoW Schnorr signing are all live.
      Mining is CPU-native (4 GB scratchpad, sequential memory-hard,
      ASIC-resistant). Block target is 10 minutes; the network is
      holding a long-running average of ~9m 58s since genesis.

      LINKS
      ─────
      Repo            : https://github.com/Neob1844/sost-core
      Explorer        : https://sostcore.com/sost-explorer.html
      Block 12,235    : https://sostcore.com/sost-explorer.html
      Website         : https://sostcore.com
      Telegram        : https://t.me/SOSTProtocolOfficial

      — NeoB
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 11, 2026, 03:45:18 AM
       #154

      SOST OTC / P2P Atomic Swap — V15 milestone

      SOST is preparing a trustless, non-custodial OTC/P2P swap engine for:

      SOST ↔ BTC
      SOST ↔ ETH
      SOST ↔ BNB
      SOST ↔ USDT
      SOST ↔ USDC
      SOST ↔ PAXG
      SOST ↔ XAUT

      The mechanism is HTLC-based: two people, two chains, one shared secret, two timeouts. Either both legs settle, or both legs refund.

      No custody. No escrow operator. No admin key. No upgrade path. No pause switch. No emergency drain.

      Current technical status:
      - SOST HTLC consensus core: LOCK / CLAIM / REFUND built and tested
      - BTC path: native P2WSH HTLC, signing path integrated with libwally-core, OFF by default
      - EVM path: AtomicSwapHTLC.sol, no owner/admin/upgrade/pause/drain, 52 Foundry tests
      - Coordinator: end-to-end non-custodial swap session flow built
      - Rehearsals: closed-environment rehearsals completed; daemon rehearsals and external audit still required

      Important gate state:
      ATOMIC_SWAP_HTLC_ACTIVATION_HEIGHT = INT64_MAX — mainnet OFF
      SOST_BTC_HTLC_SIGNING = OFF — default build OFF
      V15_HEIGHT = 20,000 — intended protocol milestone, not active yet

      Pairs marked ⚠ are issuer tokens. USDT / USDC / PAXG / XAUT can be frozen by their issuers on the counterparty chain. SOST-side HTLC atomicity remains valid, but issuer-freeze risk is disclosed before swap.

      This is not live mainnet trading yet. Activation requires daemon rehearsals, replay, operator coordination and external audit.

      Summary: SOST OTC/P2P is moving toward non-custodial atomic swaps: claim with the shared secret, or refund by timeout.
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 12, 2026, 03:52:57 PM
      Last edit: June 14, 2026, 07:53:20 AM by Neob1844
       #155

        
      ⛏️ GeaSpirit — The World's Largest Open Intelligence Platform for Second-Chance Mining Assets
        Worldwide analysis of mines & mineral deposits · A SOST-ecosystem project · geaspirit.com

        

        What is GeaSpirit?
        GeaSpirit reads the world's mines and mineral deposits from open data and triages them — surfacing overlooked, abandoned and
        underutilized "second-chance" assets, and unifying every site into one searchable, scored, geophysically-screened intelligence layer
        in 17 languages.

        By the numbers
        
      • 📍 172,000+ mines & mineral deposits across 100+ countries
      • 🪨 6,000+ mineral species in the open Minerals & Gems database
      • 🌐 17 languages · 🛰️ S2 geophysical screening · 🎯 GeaSpirit Score 0–100

        ⛏️ Mining-asset intelligence
        
      • Global asset map — every continent & major belt (Andes, Witwatersrand, Copperbelt, Great Basin, Pilbara…)
      • GeaSpirit Score — each asset triaged 0–100 with green/amber confidence bands
      • S2 subsurface screening — magnetic (EMAG2) + free-air gravity (Sandwell), ~96% of land assets
      • Second-chance classification — abandoned, historic, tailings, care-&-maintenance, underused — honestly separated from active
          operations

        🪨 Minerals & Gems database — Mindat-class, 100% open
        Each fiche carries, where available:
        
      • Formula · IMA symbol & status · crystal system · space group · unit cell · Nickel-Strunz class · density · streak ·
          colour · named-after · type locality
      • Chemistry computed by GeaSpirit — element weight %, molar mass & radioactivity from the formula (IUPAC atomic
          weights)
      • DFT electronic structure — band gap, electronic character (metal/semiconductor/insulator) & formation energy, from the
          ground-state polymorph

        🔓 Open data only — legally clean by design
        GeaSpirit uses only open / public-domain sources — (CC0),
        OpenStreetMap (ODbL), NIST JARVIS (public domain). It never scrapes licensed databases
        (Mindat, RRUFF, etc.). Every value is open-data-sourced or computed in-house.

        ⚡ SOST fusion
        GeaSpirit is the resource-discovery arm of the SOST ecosystem — the on-chain trust & provenance
        layer that sets it apart from every other mining database.

        

        
      🌍 Explore now → geaspirit.com
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 13, 2026, 07:19:10 PM
       #156

       
      GeaSpirit — what a satellite-driven mining-intelligence report actually measures
        Open Earth-observation + geoscience data → a transparent, second-chance mining read. See a full worked example:
        https://geaspirit.com/report-sample/

       

        We just published a live sample report on one real gold asset (Marvel Loch, Western Australia) so anyone can see
        exactly what GeaSpirit measures — every layer built from free, open data, every claim qualified, and nothing
        overstated.

        What it MEASURES (with real numbers & units):
       
      • Magnetics — reduced-to-pole field (nT), tilt derivative, total horizontal gradient (nT/km), analytic
          signal
        , and a tilt-depth estimate of source depth
      • Radiometrics — potassium %K, uranium & thorium (ppm), Th/K ratio → potassic-alteration vector
      • Gravity — complete Bouguer anomaly (mGal) + tilt → subsurface density contacts
      • Spectral alteration (ASTER) — phyllic / Al-OH (sericite-clay), propylitic / Mg-OH (chlorite), ferric iron,
          silica/quartz index
      • Hyperspectral mineralogy (NASA EMIT, 285 bands) — surface minerals identified by name: chlorite,
          serpentine, kaolinite, nontronite, goethite, hematite, calcite…
      • Terrain (Copernicus DEM) — relief, slope, lineament grain (structural fabric)
      • Radar / change — Sentinel-1 surface structure, InSAR ground motion, multi-year vegetation change (mining
          expansion)
      • Context — nearest documented occurrences (km), infrastructure distances, live mining tenure & owner
          (due-diligence)

        What it DETECTS:
       
      • Hydrothermal alteration halos — the chemical fingerprint around ore systems
      • Structure — faults, shears, intrusive contacts (from magnetic/gravity/DEM)
      • Circular structures — buried intrusions and meteorite-impact rings
      • Iron-oxide / gossan zones, magnetic source depth, density boundaries
      • Surface disturbance / active mining over time

        The meteorite angle 🪐
        Ora Banda (WA) was just confirmed as a meteorite-impact structure inside Archean greenstone — found via a
        circular gravity anomaly, impact breccias with siderophile metals (Ni, Co, Ir, Pt, Pd, Rh) and gold (Quintero
        et al., Meteorit. Planet. Sci., 2026). GeaSpirit's circular-structure detector hunts exactly that signature — concentric
        gravity/magnetic rings in greenstone, which often correlate with gold.

        Minerals
        The same engine identifies named alteration minerals from hyperspectral data (chlorite + kaolinite + iron oxides +
        carbonate = the textbook orogenic-gold alteration assemblage), instead of guessing from broadband colour.

       

        Honest by design — GeaSpirit gives prioritisation & research intelligence, not a resource estimate. It says
        what the open data supports and assigns an explicit confidence level. It does not claim grade, tonnage, ownership
        rights or a discovery — only field work and assay can. The proprietary part is how the layers are fused and scored;
        the evidence is shown in full, including every "what it cannot say".

        👉 Worked example (free, no signup):
        https://geaspirit.com/report-sample/
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 14, 2026, 11:00:45 AM
       #157

      [SOST Node / Explorer Notice]

      We are currently investigating a technical issue affecting the main SOST node used by the public explorer.

      The chain itself is not considered at risk and this does not indicate a consensus problem. The issue appears to be related to the node/RPC service becoming temporarily unresponsive, which interrupts explorer data loading and may also affect miners or tools that are configured to use the same public node as a bridge/RPC endpoint.

      What may be affected:
      • Public explorer loading / live chain data
      • RPC responses from the main public node
      • Miners using the public node as their bridge/RPC endpoint

      What is not currently indicated:
      • No evidence of a chain halt
      • No evidence of a fork
      • No evidence of lost funds
      • No consensus rule change involved

      We are isolating the node, checking RPC responsiveness, logs, restart behaviour and public proxy routing. A further update will be posted as soon as the diagnosis is confirmed.

      In the meantime, operators running their own node should continue normally. Miners relying on the public bridge/RPC may experience interruptions until the service is stabilized.

      Status: under investigation 
      Severity: service interruption / explorer RPC availability 
      Consensus risk: none indicated at this time

      Thank you for your patience.
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 14, 2026, 04:25:30 PM
       #158

        ► SOST Node / Explorer — Resolved (Update Available)

        Status: RESOLVED · Consensus risk: NONE · No fork · No funds affected

        Following up on the previous notice: the issue affecting the public SOST node / explorer
        RPC has been diagnosed and fixed. Below is the full technical write-up.

       

        1. SYMPTOM
       
      • The public node's RPC became unresponsive: the explorer showed "waiting for node", and HTTPS calls returned 504 Gateway
          Time-out.
      • Cheap calls that should be instant (getblockcount, getinfo) timed out at 10–20s; getblocktemplate took ~8s and then
          began timing out.
      • Connections to the RPC port piled up into the thousands.
      • Miners using the public node as their bridge/RPC endpoint were intermittently interrupted.

        2. WHAT IT WAS NOT
       
      • NOT a chain halt — blocks kept being produced and accepted the whole time.
      • NOT a fork, NOT lost funds, NOT a consensus-rule change.
      • NOT the cASERT difficulty algorithm, and NOT caused by any single miner.

        3. ROOT CAUSE (the real one)
        A pre-existing concurrency bug in the P2P layer. The function that serves a block to a
        peer (p2p_send_block) held the node's global chain mutex (g_chain_mu)
        across the blocking TCP send.

        When a peer doing initial block download (IBD) requested historical blocks — the GETB
        handler streams up to 100 blocks per request — and that peer's TCP receive window was
        full, the send() blocked while still holding the lock. Every RPC reader
        (getblockcount, getinfo, getblocktemplate, getblock) serializes on that same mutex, so
        they all starved → timeouts, 504s, and connection pile-up.

        This was confirmed with a live thread backtrace: one P2P thread sat inside the
        block send holding g_chain_mu, while ~30 RPC threads were blocked waiting for it —
        all at 0% CPU. That signature (everything asleep on a lock, nothing computing) proves a
        lock-contention stall, not a heavy computation. It surfaced now simply because the chain
        grew large enough and a peer happened to sync from us.

        4. THE FIX
       
      • Primary (226d8e09): serialize the block into a local buffer under the lock, then release the
          lock before the network send
        . A slow peer can no longer freeze RPC. Wire output is byte-for-byte identical.
      • Secondary (5e3a3cfa): getinfo / getblocktemplate / getblock were rebuilding a difficulty (cASERT)
          metadata vector over the entire ~13k-block chain on every call. cASERT only reads the last ≤288 blocks, so we window the
          build to the last 512 — bit-for-bit identical output (verified 0/80 mismatches across normal/overdue/anti-stall/slingshot
          scenarios), with the per-poll O(n) overhead removed.

        5. VERIFICATION
       
      • cASERT windowing proven identical to the full-chain computation; full cASERT consensus test suite (base / V11 / V12 /
          V13) passes.
      • Post-fix RPC latency under live traffic dropped from 8–20s timeouts to <10 ms for getblockcount / getinfo /
          getblocktemplate.

        6. ACTION FOR OPERATORS
        Recommended stability update — NOT a consensus upgrade. No fork, no activation height.
        Old binaries remain fully compatible and in consensus; they only carry the latent stall
        risk under peer-sync load.
       
      • Run your own node? Update to the latest main for stability.
      • Self-hosted miner with its own node? Same — rebuild and restart.
      • Mining against the public RPC bridge only? No action needed — the public node is already patched.

       
      Code:
        cd /opt/sost
        git pull origin main          # includes 5e3a3cfa + 226d8e09
        cmake --build build --target sost-node -j2
        sudo systemctl restart sost-node
       

       
        Summary: a lock-held-across-network-send bug in the P2P block server, amplified by
        per-call cASERT recomputation over the full chain. Both fixed; identical wire/consensus
        behaviour; recommended (not mandatory) update for self-hosted nodes/miners.

        Thank you for your patience.
      Neob1844 (OP)
      Newbie
      *
      Offline

      Activity: 84
      Merit: 0


      View Profile WWW
      June 15, 2026, 09:12:01 PM
       #159

        ✓ SOST Protocol — Registered in SLIP-0044 (merged by SatoshiLabs)

        As of June 15, 2026, SOST Protocol is officially registered in the BIP-44 / SLIP-0044
        coin-type standard — merged by SatoshiLabs, the team behind Trezor.

       
      • coin_type (decimal): 1869902947
      • Reserved BIP-44 path: m/44'/1869902947'/0'/0/0
      • Address format: BIP-173 / BIP-350 (bech32)

        Merge PR:
        github.com/satoshilabs/slips/pull/2004

        Transparency note: the current SOST reference wallet uses BIP-39 seed phrases with direct key
        derivation — fully secure and functional. Full BIP-44 hierarchical derivation (the reserved path
        above) will be added in a future wallet version if the community requests it, with migration tooling,
        legacy-wallet support during transition, and advance notice. This is a wallet/UX enhancement, not a
        consensus change
      : existing addresses, keys and transactions remain valid.

        SOST is a native L1 PoW blockchain (ConvergenceX, CPU-friendly & memory-hard) with a transparent on-chain
        Gold Vault and PoPC. MIT-licensed. No ICO, no premine, no VCs.
        Website: sostcore.com · GitHub:
        github.com/Neob1844/sost-core
      Koriaz98
      Newbie
      *
      Offline

      Activity: 24
      Merit: 0


      View Profile
      Today at 11:36:36 AM
       #160

      Hi Neob, I'm following your great project closely and mining it. Would it be possible to make everything more readable in the explorer and other pages, as I don't have a magnifying glass? ^^ Thanks a lot
      See you on chain
      Pages: « 1 2 3 4 5 6 7 [8] 9 »  All
        Print  
       
      Jump to:  

      Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!