Bitcoin Forum
April 20, 2026, 10:33:06 AM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 »  All
  Print  
Author Topic: [ANN] SOST — Native PoW Chain | ConvergenceX | CPU-Only | 8 GB | Gold Reserve  (Read 986 times)
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 05, 2026, 11:40:00 AM
Last edit: April 14, 2026, 07:39:56 PM by Neob1844
 #1

https://sostcore.com/sost-logo.png

SOST — Sovereign Stock Token
Native Proof-of-Work chain with protocol-level gold reserve allocation. Native chain. No bridges. No smart contracts on the SOST base layer. No governance tokens.

Genesis Block: March 15, 2026 — 18:00:00 UTC
Public announcement: April 05, 2026 — Decision to advance the originally planned launch date



✓ MAINNET LIVE — Explorer: SOST Explorer — Blockchain Explorer (live stats)
Last updated: April 14, 2026 — cASERT V5 hard fork active since block 4,300 (determinism fix + liveness + extreme-profile entry cap). For current height and live data, visit the explorer.



⚡ PRE-MARKET STATUS ⚡

SOST is currently in PRE-MARKET phase.

  • There is NO active market yet.
  • There is NO exchange listing yet.
  • There is NO guaranteed price.

Current value references are based on an internal model (PoPC — Proof of Personal Custody), which is used exclusively for economic testing. Approximately $6,000 USD equivalent has been committed within PoPC as a reference layer for internal valuation experiments. PoPC does NOT represent a real market price, does NOT imply liquidity, and does NOT guarantee future valuation.

We are actively inviting:
  • Miners
  • Node operators
  • Independent testers
to participate in network stress testing and validation.

This phase is designed to:
  • Identify bugs
  • Validate consensus stability (ConvergenceX + cASERT)
  • Test emission dynamics
  • Improve infrastructure

Planned public launch phase and exchange outreach: from June 16, 2026, subject to testing progress and stability

Until then: SOST should be considered an experimental system in live testing.

"SOST does not simulate a market — it prepares for one."

External Testing Invitation

SOST is not a fork and not a parameter-tweaked clone of an existing PoW chain. It is a completely new native Proof-of-Work protocol built around its own original consensus stack, including the ConvergenceX proof-of-work algorithm, custom difficulty behavior, bootstrap/sync path, P2P rules, and economic design.

Because of that, the current pre-market period is exactly the right time to subject the system to serious external testing.

I would like to explicitly invite:
  • Independent security researchers
  • External reviewers
  • Miners
  • Node operators
  • Adversarial testers

to put the protocol under stress and try to break assumptions wherever possible.

This includes, for example:
  • Bootstrap chain import behavior
  • Historical and live sync behavior
  • P2P edge cases under plaintext transport
  • Encrypted P2P transport behavior, fallback logic, and performance under load
  • ConvergenceX transcript / proof verification paths
  • Consensus stability under adversarial conditions
  • Fork / reorg handling
  • Difficulty adjustment behavior
  • Mempool and transaction propagation
  • Wallet / node interoperability
  • Unexpected crash or desync scenarios

SOST is experimental and has not been audited by any external security firm. That is precisely why these two months of pre-market live testing matter.

If there is a weakness, I want it found now.
If there is a bug, I want it reported now.
If there is a hidden consensus, networking, or ConvergenceX edge case, I want it exposed now.

Constructive criticism, hostile testing, reproducible bug reports, and detailed logs are all welcome.

Thank you to everyone already testing the network. Your reports are helping harden the protocol before broader participation.



⚠ IMPORTANT DISCLAIMER — READ BEFORE PARTICIPATING ⚠

SOST is experimental software. It is a completely new, original proof-of-work protocol written from scratch in C++17. SOST is NOT a fork of Bitcoin, Litecoin, Monero, Ethereum, RandomX, Ethash, Equihash, CryptoNight, or any other existing cryptocurrency or mining algorithm. The entire codebase — consensus rules, PoW algorithm (ConvergenceX), difficulty adjustment (cASERT), transaction validation, UTXO model, P2P networking, and wallet — has been designed and implemented independently.

Security notice:
  • This codebase has NOT been audited by any external security firm. Testing has been conducted exclusively using internal computational tools, automated test suites, and manual code review by the developer.
  • The protocol has NOT been stress-tested by a large number of independent miners. During the early network validation period, mining was conducted primarily by the founder as part of live consensus and infrastructure testing.
  • As with any complex cryptographic software, undiscovered vulnerabilities may exist. The developer is continuously working to identify and fix bugs, but no guarantee of perfect security can be made.
  • The decision to advance the public announcement date was made to enable community participation earlier. This means the protocol has had less real-world testing than originally planned.
  • Historical P2P sync, plaintext fallback, encrypted end-to-end transport, and bootstrap import have now all been validated in repeated runs; however, as with any young protocol, further real-world edge cases may still be discovered and fixed.

Risk acknowledgment:
  • Every participant is solely responsible for their own participation decisions.
  • You may lose funds committed to participation. Mining, holding, and interacting with experimental cryptocurrency software carry inherent risks including but not limited to: software bugs, consensus failures, network attacks, hardware failure, and market volatility.
  • The author and developer (NeoB) assumes NO liability for any losses resulting from the use of this software, whether caused by bugs, vulnerabilities, design flaws, or any other reason.
  • This is an experimental protocol in its early operational phase. Participants should exercise maximum diligence and caution.
  • SOST is not financial advice, not a security, and not a promise of future value.

Ongoing security posture: The developer is actively and continuously monitoring the network, searching for potential security vulnerabilities, and deploying fixes as they are identified. Hard checkpoints are now managed by an automated dynamic system that updates every 30 minutes without requiring node recompilation. A comprehensive emergency response plan is in place. Community-reported bugs will be investigated and addressed with highest priority.



Quick Specs

ParameterValue
AlgorithmConvergenceX v2.0 (memory-hard, CPU-friendly)
Block time600s (10 min)
Max supply4,669,201 SOST (hard cap by construction)
EmissionExponential decay, q = e^(-1/4) ≈ 0.7788
Coinbase split50% miner / 25% Gold Funding Vault / 25% PoPC Pool
DifficultycASERT unified rate control · blocks <1,450 → V1 (48h halflife, 6.25% delta cap) · blocks ≥1,450 → V2 (24h halflife, 12.5% delta cap) · blocks ≥4,170 → V4 (sentinel fix + stateful Ahead Guard) · blocks ≥4,300 → V5 (stateless Ahead Guard, post-slew Safety Rule 1, EBR cliffs, anti-stall floor 1h, H10+ entry cap +1/block)
EncodingSOSTCompact Q16.16 fixed-point
Coinbase maturity1,000 blocks (~7 days)
PremineNONE
ICO / IEONONE
Dev taxNONE
SourceGitHub (public from genesis)

V5 Ahead Guard (block 4,300+): stateless per-block check with post-slew Safety Rule 1 — removes the hidden static-state bug that caused deterministic drift. Emergency Behind Release (EBR): when lag ≤ −10 blocks, profile cliffs unlock relief at E2/E3/E4 levels. Anti-stall floor: reduced from 2h to 1h so a stuck chain recovers twice as fast. Extreme-profile entry cap: once H ≥ H10, the profile can only rise by +1 per block, preventing B0→H12 overshoots.



The Problem

Gold has 5,000 years of monetary history. It is the most trusted store of value across civilizations. But gold has zero programmability — you cannot send it over TCP/IP, you cannot split it into eight decimal places, and you cannot verify its custody without a trusted third party.

Existing gold-backed tokens (XAUT, PAXG) attempt to bridge this gap. They are ERC-20 tokens on Ethereum — centralized custodians hold the gold, the tokens can be frozen by the issuer, and the entire scheme depends on counterparty trust in a single entity. If Paxos or Tether Gold decides your tokens are problematic, they disappear. This is not sound money.

The trust model is the fundamental failure. XAUT holders trust Tether to maintain 1:1 reserves in a Swiss vault. PAXG holders trust Paxos to not freeze their tokens. Both trust their respective custodians to survive regulatory action, remain solvent, and not selectively enforce terms of service. The gold exists in a vault you cannot visit, managed by a company you cannot audit, under a jurisdiction that may change its rules. Every gold-backed ERC-20 is a bearer instrument for counterparty risk dressed up as sound money.

Bitcoin pioneered digital scarcity through proof-of-work — a breakthrough that changed the world. SOST builds on that foundation by exploring a different design: connecting PoW scarcity to physical gold accumulation at the protocol level, through consensus rules that are immutable at genesis. This is not a criticism of Bitcoin — it is an exploration of a complementary approach.



The Solution

Every SOST block automatically allocates 25% of the coinbase reward to a Gold Funding Vault address. This is not a governance decision. It is not a DAO vote. It is a consensus rule — any block that does not include the correct 50/25/25 split to the correct constitutional addresses is invalid and rejected by every node on the network. The split is hardcoded at genesis and cannot be modified.

The remaining 25% flows to a PoPC Pool powering Proof of Personal Custody — a mechanism that rewards holders who self-custody gold and prove it.

Model A — Bond with Autocustody. The participant declares an Ethereum wallet holding XAUT or PAXG, locks a SOST bond (10-25% of gold value, based on SOST/gold price ratio), and commits to maintain custody for 1 to 12 months. Random audits derived from ConvergenceX block entropy verify custody. On success: bond returned + reward (up to 20% of bond at Tier 1, dynamically adjusted by participation tier and pool utilization). Protocol fee: 3%. On failure: bond slashed automatically (50% PoPC Pool / 50% Gold Vault). The gold never leaves the user's wallet. Anti-whale tiers apply above 10 oz.

Model B — Timelocked Escrow. The participant deposits XAUT/PAXG into an immutable escrow contract on Ethereum. SOST reward paid immediately (up to 8% of gold value at Tier 1, dynamically adjusted). Protocol fee: 8%. At expiry, depositor withdraws 100% of gold. No audits. No bond. No slash.

SOST is not pegged to gold. Holders have no redemption right against the reserve. There is no stablecoin mechanic, no oracle dependency for consensus, and no algorithmic peg.

PoPC Activation Conditions

PoPC (Proof of Personal Custody) is implemented in software and publicly documented, but it is NOT yet active on mainnet.

PoPC activation will occur only once the following technical and network conditions are met:

  • Block height ≥ 5,000 — activation is tied to a protocol milestone and will not occur before this threshold.
  • Sustained network stability — the chain must demonstrate consistent block production, stable synchronization across nodes, and absence of critical consensus or networking issues.
  • Sufficient node and miner participation — a minimum level of independent nodes and active miners is required to ensure reliable operation under real network conditions.
  • PoPC contract validation (Model A) — registration, audit, reward, and slashing flows must be fully validated under live network testing conditions.
  • Ethereum escrow deployment (Model B) — final escrow contracts must be deployed, verified, and publicly auditable before Model B activation.
  • Explorer and wallet integration readiness — public interfaces must correctly reflect PoPC states such as pending, active, completed, and slashed.

Activation note: PoPC activation is protocol-scheduled but condition-dependent. Reaching block 5,000 is a necessary condition, but activation will proceed only once the system is considered stable and all required components are fully operational.



ConvergenceX v2.0 — Technical Details

In simple terms: Bitcoin adjusts in bulk every ~14 days — if hashrate doubles overnight, difficulty doesn't respond for up to 2 weeks. Monero adjusts every block but uses a single EWMA formula with one control signal. SOST adjusts every block using a full PID controller with 5 weighted inputs (U = 0.05·r + 0.40·lag + 0.15·I + 0.05·burst + 0.02·V) and 17 dynamic profiles that change the stability parameters of the ConvergenceX puzzle itself — not just the difficulty target, but how hard the stability basin check is. This makes the chain more resistant to hashrate attacks and faster to recover from mining disruptions.

ConvergenceX is not a hash lottery. Each mining attempt requires solving a 32×32 linear system through 100,000 sequential rounds of integer-only gradient descent, then proving the solution sits in a stable basin of attraction.

Memory-hard: 4 GB dataset + 4 GB scratchpad = ~8 GB total mining memory. Node validation: ~500 MB only.
Per-block program: 256-operation program changes every block. No fixed ASIC circuit can optimize for it.
cASERT difficulty: Per-block adjustment, 17 equalizer profiles, anti-stall recovery zones.
Integer-only consensus: Zero floating-point operations. Q16.16 fixed-point difficulty encoding.

Difficulty adjustment — how SOST compares:

FeatureBitcoinMoneroSOST
Adjustment frequencyEvery 2,016 blocks (~2 weeks)Every blockEvery block
Response speed2-week lag~720-block EWMA8-block short + 96-block long EWMA
Halflife~2 weeks (fixed)~720 blocks (~24h)24h, with 5 PID-weighted signals
Max change per blockN/A (bulk)EWMA smoothed12.5% hard cap per block
Dynamic profilesNone (1 formula)None (1 formula)17 profiles (E4 through H12)
Anti-stallNoneNoneZone-based decay + emergency easing
Control signals1 (time delta)1 (timestamp EWMA)5 (rate, lag, integrator, burst, volatility)
Math typeFloating-point128-bit integerQ16.16 fixed-point (zero float)



Fair Launch — Full Transparency

  • Genesis: March 15, 2026, 18:00:00 UTC
  • Block 0 reward: 7.85100863 SOST, with miner, Gold Vault, and PoPC Pool allocations enforced by consensus rules
  • No coins pre-mined. No coins reserved for founder or investors
  • No dev tax. The protocol-defined miner allocation is paid to the mining address that finds the block
  • Source code: Public on GitHub from genesis
  • Hard checkpoints: Historical checkpoints through block 3554 are currently hardcoded. Dynamic checkpoint and assumevalid updates continue on top of that without requiring node recompilation.

Founder mining disclosure: The founder mined solo during the early post-genesis phase as part of the network validation process required by the complexity and experimental nature of this new proof-of-work system. The blocks mined from genesis onward have not been arbitrary; they have been part of the real-world testing needed to validate block production, propagation, difficulty adjustment, cASERT transitions, and overall consensus stability under live conditions. All mined blocks are publicly verifiable on the explorer. The founder had no algorithmic advantage — the same binary, the same rules. The code was public from day one.



Tokenomics

  • Epoch 0 reward: 7.85100863 SOST per block
  • Decay factor: q = e^(-1/4) ≈ 0.7788 per epoch (~22.12% reduction)
  • Epoch length: 131,553 blocks (~2.5 years)
  • Hard cap: 4,669,201 SOST — mathematical consequence, not a counter
  • ~95% mined after ~12 epochs (~30 years). 100% emission completes over ~82 epochs (~205 years)
  • No inflation mechanism. No minting function. No governance override.
  • ~50% to miners, ~25% to Gold Vault, ~25% to PoPC Pool — every block, forever



Transaction Fees

ParameterValue
Min fee rate1 stock/byte (0.00000001 SOST/byte)
Typical TX (~250 bytes)~0.00000250 SOST
Fee split50% miner / 25% Gold Vault / 25% PoPC Pool
Fee marketRBF (Replace-by-Fee) + CPFP (Child-Pays-for-Parent)
ArithmeticRational integer (no floating-point in consensus)

Fees follow the same constitutional 50/25/25 split as block subsidies. Even after emission ends (~year 2228), fees continue accumulating gold reserves in perpetuity.



Synchronization Notice

Historical P2P sync issues reported during early live testing have now been identified and resolved.

The following methods have been validated successfully:
  • Direct P2P sync (plaintext)
  • Bootstrap chain import over HTTPS
  • Encrypted P2P sync, including encrypted/plaintext fallback and encrypted end-to-end operation

These fixes affected the networking / transport layer only.
This does NOT change consensus.
This does NOT change emission.
This does NOT require regenesis.
This does NOT imply chain corruption.
No hard fork was required.

Operational note:
  • --p2p-enc off remains the fastest option for historical sync
  • --p2p-enc on now works, but historical sync is slower under full encryption due to transport overhead
  • Bootstrap remains available as an optional fast-start / fallback path



How to Mine

Requirements: Linux x86_64, 8 GB RAM minimum, CPU-only (GPU provides no advantage).

Low-memory systems (8–12 GB RAM): If std::bad_alloc occurs during ConvergenceX dataset loading, a swap file may be added before starting the miner:
Code:
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
This provides temporary overflow memory during the 4 GB dataset load. Once loading completes, normal mining operation remains stable.

Code:
# Build
git clone https://github.com/Neob1844/sost-core.git
cd sost-core && mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
cp ../genesis_block.json .

# Option 1: Direct P2P sync (fastest historical sync)
rm -rf blocks utxo ~/.sost

./sost-node --genesis genesis_block.json \
  --connect seed.sostcore.com:19333 \
  --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
  --profile mainnet --p2p-enc off

# Option 2: Bootstrap fast-start
curl -o chain.json https://sostcore.com/bootstrap-chain.json
rm -rf blocks utxo ~/.sost

./sost-node --genesis genesis_block.json --chain chain.json \
  --connect seed.sostcore.com:19333 \
  --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
  --profile mainnet --p2p-enc off

# Option 3: Encrypted P2P sync
rm -rf blocks utxo ~/.sost

./sost-node --genesis genesis_block.json \
  --connect seed.sostcore.com:19333 \
  --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
  --profile mainnet --p2p-enc on

# Verify current height
curl -s --user YOUR_USER:YOUR_PASS \
  -d '{"method":"getblockcount","params":[],"id":1}' \
  http://127.0.0.1:18232

# Run miner (after node is fully synced)
./sost-miner --address YOUR_SOST_ADDRESS \
  --rpc 127.0.0.1:18232 --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
  --blocks 999999 --profile mainnet

A wallet can be generated at sostcore.com/sost-wallet.html

Sync note: Direct P2P sync is now functional again. For the fastest historical sync, plaintext transport via --p2p-enc off remains the fastest option. Bootstrap over HTTPS remains available when a node operator wants the quickest possible initialization. Full encrypted P2P via --p2p-enc on is also functional, including fallback to plaintext peers when required, but historical sync is slower under full encryption.



Security Features

  • ECDSA secp256k1 + LOW-S enforcement (BIP-62)
  • 4-layer block validation (structure, header, consensus, atomic UTXO)
  • HD Wallet (BIP39) with 12-word seed phrases
  • PSBT offline signing (air-gapped compatible)
  • Native 2-of-3 multisig (P2SH)
  • RBF + CPFP dynamic fee market
  • Optional encrypted P2P transport: X25519 + ChaCha20-Poly1305. Plaintext and encrypted modes are both functional; plaintext remains the fastest for historical sync, while encrypted mode prioritizes transport confidentiality at higher sync overhead.
  • Peer ban scoring (misbehavior threshold: 100 points, sync-mode exempt)
  • Dynamic assumevalid checkpoints (auto-updated every 30 min, no recompilation needed)
  • MAX_REORG_DEPTH = 500 blocks
  • cASERT suite: 73 tests covering V3.1 → V5 consensus rules, EBR cliffs, slew boundaries, and extreme-profile entry cap.



Ecosystem

GeaSpirit — Multi-Commodity Mineral Intelligence Platform
GeaSpirit is an advanced remote sensing and exploration intelligence platform for metallic AND non-metallic mineral systems. Canonical Score 25.1/40 (63%). Validated commodity types: Porphyry Cu (0.882 AUC), Orogenic Au (0.922), IOCG (0.841), SEDEX Cu-Pb-Zn (0.781), Sediment Cu (0.760), Lithium brines/salares (0.891). Gravity integrated. 11+ zones across 4 continents. GEE-operationalized. Remote-first architecture validated: works anywhere on the planet with satellite data alone.
Our goal: know what lies beneath the Earth's surface before the first drill ever turns.

Materials Discovery Engine
Computational materials discovery. 76,193 materials corpus. 19 campaign profiles including water/lithium/membrane. 35,589 materials screened for multi-function candidates. Novelty-aware consensus ranking with PV false-positive filtering. Runs at $0/month on CPU.
Our goal: design the materials the world needs tomorrow — entirely on a computer, before they ever exist in a lab.



OTC Pre-Market SaleTEMPORARILY CLOSED

⚠ The OTC pre-market sale is currently TEMPORARILY CLOSED. New purchases are not being accepted at this time. The sale will reopen once network stability under cASERT V5 is confirmed and the pending infrastructure work is complete. Follow this thread for the reopening announcement.

Up to 3,000 SOST are planned to be made available at $0.20 each (below PoPC reference of ~$0.22) when the sale reopens.
Source: founder's mining rewards. Gold Vault and PoPC Pool are untouched and verifiable on-chain.
100% of proceeds go to purchasing tokenized gold for the protocol's gold reserve.

Verify the gold reserve: Etherscan — Gold Reserve Wallet
Full details (sale closed for now): sostcore.com/sost-otc.html



Roadmap

MilestoneTargetStatus
Genesis + fair launchMarch 15, 2026DONE
cASERT V2 hard fork (24h halflife)Block 1,450DONE
Public announcement + community miningApril 05, 2026DONE
Native multisig 2-of-3 (P2SH)Block 2,000DONE
Dynamic checkpoint systemApril 07, 2026DONE
Bootstrap chain import over HTTPSApril 09, 2026DONE
Historical bulk P2P sync hardeningApril 2026DONE
Encrypted/plaintext fallback compatibilityApril 2026DONE
Encrypted P2P transport validationApril 2026DONE
cASERT V3 hard fork (±3 slew rate + lag floor)Block 4,100DONE
cASERT V3.1 fix (slew rate enforcement + anti-stall)Block 4,110DONE
V4 compatibility patch (profile_index optional 4,100-4,169)April 13, 2026DONE
cASERT V4 (Ahead Guard + slew-rate sentinel fix + profile_index persistence)Block 4,170DONE
cASERT V5Block 4,300DONE
cASERT V5 detailsApril 13, 2026DONE
— stateless Ahead GuardBlock 4,300DONE
— post-slew Safety Rule 1Block 4,300DONE
— Emergency Behind Release cliffsBlock 4,300DONE
— anti-stall floor 7200s → 3600sBlock 4,300DONE
— extreme-profile entry cap (H10+ limited to +1/block)Block 4,300DONE
Encrypted transport performance optimizationApril 2026IN PROGRESS
Bond Lock + Escrow Lock + Capsule ProtocolBlock 5,000Q2 2026
PoPC Model A — first custody contractsAfter block 5,000Q2-Q3 2026
First gold reserve acquisitionWhen Gold Vault reaches thresholdTBD
Exchange listing explorationAfter sufficient hashrate + liquidity2026-2027



Links


Note: the old explorer.sostcore.com subdomain is deprecated and now redirects automatically.



Contact




LEGAL DISCLAIMER

Post-Quantum Security Roadmap

SOST uses secp256k1 ECDSA (same as Bitcoin) for transaction signatures. While no quantum threat exists today, SOST has a constitutional migration plan:

  • Phase 1 (COMPLETED): Algorithm selected — CRYSTALS-Dilithium (NIST FIPS 204 winner). 2,420-byte signatures, ~0.5ms signing time.
  • Phase 2 (2027): liboqs integration prototype. Performance benchmarks on SOST TX structure.
  • Phase 3 (2028 Q1): Dual signatures on testnet. New sost2 address prefix for post-quantum keys.
  • Phase 4 (2028 Q3): Mainnet activation. Both sost1 (ECDSA) and sost2 (Dilithium) accepted.
  • Phase 5 (2030+): ECDSA deprecation via constitutional hard fork (75% miner vote).

SHA-256 hashing remains safe against quantum attacks (Grover's algorithm reduces security to 128-bit, still sufficient). The migration targets only signatures (ECDSA → Dilithium), not hashing.

SOST is experimental, unaudited software. It is a completely new proof-of-work protocol — not a fork of Bitcoin, Litecoin, Monero, RandomX, Ethash, Equihash, CryptoNight, X11, Scrypt, or any other existing cryptocurrency or algorithm. The ConvergenceX proof-of-work algorithm, the cASERT difficulty adjustment, and the constitutional economic model are original designs that have not been independently verified by any third-party security auditing firm.

This software is provided "AS IS" without warranty of any kind. The developer (NeoB) makes no representations or warranties regarding the security, reliability, or fitness for purpose of this software. The protocol has not been tested under adversarial conditions by a large number of independent miners. Undiscovered vulnerabilities, bugs, or design flaws may exist that could result in loss of funds, consensus failures, or other adverse outcomes.

Every participant is solely and entirely responsible for their own participation decisions and for understanding the risks involved. You acknowledge that you may lose funds committed to participation. The developer assumes no liability whatsoever for any direct, indirect, incidental, or consequential damages arising from the use of this software.

The gold reserve mechanism is not a redemption right, not a price guarantee, and not a stability mechanism. SOST is not a security, not a stablecoin, and not financial advice. Consult qualified professionals before making participation, custody, or financial decisions.

By participating in the SOST network (mining, holding, transacting), you accept these terms and acknowledge full personal responsibility for any outcomes.
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 05, 2026, 11:48:08 AM
Last edit: April 14, 2026, 07:58:27 PM by Neob1844
 #2

ConvergenceX Testing / Network Status / Sync Updates

This reserved post is dedicated exclusively to ConvergenceX testing, bootstrap/sync status, P2P hardening, cASERT behavior, and external validation of the live network during the current pre-market phase.



Purpose of this post

SOST is a new native PoW protocol, not a fork. Its proof-of-work system, ConvergenceX, together with the bootstrap path, P2P transport, cASERT behavior, and transcript verification logic, is being actively tested under real live-network conditions.

This post will be used to track:

  • Sync / bootstrap issues
  • ConvergenceX verification issues
  • P2P transport fixes
  • Fast-sync / checkpoint updates
  • Difficulty-control fixes and cASERT hardening
  • External testing instructions
  • Open requests for logs and reproducible bug reports



Current testing objective

The goal during this pre-market period is to stress test ConvergenceX and the network stack as hard as possible before broader participation.

External testers are explicitly invited to try to break or stress:

  • Bootstrap and initial sync
  • ConvergenceX transcript / proof verification
  • P2P behavior under real-world latency and packet loss
  • Fast-sync and checkpoint transitions
  • Consensus stability under edge cases
  • Fork / orphan / reorg handling
  • Difficulty adjustment behavior under uneven mining conditions
  • Unexpected crashes, desyncs, incomplete block reads, malformed transport cases, or RPC failures

If there is a weakness in ConvergenceX integration, bootstrap, the network path, or cASERT coordination, I want it found now.



What has been found so far

Testing by external users has already exposed several real bootstrap, sync, and control issues, including:

  • Historical blocks being served without sufficient proof data for full CX verification
  • Checkpoint gaps where new peers reached the assumevalid boundary and then failed on immediate post-checkpoint blocks
  • Sync-mode peers being incorrectly penalized by the P2P rate limiter
  • High-latency / packet-loss conditions exposing incomplete block transport cases
  • cASERT equalizer profile oscillation (H3↔H12) due to a slew-rate recomputation bug
  • Anti-stall threshold scaling to 11h+ at high lag values
  • Blocks accepted without profile_index, causing E1-style validation instead of the correct H12 behavior
  • bitsQ dropping aggressively during equalizer braking, undoing part of the correction
  • Miner not detecting anti-stall profile changes, leading to grinding at 0% stability
  • RPC connection accumulation (CLOSE-WAIT) eventually crashing the node
  • cASERT V3.1 fallback-without-label bug: BlockMeta::profile_index defaulted to 0, making legit B0 blocks indistinguishable from "missing" values and silently disabling the ±3 slew rate
  • Deterministic B0→H6→H9→H12→stall oscillation every ~30 blocks caused by a static-state variable inside the Ahead Guard path
  • Stale test_checkpoints.cpp referencing removed CASERT_L2_BLOCKS/L6_BLOCKS constants, breaking fresh-clone builds (reported by colerus)

These reports have been extremely valuable and are exactly why this testing phase exists.



Fixes deployed so far

  • Dynamic assumevalid / checkpoint updates
  • Sync-mode exemption from misbehavior scoring during bootstrap
  • Relaxed sync traffic limits
  • Seed-side restart and checkpoint refreshes as needed
  • Fast-sync improvements for trusted historical ranges
  • Additional P2P transport hardening for higher-latency connections
  • cASERT V3 hard fork (block 4,100): equalizer slew rate ±1 → ±3, lag floor mechanism
  • cASERT V3.1 (block 4,110): slew-rate enforcement fix, anti-stall threshold fixed at 2h (later lowered to 1h in V5), miner auto-restart on profile change, profile_index validation for P2P blocks
  • cASERT V4 hard fork (block 4,170): sentinel profile_index fix — closes the fallback-without-label silent bug that let legit B0 blocks be indistinguishable from "missing" values, silently disabling the ±3 slew rate
  • cASERT V5 hard fork (block 4,300): five consensus changes — (1) stateless Ahead Guard removes a static-state determinism risk; (2) post-slew Safety Rule 1 prevents profile/bits divergence after ±3 slew; (3) Emergency Behind Release (EBR) cliffs unlock relief at lag ≤ −10/−15/−20/−25; (4) anti-stall floor lowered from 7,200s (2h) to 3,600s (1h) so stuck chains recover twice as fast; (5) extreme-profile entry cap — once H ≥ H10, profile can only rise by +1 per block, preventing B0→H12 overshoots
  • Multi-threaded mining (--threads N) for parallel nonce search
  • Real-time hashrate display in the miner
  • RPC CLOSE-WAIT fix (socket timeouts + shutdown + linger)
  • Fake-height peer detection and disconnect

This area is still being actively hardened. If you test and hit a new edge case, please post the full log.



How to test from a clean sync

Code:
git pull
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc) sost-node sost-miner

rm -f chain.json
rm -rf blocks utxo

./sost-node --genesis genesis_block.json \
  --connect seed.sostcore.com:19333 \
  --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
  --profile mainnet

Important: wait for the node to finish syncing fully before starting the miner.

Code:
./sost-miner --address YOUR_ADDRESS \
  --rpc 127.0.0.1:18232 --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
  --blocks 999999 --profile mainnet --threads 4

Explorer:
https://sostcore.com/sost-explorer.html
https://sostprotocol.com/sost-explorer.html

Note: the old explorer.sostcore.com subdomain is deprecated and now redirects automatically.



If testing fails, please include as much of the following as possible:

  • Operating system and version
  • RAM amount
  • Whether you are using WSL2, native Linux, VPS, etc.
  • Exact git state / latest pull / rebuild confirmation
  • Whether you started from clean chain data
  • Full node log output
  • Full miner log output, if mining started
  • Whether the failure happened during sync, post-checkpoint validation, mining, or RPC use
  • Your approximate ping/latency to the seed, if relevant

The more complete the log, the easier it is to reproduce and fix the issue.



I would like to explicitly invite:

  • Independent security researchers
  • External reviewers
  • Miners
  • Node operators
  • Adversarial testers

to actively test ConvergenceX, the sync/bootstrap path, P2P transport, cASERT coordination, and the live consensus flow.

SOST is experimental and unaudited. This is exactly the moment when hidden bugs, fragile assumptions, and network edge cases should be exposed.

Constructive criticism, hostile testing, reproducible bug reports, and full logs are all welcome.



Current status note

This post will be updated as new testing results come in.

For now, the main areas under active observation are:

  • Bootstrap reliability from height 0
  • ConvergenceX verification transitions across checkpoint boundaries
  • P2P robustness under non-ideal network conditions
  • Fast-sync correctness and hardening
  • cASERT behavior under V5 rules — ongoing monitoring
  • Miner behavior under profile changes and multi-thread operation

Thank you to everyone already testing the network. Your reports are directly helping harden ConvergenceX and the surrounding network stack before broader participation.
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 05, 2026, 11:59:58 AM
 #3

Reserved for PoPC, custody models, and reserve mechanics.
visibleplayer
Jr. Member
*
Offline Offline

Activity: 148
Merit: 5


View Profile
April 05, 2026, 12:08:29 PM
 #4

[SYNC] Peer seed.sostcore.com:19333 has height 2987, we have 0 — requesting blocks 1..2987
[BLOCK] REJECTED: CX Transcript V2 verification failed
[SYNC] Block #1 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=10/100]
Laheeboo
Jr. Member
*
Offline Offline

Activity: 83
Merit: 4


View Profile
April 05, 2026, 07:19:03 PM
 #5

The live network is running Transcript V2 blocks but the public binary (v0.4.0) can't validate them. The code that can is not public.  Huh Huh Huh

In most projects the dev and select few get to mine first while everyone else idles and wait to join while they fill their bags will this be different? already 3k blocks and no one can join it?

how were those blocks mined if no one can join  Huh Huh Huh
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 06, 2026, 06:08:09 AM
 #6

Hi, and thanks for reporting this.

The error you're seeing (`CX Transcript V2 verification failed on block #1`) is a known compatibility issue with the current binary. The network is using Transcript V2 witness format for ConvergenceX PoW verification, and that requires building from source.

To sync and mine right now:
1. Clone: https://github.com/Neob1844/sost-core
2. Build from source (README.md has instructions)
3. Make sure you're on the latest commit on `main`

Regarding the "filling bags" concern — fair question. Here's the reality:

- SOST launched March 15. The source code has been public on GitHub since day one.
- Anyone who builds from source can sync and mine. There is no whitelist, no permission needed.
- I am the only miner right now because nobody else has tried yet — not because anyone is blocked.
- Block rewards are 7.85 SOST with a 50/25/25 split: 50% to miner, 25% to Gold Vault (locked), 25% to PoPC Pool (locked). So only half goes to the miner.
- There is no premine. Block 0 is the genesis with zero balance.

The precompiled binary issue is real and I'm working on it — full binaries with Transcript V2 support will be ready before the public launch on June 16. But if you want to mine today, the source code is right there.

I welcome more miners. A single-miner chain is the #1 risk I want to fix.
oswaldzc
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
April 06, 2026, 06:37:45 AM
 #7

Hi, and thanks for reporting this.

The error you're seeing (`CX Transcript V2 verification failed on block #1`) is a known compatibility issue with the current binary. The network is using Transcript V2 witness format for ConvergenceX PoW verification, and that requires building from source.

To sync and mine right now:
1. Clone: https://github.com/Neob1844/sost-core
2. Build from source (README.md has instructions)
3. Make sure you're on the latest commit on `main`

Regarding the "filling bags" concern — fair question. Here's the reality:

- SOST launched March 15. The source code has been public on GitHub since day one.
- Anyone who builds from source can sync and mine. There is no whitelist, no permission needed.
- I am the only miner right now because nobody else has tried yet — not because anyone is blocked.
- Block rewards are 7.85 SOST with a 50/25/25 split: 50% to miner, 25% to Gold Vault (locked), 25% to PoPC Pool (locked). So only half goes to the miner.
- There is no premine. Block 0 is the genesis with zero balance.

The precompiled binary issue is real and I'm working on it — full binaries with Transcript V2 support will be ready before the public launch on June 16. But if you want to mine today, the source code is right there.

I welcome more miners. A single-miner chain is the #1 risk I want to fix.

I followed the instructions exactly as described, but I'm still getting the error: [BLOCK] REJECTED: CX Transcript V2 verification failed. Could you please look into this and check what might be going wrong?
https://github.com/Neob1844/sost-core/issues/1
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 06, 2026, 07:55:24 AM
Last edit: April 11, 2026, 02:09:42 PM by Welsh
 #8

Update on the sync issue:

I found the root cause. The node was not storing the Transcript V2 proof data for historical blocks, so when a new node connects, it receives blocks without the proofs and cannot verify them. That is why the sync fails at block #1.

I’m now implementing an assumevalid checkpoint, using the same general approach as Bitcoin Core for initial sync. New nodes will skip the expensive CX proof verification for historical blocks, while still validating headers, timestamps, cASERT, and coinbase structure.

The fix is being tested right now. I’ll post here again as soon as it is live, together with the updated build instructions.

And honestly, thank you for testing. This is exactly what the project needs during these two months: to be pushed hard, tested as much as possible, and to have any errors found early so I can fix them properly.

Update — sync issue fixed.

The problem: the node wasn't including CX proof data when serving historical blocks over P2P. New nodes received blocks without proofs → verification failed at block #1. Thanks @visibleplayer for catching this.

The fix: assumevalid checkpoint at block 3000 (same mechanism Bitcoin Core uses). New nodes now sync the full chain in under a minute. All structural validation still runs — headers, timestamps, cASERT difficulty, coinbase split, transactions, UTXOs. Only the expensive CX proof verification is skipped for historical blocks. From block 3000 onward, everything is fully verified.

Code is live on GitHub.

  git clone https://github.com/Neob1844/sost-core.git
  cd sost-core && mkdir build && cd build
  cmake .. -DCMAKE_BUILD_TYPE=Release
  make -j$(nproc)
  cp ../genesis_block.json .

To start node:

  ./sost-node --connect seed.sostcore.com:19333 \
    --rpc-user youruser --rpc-pass yourpass --profile mainnet

You should see blocks syncing immediately. Once synced, open a second terminal and mine:

  ./sost-miner --address YOUR_SOST_ADDRESS \
    --rpc 127.0.0.1:18232 --rpc-user youruser --rpc-pass yourpass \
    --blocks 999999 --profile mainnet

Requirements: Ubuntu 22.04+ or WSL2, 8GB RAM, build-essential cmake libssl-dev libsecp256k1-dev.

The network needs more miners. Right now it's just me, that's the biggest risk to fix.

Please, let me know if you hit any issues.
oswaldzc
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
April 06, 2026, 11:14:29 AM
 #9

Update — sync issue fixed.

The problem: the node wasn't including CX proof data when serving historical blocks over P2P. New nodes received blocks without proofs → verification failed at block #1. Thanks @visibleplayer for catching this.

The fix: assumevalid checkpoint at block 3000 (same mechanism Bitcoin Core uses). New nodes now sync the full chain in under a minute. All structural validation still runs — headers, timestamps, cASERT difficulty, coinbase split, transactions, UTXOs. Only the expensive CX proof verification is skipped for historical blocks. From block 3000 onward, everything is fully verified.

Code is live on GitHub.

  git clone https://github.com/Neob1844/sost-core.git
  cd sost-core && mkdir build && cd build
  cmake .. -DCMAKE_BUILD_TYPE=Release
  make -j$(nproc)
  cp ../genesis_block.json .

To start node:

  ./sost-node --connect seed.sostcore.com:19333 \
    --rpc-user youruser --rpc-pass yourpass --profile mainnet

You should see blocks syncing immediately. Once synced, open a second terminal and mine:

  ./sost-miner --address YOUR_SOST_ADDRESS \
    --rpc 127.0.0.1:18232 --rpc-user youruser --rpc-pass yourpass \
    --blocks 999999 --profile mainnet

Requirements: Ubuntu 22.04+ or WSL2, 8GB RAM, build-essential cmake libssl-dev libsecp256k1-dev.

The network needs more miners. Right now it's just me, that's the biggest risk to fix.

Please, let me know if you hit any issues.


3Q for your working, is this working normal? why start with h=1

=== SOST Node v0.4.0 ===
Profile: MAINNET | P2P: 19333 | RPC: 18232 | RPC auth: ON | P2P enc: on | Fast sync: ON

Genesis: 6517916b98ab9f807272bf94f89297011dd5512ecea477bd9d692fbafe699f37
Wallet: 2 keys
PoPC registry: 0 active commitments
Wallet rescan: 0 UTXOs registered (balance: 0.00000000 SOST)
UTXO set: 3 entries | Mempool: 0 txs

[RPC] Listening on 127.0.0.1:18232 — 36 methods (auth=ON)
[P2P] Listening on port 19333
Node running. Ctrl+C to stop.

[P2P] Peer connected: seed.sostcore.com:19333 (outbound)
[P2P] seed.sostcore.com:19333: peer doesn't support encryption, falling back to plaintext
[P2P] Peer disconnected: seed.sostcore.com:19333
[SUBMITBLOCK] Received block submission (params=1)
[BLOCK] fast-sync height=1 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 1 accepted: a8ab4511298fb954 (txs=1, fees=0, UTXOs=6, chainwork=0x19b4)
[SUBMITBLOCK] ACCEPTED


=== SOST Miner v0.6 (FULL submitblock) ===
Miner address: sost1b32cb02669c118d34b4759100c45fa4c25104710
Profile: mainnet | Blocks: 999999 | Max nonce: 500000 | RPC: 127.0.0.1:18232

Genesis: 6517916b98ab9f807272bf94f89297011dd5512ecea477bd9d692fbafe699f37

[MINING] h=1 diff=765730 sub=785100863 fees=0 merkle=5e7fb761ef4e0039 txs=1
[DIAG] Mining h=1 prev=6517916b98ab9f80 bitsQ=765730 (11.6841) profile: scale=1 k=4 margin=185 steps=4
[BLOCK 1] a8ab4511298fb954 nonce=915 extra=0 184620ms txs=1
  sub=785100863 fees=0 miner=392550433 gold=196275215 popc=196275215
  Generating Transcript V2 witnesses...
  6 segment proofs, 12 round witnesses
  -> submitted to node OK (1 txs)
[MINING] h=2 diff=717872 sub=785100863 fees=0 merkle=ed7569523da4f8db txs=1
[DIAG] Mining h=2 prev=a8ab4511298fb954 bitsQ=717872 (10.9539) profile: scale=1 k=3 margin=280 steps=2
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 06, 2026, 04:21:04 PM
Last edit: April 11, 2026, 02:07:36 PM by Welsh
 #10

Found and fixed the issue.

The seed node had a bug in the P2P rate limiter — it wasn't
recognizing incoming sync requests from new nodes (height=0),
so it was treating them as relay traffic and disconnecting
before sync could complete.

Fix is live now. Please try again:

1. Stop everything and delete chain data
2. Restart node:
   ./sost-node --connect seed.sostcore.com:19333 \
     --rpc-user youruser --rpc-pass yourpass --profile mainnet
3. Wait until you see the current height (~3148)
4. Then start the miner

You should sync in under a minute. Let me know if it works.

Thank you very much for your invaluable help.


Hi oswaldzc, your node disconnected from the seed before syncing
the chain — so you are mining a separate chain from block 1,
not the main network.

To fix:
1. Stop the miner
2. Stop the node  
3. Delete your chain data
4. Restart the node and wait for full sync before mining:

   ./sost-node --connect seed.sostcore.com:19333 \
     --rpc-user youruser --rpc-pass yourpass --profile mainnet

   Please, wait until you see height=3127 (or current height).
   Then start the miner.

The P2P encryption fallback is expected — the seed node
accepts plaintext connections. The issue is the immediate
disconnection before sync completed.

I am on it now to find the issue.

A quick note of appreciation to everyone who has been testing
the network these past days — and from now on.

Your bug reports have already led to three critical fixes:
- Transcript V2 sync issue (found by visibleplayer)
- P2P rate limiter bug (found by 3Q)  
- Build compatibility issues (found by oswaldzc)

This is exactly what the pre-market phase is for. Thank you.
oswaldzc
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
April 06, 2026, 04:32:16 PM
 #11

Found and fixed the issue.

The seed node had a bug in the P2P rate limiter — it wasn't
recognizing incoming sync requests from new nodes (height=0),
so it was treating them as relay traffic and disconnecting
before sync could complete.

Fix is live now. Please try again:

1. Stop everything and delete chain data
2. Restart node:
   ./sost-node --connect seed.sostcore.com:19333 \
     --rpc-user youruser --rpc-pass yourpass --profile mainnet
3. Wait until you see the current height (~3148)
4. Then start the miner

You should sync in under a minute. Let me know if it works.

Thank you very much for your invaluable help.

It has successfully synced up to height 3000, but another issue has arisen.
[FORK] Block h=3156 bid=2b96b71d74dc3f29 does not extend tip (our height=3001).
[FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0000000000000000 vs 0000000000000000
[FORK] Block h=3157 bid=5c8e356aaa6b8ef9 does not extend tip (our height=3001).
[FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0000000000000000 vs 0000000000000000
[FORK] Block h=3158 bid=0527619451574837 does not extend tip (our height=3001).
[FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0000000000000000 vs 0000000000000000
[FORK] Block h=3159 bid=daddcb42e3735cc4 does not extend tip (our height=3001).
[FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0000000000000000 vs 0000000000000000
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 3001..3159
[BLOCK] REJECTED: CX Transcript V2 verification failed
[SYNC] Block #3001 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=20/100]
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 3001..3159
[BLOCK] REJECTED: CX Transcript V2 verification failed
[SYNC] Block #3001 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=30/100]
[P2P] Peer disconnected: seed.sostcore.com:19333
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 06, 2026, 05:40:38 PM
Last edit: April 11, 2026, 02:06:09 PM by Welsh
 #12

Good progress — you synced to 3000 correctly.

The issue is that the assumevalid checkpoint covers blocks 1-3000
but blocks 3001+ still require CX proof verification, which is
failing because the proofs aren't being served over P2P yet.

I'm updating the checkpoint to the current height right now.
Please wait a few minutes and then delete your chain data and
sync again from scratch. It will work completely this time.

Sorry for the extra step — this is exactly the kind of testing
that helps find these edge cases before the public launch.
I'll let you know as soon as it's ready.

Hi oswaldzc, checkpoint updated — ready to try again.

Please delete your chain data and sync from scratch:

   ./sost-node --connect seed.sostcore.com:19333 \
     --rpc-user youruser --rpc-pass yourpass --profile mainnet

You should now sync fully to the current height (~3165)
without any CX verification errors.

Let me know if it works. Thanks.
yoshikiazuma
Newbie
*
Offline Offline

Activity: 98
Merit: 0


View Profile WWW
April 06, 2026, 08:32:16 PM
 #13

Hi oswaldzc, checkpoint updated — ready to try again.

Please delete your chain data and sync from scratch:

   ./sost-node --connect seed.sostcore.com:19333 \
     --rpc-user youruser --rpc-pass yourpass --profile mainnet

You should now sync fully to the current height (~3165)
without any CX verification errors.

Let me know if it works. Thanks.

ive been having problems syncing too. how do i delete blockdata on linux and where is it located? thanks
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 06, 2026, 09:28:52 PM
 #14

Hi yoshikiazuma, welcome!

To delete chain data on Linux:

1. Stop the node first:
   Ctrl+C (if running in terminal)
   or: sudo systemctl stop sost-node

2. Delete the chain data:
   rm -rf ~/.sost/chain.json
   rm -rf ~/.sost/blocks/
   rm -rf ~/.sost/utxo/

   Or if you built in a custom directory:
   rm -rf /path/to/sost-core/build/chain.json
   rm -rf /path/to/sost-core/build/blocks/

3. Keep your wallet file safe — do NOT delete:
   ~/.sost/wallet.json

4. Restart the node:
   ./sost-node --connect seed.sostcore.com:19333 \
     --rpc-user youruser --rpc-pass yourpass \
     --profile mainnet

You should sync to current height (~3180+) in under
a minute. Please, let me know if you hit any issues.
yoshikiazuma
Newbie
*
Offline Offline

Activity: 98
Merit: 0


View Profile WWW
April 06, 2026, 10:30:15 PM
 #15

Hi yoshikiazuma, welcome!

To delete chain data on Linux:

1. Stop the node first:
   Ctrl+C (if running in terminal)
   or: sudo systemctl stop sost-node

2. Delete the chain data:
   rm -rf ~/.sost/chain.json
   rm -rf ~/.sost/blocks/
   rm -rf ~/.sost/utxo/

   Or if you built in a custom directory:
   rm -rf /path/to/sost-core/build/chain.json
   rm -rf /path/to/sost-core/build/blocks/

3. Keep your wallet file safe — do NOT delete:
   ~/.sost/wallet.json

4. Restart the node:
   ./sost-node --connect seed.sostcore.com:19333 \
     --rpc-user youruser --rpc-pass yourpass \
     --profile mainnet

You should sync to current height (~3180+) in under
a minute. Please, let me know if you hit any issues.

[P2P] Misbehavior +5 (block rate limit) from seed.sostcore.com:19333 [score=95/100]
[P2P] Rate limit exceeded from seed.sostcore.com:19333 (mode=sync)
[P2P] BANNED seed.sostcore.com:19333: block rate limit (24h)
[P2P] Peer disconnected: seed.sostcore.com:19333
oswaldzc
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
April 07, 2026, 01:15:21 AM
 #16

Hi yoshikiazuma, welcome!

To delete chain data on Linux:

1. Stop the node first:
   Ctrl+C (if running in terminal)
   or: sudo systemctl stop sost-node

2. Delete the chain data:
   rm -rf ~/.sost/chain.json
   rm -rf ~/.sost/blocks/
   rm -rf ~/.sost/utxo/

   Or if you built in a custom directory:
   rm -rf /path/to/sost-core/build/chain.json
   rm -rf /path/to/sost-core/build/blocks/

3. Keep your wallet file safe — do NOT delete:
   ~/.sost/wallet.json

4. Restart the node:
   ./sost-node --connect seed.sostcore.com:19333 \
     --rpc-user youruser --rpc-pass yourpass \
     --profile mainnet

You should sync to current height (~3180+) in under
a minute. Please, let me know if you hit any issues.
I successfully reached 3150, but a new issue has arisen.
[SYNC] Peer seed.sostcore.com:19333 has height 3206, we have 3150 — requesting blocks 3151..3206
[BLOCK] REJECTED: CX Transcript V2 verification failed
[SYNC] Block #3151 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=10/100]
[FORK] Block h=3152 bid=ff218889a0bbd1fa does not extend tip (our height=3151).
[ORPHAN] Block h=3152 stored (parent b422ec7877742992 unknown). 1 orphans total.
[FORK] Block h=3153 bid=f24ed9b68cff637d does not extend tip (our height=3151).
[FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0000000000000000 vs 0000000000000000
[FORK] Block h=3154 bid=e75a18d0d98cbb09 does not extend tip (our height=3151).
[FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0000000000000000 vs 0000000000000000
............
[FORK] Block h=3205 bid=97e467a4e58cd9d8 does not extend tip (our height=3151).
[FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0000000000000000 vs 0000000000000000
[FORK] Block h=3206 bid=719ee9692bb80a20 does not extend tip (our height=3151).
[FORK] Fork stored but has LESS cumulative work (no reorg). Fork work vs active: 0000000000000000 vs 0000000000000000
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 3151..3206
[BLOCK] REJECTED: CX Transcript V2 verification failed
[SYNC] Block #3151 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=20/100]
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 3151..3206
[BLOCK] REJECTED: CX Transcript V2 verification failed
......
[P2P] Rate limit exceeded from seed.sostcore.com:19333 (mode=sync)
[P2P] Misbehavior +5 (block rate limit) from seed.sostcore.com:19333 [score=95/100]
[P2P] Rate limit exceeded from seed.sostcore.com:19333 (mode=sync)
[P2P] BANNED seed.sostcore.com:19333: block rate limit (24h)
[P2P] Peer disconnected: seed.sostcore.com:19333
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 07, 2026, 05:37:54 AM
 #17

Hi both,

I investigated the sync problems more deeply, and there were two separate root causes on the seed/bootstrap path:

1. Sync-mode rate limiter bug
New peers syncing from height 0 could be incorrectly treated as normal relay traffic, which caused misbehavior scoring and, in some cases, an automatic ban during sync.

2. Checkpoint / historical CX verification gap
Nodes syncing from scratch could still hit CX Transcript V2 verification failed on blocks beyond the current assumevalid range, because historical bootstrap was not yet fully robust for those heights.

I believe both issues have now been addressed:

sync-mode peers are no longer penalized during initial sync
the rate limit for sync traffic has been relaxed
the checkpoint system has been updated and is now loaded dynamically, so it should no longer require repeated manual updates as the chain advances
the seed node has been restarted with the new fixes in place

If you were previously stuck, please try again from a clean sync:


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

rm -f chain.json
rm -rf blocks utxo

./sost-node --genesis genesis_block.json \
  --connect seed.sostcore.com:19333 \
  --rpc-user youruser --rpc-pass yourpass \
  --profile mainnet


Please wait for the node to sync fully before starting the miner.

I believe this should now resolve the bootstrap issues, but since this is still live pre-market testing, I would really appreciate it if you let me know the exact result. If anything still fails, please paste the full log output and I will inspect it immediately.

Once synced, you can verify your node at:
https://sostcore.com/sost-explorer.html

Note: the old explorer.sostcore.com URL is deprecated and now redirects to the above.

Your reports have been extremely valuable. Thanks for your patience.
Rizki Maryanto
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
April 07, 2026, 07:48:22 AM
 #18

Quote from: Neob1844 on April 06, 2026, 05:40:38 PM

Hi oswaldzc, checkpoint updated — ready to try again...

Hi Neob, I'm experiencing the exact same issue as @oswaldzc.

I've performed a clean build from the latest commit, deleted all chain data, and synchronized from scratch. The sync was very fast and successful up to the checkpoint at block #3225. However, as soon as it hit block #3226, the node rejected it with the following error:

[BLOCK] REJECTED: CX Transcript V2 verification failed
[SYNC] Block #3226 from seed.sostcore.com:19333 failed validation — stopping sync

After a few retries, my node eventually banned the seed IP due to "misbehavior" score reaching 100. It seems the Transcript V2 data for blocks immediately following the current checkpoint is still failing full validation.

Running on: WSL2 (Ubuntu 22.04), 16GB RAM. Looking forward to the next fix or a higher checkpoint. Thanks for your hard work on this!
Neob1844 (OP)
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
April 07, 2026, 08:02:56 AM
 #19

Hi Rizki Maryanto, thank you for the detailed report.

I reviewed your case carefully, and you are correct: this was the same bootstrap/checkpoint class of issue, but with a more specific cause this time.

What happened was the following:

1. Your node synced correctly up to the current trusted checkpoint range.
   That means the bootstrap path itself was working as intended up to that point.

2. The failure started immediately after the checkpoint boundary, at block `#3226`.
   From that height onward, your node had to switch from trusted historical bootstrap into full CX Transcript V2 verification.

3. The dynamic checkpoint updater had not advanced quickly enough yet.
   The updater was still using thresholds that were too conservative, so the checkpoint lagged behind the tip more than it should have. In practice, that left a small gap where new peers were again forced into full CX verification for freshly synced blocks.

4. Because those post-checkpoint blocks were still not being served robustly enough for that path, your node rejected block `#3226` with:
   `CX Transcript V2 verification failed`

5. After repeated retries against the same failing range, your node eventually accumulated enough misbehavior score to ban the seed IP locally.

So, in short:
the checkpoint mechanism was working, but it was not updating aggressively enough relative to chain growth, which left a small verification gap just beyond the current checkpoint.

I have now adjusted that:

* reduced the checkpoint auto-update trigger so it advances sooner
* reduced the safety distance from the tip so the checkpoint stays much closer to the live chain
* forced the checkpoint forward manually to the current safe range
* restarted the seed node so the new checkpoint is loaded and active

The result is that the trusted range is now much closer to the tip than before, so new peers should no longer hit the same `3226+` gap during bootstrap.

Please try again from a clean sync:

```bash id="9z0v0r"
git pull
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc) sost-node

rm -f chain.json
rm -rf blocks utxo

./sost-node --genesis genesis_block.json \
  --connect seed.sostcore.com:19333 \
  --rpc-user youruser --rpc-pass yourpass \
  --profile mainnet
```

Please wait for the node to finish syncing fully before starting the miner.

I believe this should now resolve the issue, but I do want to be careful and precise: this part of the bootstrap path is still being actively hardened during pre-market testing. So if anything still fails, please paste the full log again and I will inspect it immediately.

Your report was very helpful because it exposed exactly where the dynamic checkpoint policy was still too slow relative to live chain growth.

Rizki Maryanto
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
April 07, 2026, 08:38:04 AM
 #20

Still facing the same issue. Now it got rejected even earlier at block #28 with missing transactions[] (must include coinbase). It seems the seed node data is inconsistent. Ping to seed is around 300ms with some packet loss.
Pages: [1] 2 3 4 5 »  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!