SOST Synchronization Update — P2P Sync Fixed, Encryption Working, Bootstrap Still Available
The historical P2P synchronization issues reported earlier have now been identified and resolved.
A fresh node has been synchronized successfully from zero state to tip over direct P2P in repeated clean runs. Bootstrap HTTPS was also re-tested successfully and remains available as an optional fast-start / fallback method.
P2P encryption has now also been validated in all practical modes:
- plaintext on both sides
- encrypted client with plaintext fallback to a non-encrypted peer
- encrypted end-to-end on both sides
What was fixed:
The sync stall affecting nodes after block ~2500 was caused by multiple issues in the P2P transport layer:
- a rate limiter that silently dropped blocks during initial sync
- blocking I/O in the message loop that prevented reliable stall recovery
- TCP flow-control deadlocks when sending oversized batches
- missing EAGAIN handling for non-blocking socket writes
An additional issue affected encrypted/plaintext interoperability:
- when an encrypted client connected to a plaintext peer, the client could discard the peer’s VERSION message while expecting EKEY, preventing sync from starting
- plaintext peers could also penalize EKEY unnecessarily
These were networking / transport bugs only.
No consensus rules were changed.
No block validation rules were changed.
No emission logic was changed.
No chain history was changed.
No hard fork or regenesis was required.
Validated methods:
1. Direct P2P sync (plaintext)
A fresh node can now sync the full chain from genesis to tip over direct P2P. This was validated in repeated clean runs from zero state to tip.
2. Bootstrap chain import (fast start)
A node can also download the HTTPS bootstrap chain snapshot and become operational almost immediately. This remains available as an optional fast-start / fallback path.
3. Encrypted P2P sync
Encrypted P2P transport is now functional.
- ON/OFF fallback works correctly
- ON/ON end-to-end encrypted sync also completes successfully
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 useful when a node operator wants the fastest possible initialization
Build from latest source:
git pull origin main
cd build
make clean
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc) sost-node
cp ../genesis_block.json .
Direct P2P sync (fastest historical sync):
./sost-node --genesis genesis_block.json \
--connect seed.sostcore.com:19333 \
--rpc-user YOUR_USER --rpc-pass YOUR_PASS \
--profile mainnet --p2p-enc off
Bootstrap fast-start:
curl -o chain.json
https://sostcore.com/bootstrap-chain.jsonrm -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
Encrypted P2P sync:
./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 sync:
curl -s --user YOUR_USER:YOUR_PASS \
-d '{"method":"getblockcount","params":[],"id":1}' \
http://127.0.0.1:YOUR_RPC_PORT
Start mining after full sync:
./sost-miner --address YOUR_SOST_ADDRESS \
--rpc 127.0.0.1:18232 --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
--blocks 999999 --profile mainnet
Bootstrap snapshot:
https://sostcore.com/bootstrap-chain.jsonSeed node:
seed.sostcore.com:19333
Explorer:
https://sostcore.com/sost-explorer.htmlSummary:
- Direct P2P sync: working
- Bootstrap import: working
- Encrypted P2P: working
- Plaintext historical sync remains the fastest mode
- No consensus changes
- No hard fork
- No regenesis
Thank you to everyone who reported sync issues during testing. Those reports directly helped isolate and fix the networking bugs.
Quick miner update:
if you're mining and see repeated "NODE REJECTED BLOCK — will retry same height", please update:
# 1. Stop your miner (Ctrl+C or):
pkill -9 -f sost-miner
# 2. Pull and rebuild:
cd ~/sost-core
git pull origin main
cd build
make clean
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc) sost-miner
# 3. Restart your miner:
./sost-miner --address YOUR_SOST_ADDRESS \
--rpc 127.0.0.1:18232 \
--rpc-user YOUR_USER \
--rpc-pass YOUR_PASS \
--blocks 999999 --profile mainnet
No node restart needed — only the miner binary changed.
This fixes the miner to automatically advance to the current tip when another miner wins a block first, instead of retrying the same height indefinitely.
Miner update — competitive mining fix
A miner behavior bug has been identified and fixed that only
appears when two or more miners are active simultaneously.
What happened:
When a miner found a valid block but another miner had already
submitted a block at the same height, the node correctly rejected
the late submission. However, the miner did not advance to the
next height — it kept retrying the same rejected block indefinitely.
This bug was invisible during solo mining. It only became apparent
now that a second miner joined the network.
What was fixed:
The miner now queries the node after a rejection. If the chain has
advanced, the miner automatically moves to the next height and
continues. No manual intervention needed.
To update and restart:
# 1. Stop your miner (Ctrl+C or):
pkill -9 -f sost-miner
# 2. Pull and rebuild:
cd ~/sost-core
git pull origin main
cd build
make clean
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc) sost-miner
# 3. Restart your miner:
./sost-miner --address YOUR_SOST_ADDRESS \
--rpc 127.0.0.1:18232 \
--rpc-user YOUR_USER \
--rpc-pass YOUR_PASS \
--blocks 999999 --profile mainnet
No node restart needed — only the miner binary changed.
How SOST handles two miners finding a block at the same height:
The node and chain consensus already handle this correctly. No changes were needed here — this is how it has always worked:
- Miner A submits first, Miner B submits second (same height): The node accepts A. B is stored as a fork candidate. A remains the active tip. This is the "first seen wins" rule.
- Miner B's block has more cumulative proof-of-work: The node automatically reorganizes the chain to follow B's block instead. The best chain always wins, regardless of arrival order.
- Both blocks have equal cumulative work: First seen wins. No reorganization. This is the same rule Bitcoin uses.
- The miner whose block was rejected: With today's fix, the miner detects the rejection, queries the node for the current tip, and immediately starts mining the next block. No manual restart needed.
In short: the chain selects the best valid chain by cumulative work, and miners now recover automatically when they lose a block to a competitor.
▎ Infrastructure update — miner improvements
▎ Several miner fixes have been pushed in the last 24h:
▎ - Miner now auto-advances when another miner wins a block (no more infinite REJECTED loop)
▎ - Miner correctly syncs tip hash and difficulty after reconnecting to the node
▎ - Explorer now shows accurate mining status
▎ If your miner gets stuck or shows repeated REJECTED:
▎ pkill -9 -f sost-miner
▎ cd ~/sost-core
▎ git pull origin main
▎ cd build
▎ make clean
▎ cmake .. -DCMAKE_BUILD_TYPE=Release
▎ make -j$(nproc) sost-miner
▎ Then download fresh chain state and restart:
▎ scp YOUR_NODE:/path/to/chain.json ./chain.json
▎ ./sost-miner --address YOUR_SOST_ADDRESS \
▎ --rpc 127.0.0.1:18232 \
▎ --rpc-user YOUR_USER --rpc-pass YOUR_PASS \
▎ --blocks 999999 --profile mainnet
▎ The infrastructure is under continuous improvement during this pre-market testing phase. If you experience any issue, always start by pulling the latest code and
rebuilding. Report any problems here with your full log.
