[ANN] SOST — Native PoW Chain | ConvergenceX | CPU-Only | 8 GB | Gold Reserve

[Neob1844]

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]

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]

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]

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.

[Neob1844]

The block #28 error
("missing transactions[]") is a different issue from the
checkpoint gap — it means the block data was received
incomplete or corrupted during P2P transmission.

Your 300ms ping with packet loss to the seed is likely
contributing to this. The P2P protocol sends full block
data over TCP, and high latency + packet loss can cause
incomplete reads.

I have just pushed the checkpoint to block 3245 (only 5
blocks from the tip). Your node should now sync almost
entirely in fast-sync mode.

Please try one more time:

   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

If the block #28 error still appears with the new build,
please share the full log — this would indicate a P2P
transport issue under high-latency conditions that I need
to investigate and harden specifically.

[Neob1844]

Working on two additional fixes right now based on Rizki's report.

Fix 1 (immediate): In fast-sync mode, blocks under the
checkpoint will no longer require full transaction data
validation — only header + hash verification. This should
resolve the "missing transactions[]" error on high-latency
connections.

Fix 2 (robustness): Improving P2P transport to handle
high-latency connections with packet loss more gracefully
— retry logic, better error recovery.

Please hold on. I will post here as soon
as both fixes are live and you can try again.

[Neob1844]

 I found the root cause of your block #28 error and have deployed
  two fixes:

  1. Header-only fast-sync: blocks under the trusted checkpoint
     range now accept even if the transaction data arrives
     incomplete. This handles the case where high-latency
     connections (your 300ms ping) cause partial block delivery.

  2. P2P resilience: socket timeouts increased to 30s, TCP_NODELAY
     enabled, read retries with 100ms backoff for EAGAIN/EWOULDBLOCK,
     and 256KB socket buffers. This should handle packet loss much
     better.

  The checkpoint is now at block 3245 (only 5 blocks from tip),
  so your entire sync should complete in trusted fast-sync mode.

  Please try again:

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

  rm -f chain.json

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

[Neob1844]

For anyone who wants to start mining SOST right now — here is the full process from scratch:

STEP 1 — Build from source

   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 .

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

STEP 2 — Generate your RPC credentials

   NEW_USER=$(openssl rand -hex 10)
   NEW_PASS=$(openssl rand -hex 20)
   echo "RPC USER: $NEW_USER"
   echo "RPC PASS: $NEW_PASS"

Save these — you will need them for the node and miner.

STEP 3 — Generate a SOST wallet address

   https://sostcore.com/sost-wallet.html

Save your seed phrase. You will need the sost1... address for mining.

STEP 4 — Start the node and wait for full sync

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

Wait until you see the current block height (~3245+).
Do NOT start the miner until sync is complete.

STEP 5 — Start mining

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

That's it. You should see blocks being mined immediately.

Explorer to verify your address:
https://sostcore.com/sost-explorer.html
https://sostprotocol.com/sost-explorer.html

18232 → RPC (used by the miner to communicate with the node)
19333 → P2P (used by nodes to communicate with each other)

Any issues? Please, post your full log here.

[Rizki Maryanto]

Hi Neob1844,

Thank you for the quick fixes. I have followed your instructions: performed a git pull (already up to date), re-compiled sost-node, and completely purged ~/.sost, chain.json, blocks/, and utxo/.

However, the node is still stuck at height 2501. Even with a completely empty data directory, it immediately attempts to request blocks starting from 2501 instead of 3245 or syncing from genesis.

Here is my latest log:

Bash

root@srv1561018:~/sost-core/build# cp ../genesis_block.json .
root@srv1561018:~/sost-core/build# nohup ./sost-node --genesis genesis_block.json \
>   --connect seed.sostcore.com:19333 \
>   --rpc-user rizki --rpc-pass sost_jaya_selalu \
>   --profile mainnet > node.log 2>&1 &
[1] 21695
root@srv1561018:~/sost-core/build# tail -n 20 node.log
[ORPHAN] Block h=2847 stored (parent 0da1666478f19ebe unknown). 8 orphans total.
[FORK] Block h=2848 bid=b8072d5d5bf478b6 does not extend tip (our height=2501).
[SYNC] Block #2848 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=70/100]
[FORK] Block h=2849 bid=f6ea6758586df89e does not extend tip (our height=2501).
[ORPHAN] Block h=2849 stored (parent b8072d5d5bf478b6 unknown). 9 orphans total.
[FORK] Block h=2850 bid=30122ce5ba3d4aac does not extend tip (our height=2501).
[SYNC] Block #2850 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=80/100]
[FORK] Block h=2851 bid=48f548c1dd526453 does not extend tip (our height=2501).
[ORPHAN] Block h=2851 stored (parent 30122ce5ba3d4aac unknown). 10 orphans total.
[FORK] Block h=2852 bid=44f8098489726ebb does not extend tip (our height=2501).
[SYNC] Block #2852 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=90/100]
[FORK] Block h=2853 bid=a0f141e4594ba906 does not extend tip (our height=2501).
[ORPHAN] Block h=2853 stored (parent 44f8098489726ebb unknown). 11 orphans total.
[FORK] Block h=2854 bid=d9c415f92a56e30c does not extend tip (our height=2501).
[SYNC] Block #2854 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] BANNED seed.sostcore.com:19333: invalid block (24h)
[P2P] Peer disconnected: seed.sostcore.com:19333
root@srv1561018:~/sost-core/build# pkill -9 sost-node
root@srv1561018:~/sost-core/build# rm -rf ~/.sost
[1]+  Killed                  nohup ./sost-node --genesis genesis_block.json --connect seed.sostcore.com:19333 --rpc-user rizki --rpc-pass sost_jaya_selalu --profile mainnet > node.log 2>&1
root@srv1561018:~/sost-core/build# rm -f chain.json
root@srv1561018:~/sost-core/build# rm -rf blocks utxo
root@srv1561018:~/sost-core/build# cd ~/sost-core
root@srv1561018:~/sost-core# git pull
Already up to date.
root@srv1561018:~/sost-core# cd build
root@srv1561018:~/sost-core/build# cmake .. -DCMAKE_BUILD_TYPE=Release
nproc) sost-node-- Configuring done (0.0s)
-- Generating done (0.1s)
-- Build files have been written to: /root/sost-core/build
root@srv1561018:~/sost-core/build# make -j$(nproc) sost-node
[ 93%] Built target sost-core
[100%] Built target sost-node
root@srv1561018:~/sost-core/build# nohup ./sost-node --genesis genesis_block.json \
>   --connect seed.sostcore.com:19333 \
>   --rpc-user rizki --rpc-pass sost_jaya_selalu \
>   --profile mainnet > node.log 2>&1 &
[1] 21754
root@srv1561018:~/sost-core/build# tail -n 20 node.log
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3273
root@srv1561018:~/sost-core/build#

[Neob1844]

  Hi Rizki,

  I found the issue. Your build cache is stale — make did not
  recompile the node with the latest fixes because the .o files
  were already cached.

  IMPORTANT: Please run a CLEAN rebuild:

     cd ~/sost-core/build
     MAKE CLEAN           <-- THIS IS THE KEY STEP
     cmake .. -DCMAKE_BUILD_TYPE=Release
     make -j$(nproc) sost-node

     rm -f chain.json
     rm -rf blocks utxo ~/.sost

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

  WITHOUT "make clean", make thinks nothing changed and skips
  recompilation. The P2P and fast-sync fixes are in the source
  code on GitHub right now, but they were NOT compiled into
  your current binary.

  Let me know if this resolves it.

And to everyone testing — I want to say this clearly:

SOST is a genuinely different protocol. Not a fork, not a
parameter tweak. That means the edge cases are real and the
fixes matter. Each of these bugs, small as they look in a log,
can silently break the sync path for every future node.

There is no middle ground here: either the bootstrap works
reliably for everyone, everywhere, or it doesn't ship.

Your reports are not just helpful — they are the reason this
protocol has a chance of being what it is designed to be.

[Rizki Maryanto]

root@srv1495092:~/sost-core/build# cp ../genesis_block.json .
root@srv1495092:~/sost-core/build#
root@srv1495092:~/sost-core/build# NEW_USER=$(openssl rand -hex 10)
 rand -hex 20)
echo "RPC USER: $NEW_USER"
echo "RPC PASS: $NEW_PASS"root@srv1495092:~/sost-core/build# NEW_PASS=$(openssl rand -hex 20)
root@srv1495092:~/sost-core/build# echo "RPC USER: $NEW_USER"
RPC USER: 1ebb39d1e42cb5c17dae
root@srv1495092:~/sost-core/build# echo "RPC PASS: $NEW_PASS"
RPC PASS: 6f13511b879839471bbbcc1b79d5869577d63dcc
root@srv1495092:~/sost-core/build# nohup ./sost-node --genesis genesis_block.json \
>   --connect seed.sostcore.com:19333 \
>   --rpc-user 1ebb39d1e42cb5c17dae --rpc-pass 6f13511b879839471bbbcc1b79d5869577d63dcc \
>   --profile mainnet > node.log 2>&1 &
[1] 88120
root@srv1495092:~/sost-core/build# tail -f node.log
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3276

[Neob1844]

I may be wrong, but looking at your log it seems you skipped
the CLEAN rebuild step. Your log shows you went straight to
starting the node without recompiling.

Please do this EXACTLY in order:

1. STOP the node first:
   pkill -9 sost-node

2. CLEAN rebuild:
   cd ~/sost-core/build
   make clean
   cmake .. -DCMAKE_BUILD_TYPE=Release
   make -j$(nproc) sost-node
   cp ../genesis_block.json .

3. DELETE all old data:
   rm -f chain.json
   rm -rf blocks utxo ~/.sost

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

The critical step is "make clean" in step 2. Without it,
your binary does not contain today's fixes and the sync
loop will repeat forever.

[Rizki Maryanto]

Hi Neob1844,

Good news: The make clean worked! My node successfully synced from the beginning and accepted blocks up to 2500.

The Problem: Immediately after block 2500, the node enters an infinite request loop for the next batch:
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280

The seed server acknowledges the batch is done up to 2500, but it seems it's not delivering the data for 2501+. Since I am now on a clean build with your latest P2P fixes, and my node is clearly active and healthy up to 2500, it seems the seed might be failing to serve the post-2500 range to peers currently at that height.

Here is the log showing the successful sync to 2500 and the subsequent stall:

[BLOCK] fast-sync height=2490 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2490 accepted: eb7cd5c99fa08a1b (txs=1, fees=0, UTXOs=7452, chainwork=0x4a8315)
[P2P] Broadcasting block #2490 to 1 peers
[SYNC] Received block #2490 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2491: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2491 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2491 accepted: 054b397ef9809295 (txs=1, fees=0, UTXOs=7455, chainwork=0x4a8c7c)
[P2P] Broadcasting block #2491 to 1 peers
[SYNC] Received block #2491 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2492: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2492 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2492 accepted: 1244d86dd0f7c15e (txs=1, fees=0, UTXOs=7458, chainwork=0x4a953d)
[P2P] Broadcasting block #2492 to 1 peers
[SYNC] Received block #2492 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2493: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2493 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2493 accepted: 5d8e7c1d72b00f9c (txs=1, fees=0, UTXOs=7461, chainwork=0x4a9dfa)
[P2P] Broadcasting block #2493 to 1 peers
[SYNC] Received block #2493 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2494: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2494 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2494 accepted: ff72d95a243ed861 (txs=1, fees=0, UTXOs=7464, chainwork=0x4aa632)
[P2P] Broadcasting block #2494 to 1 peers
[SYNC] Received block #2494 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2495: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2495 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2495 accepted: edaf1964fabd02d7 (txs=1, fees=0, UTXOs=7467, chainwork=0x4aaea2)
[P2P] Broadcasting block #2495 to 1 peers
[SYNC] Received block #2495 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2496: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2496 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2496 accepted: 55c41a17c3023ec6 (txs=1, fees=0, UTXOs=7470, chainwork=0x4ab715)
[P2P] Broadcasting block #2496 to 1 peers
[SYNC] Received block #2496 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2497: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2497 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2497 accepted: ea5d2624778edbff (txs=1, fees=0, UTXOs=7473, chainwork=0x4abfab)
[P2P] Broadcasting block #2497 to 1 peers
[SYNC] Received block #2497 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2498: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2498 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2498 accepted: 3924f2f97dae55d9 (txs=1, fees=0, UTXOs=7476, chainwork=0x4ac7bd)
[P2P] Broadcasting block #2498 to 1 peers
[SYNC] Received block #2498 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2499: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2499 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2499 accepted: 532853b3e48fe051 (txs=1, fees=0, UTXOs=7479, chainwork=0x4acff3)
[P2P] Broadcasting block #2499 to 1 peers
[SYNC] Received block #2499 from seed.sostcore.com:19333
[BLOCK] fast-sync height=2500: profile_index missing, trusted block (assuming B0)
[BLOCK] fast-sync height=2500 (trusted: checkpoint/assumevalid, CX proof skipped)
[BLOCK] Height 2500 accepted: 55d1314469265216 (txs=1, fees=0, UTXOs=7482, chainwork=0x4ad860)
[P2P] Broadcasting block #2500 to 1 peers
[SYNC] Received block #2500 from seed.sostcore.com:19333
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3280

[Neob1844]

https://sostcore.com/explorer-screenshot.png

[Neob1844]

Please hold on — fixes deploying now. Back shortly.

[Neob1844]

I found the actual root cause of the 2501 stall.

  The seed node was sending blocks using PLAINTEXT framing
  into your ENCRYPTED connection (X25519+ChaCha20). Your node
  received the raw bytes but couldn't decrypt them, so every
  block after 2500 was silently dropped.

  This explains why sync worked perfectly up to 2500 (first
  batch) but then entered an infinite request loop — the seed
  kept sending blocks, your node kept not receiving them.

  The fix is now live on GitHub and the seed has been
  recompiled and restarted.

  Please try again:

     cd ~/sost-core
     git pull
     cd build
     make clean
     cmake .. -DCMAKE_BUILD_TYPE=Release
     make -j$(nproc) sost-node
     cp ../genesis_block.json .

     rm -f chain.json
     rm -rf ~/.sost

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

  You should now sync the full chain without any stall.
  Let me know the result.

[Neob1844]

Hi all,

Quick technical update.

I believe I have now identified the most likely root cause of the latest sync stall, but I do not want to claim this is fully resolved until it is confirmed by external testers.

The issue appears to have been a P2P transport / framing mismatch on the seed side: after the initial trusted sync range, some blocks were being sent in a way that did not match the connection mode expected by the receiving node. In practice, this could cause blocks to be silently dropped or the sync process to enter a request loop, even though the node itself remained running.

This would explain the pattern some testers reported:

sync progressing correctly through the trusted range,
then stalling or looping on later batches,
or failing differently depending on latency, packet loss, and connection state.

I have now deployed a fix for that path and restarted the seed with the updated build.

However, I want to be precise and honest here:

I am not marking this issue as fully solved yet.
At this point, the correct status is:

candidate fix deployed — awaiting independent confirmation

So if you are testing, please try again from a fully clean state:

cd ~/sost-core
git pull
cd build
make clean
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc) sost-node
cp ../genesis_block.json .

rm -f chain.json
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

Please wait for full sync before starting the miner.

If this now works from height 0 to tip on external machines, then I will consider this specific bootstrap issue materially resolved. If it still fails, please post the full log again and I will continue investigating immediately.

Thank you again to everyone testing.

[Rizki Maryanto]

Crucial Update: Tested on 4 Different Servers

Hi Neob1844,

I want to emphasize that I have now tested this on 4 entirely different servers (fresh VPS instances).

On every single one of them:

I performed a git pull and a make clean rebuild.

I started from a completely fresh data state.

Every server successfully synced from 0 to 2500 without a single error.

Every server is now hard-stuck at 2501, looping on the same request:
Requesting blocks 2501..3288

This confirms that the issue is not related to a specific machine, OS, or network provider. There is a consistent protocol or handshake failure that occurs exactly at the 2501 boundary across all external nodes.

Please check if there is a specific hardcoded rule or a mismatch in the "Encryption vs Plaintext" logic that specifically kicks in after the 2500-block batch is completed.

[Neob1844]

First of all, let me give a complete picture of where things stand.

  1. The seed node was sending blocks using PLAINTEXT framing
     inside ENCRYPTED P2P connections. After the initial batch
     (blocks 1-2500), the connection switches to encrypted mode,
     but the block-sending function was not aware of this. It kept
     pushing raw bytes that the receiving node could not decrypt.

  2. I rewrote p2p_send_block to be encryption-aware — it now
     checks whether the connection is encrypted and uses the
     correct framing path (commit 774cd83).

  3. I wrote a sync simulation script that connects to the seed
     and requests all blocks from height 0. The result:
     - 3288 blocks received in 2.7 seconds
     - Block #2501 received correctly
     - All blocks through #3288 received correctly
     However, this test ran in PLAINTEXT mode, not encrypted.

  4. I have just restarted the seed node to make absolutely sure
     it is running the latest binary with the encryption fix.

  Please try ONE MORE TIME on any of your servers:

     pkill -9 sost-node
     rm -f chain.json
     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

  If it still stalls at 2501, please also try with encryption
  explicitly disabled:

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

  If --p2p-enc off syncs fully but the default mode does not,
  that confirms the encrypted path still has a problem, and I
  will know exactly where to look.

  If BOTH modes fail, the issue is deeper than encryption framing
  and I will conduct a full line-by-line audit of the entire P2P
  sync pipeline — every parameter, every state transition, every
  edge case. That may take some time, but I will not stop until
  external nodes can sync reliably from zero to tip.

  This is not a project where I will paper over a bootstrap
  failure. If the sync does not work for real people on real
  machines, nothing else matters. Your 4-server
  test is the most valuable debugging data I have received so far.

[Rizki Maryanto]

Hi Neob1844,

Here are the final results from my 4-server test:

DEFAULT MODE (Encryption On): Still STUCK at 2501 in an infinite loop. Your encryption fix (commit 774cd83) did not resolve the issue for external nodes.

ENCRYPTION OFF (--p2p-enc off): This successfully bypassed the 2501 stall! The node synced rapidly from 2501 to 3226.

THE NEW WALL (3226): At height 3226, the sync failed again with massive validation errors:

Block #3228 failed validation — stopping sync

Block does not extend tip (our height=3226)

The node eventually BANNED the seed IP for "invalid blocks".

Conclusion:

Your P2P Encryption logic is definitely still failing to frame/decrypt batches correctly after the first 2500 blocks.

Even in plaintext, there is a Consensus/Validation mismatch starting at height 3226. It looks like the "Tip" on the seed node is following a different rule than the current binary build.

Please investigate the transition at 2501 (for encryption) and 3226 (for consensus).