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

[Neob1844]

 Quick status update.

I am currently running an isolated sync test from my own machine,
simulating what a new peer does when connecting to the seed from zero.

So far, the sync reaches block ~2392 successfully. At block #2393,
the peer accepts the block in trusted header-only mode
(`tx data missing — header-only accept`) and the connection then
drops immediately afterward.

This strongly suggests that the remaining issue is still in the
bootstrap / GETB delivery path — most likely at the transport,
framing, or block-serving layer — rather than in the mined chain
itself.

At this point, I do not want to overstate the diagnosis:
the current evidence points to incomplete or inconsistent block
delivery during sync, but I am still auditing the full path before
claiming the exact root cause.

I am now reviewing the block send/receive pipeline around that
boundary to determine why a trusted block can arrive without full
transaction payload and why the peer disconnects immediately after.

I will post again when I have either:
1. a confirmed root cause, or
2. a fix ready for external retesting.

[Rizki Maryanto]

ok, i`ll wait for further news. i hope it goes smoothly.

[Neob1844]

Quick status update.

An isolated sync test has been executed from a clean external machine, simulating exactly how a new peer connects to the seed from scratch.

Current verified status:

* full bootstrap sync from height 0 to tip completes successfully in plaintext P2P mode
* the node reaches height 3300 and completes synchronization normally
* the previous bootstrap failure around height 3226 is resolved on the practical sync path
* the remaining unresolved issue is isolated to the encrypted P2P transport path, which still stalls after the first trusted batch

Transport status:

The default P2P transport has been temporarily switched to plaintext while the encrypted X25519+ChaCha20 sync path remains under investigation.

This decision was made because a broken default transport mode is operationally worse than a stable plaintext bootstrap path.

What this change does NOT affect:

* consensus rules
* block validity
* chain selection
* PoW verification
* cASERT difficulty validation
* wallet key custody

Private keys do not propagate over the P2P network. Transactions remain locally signed. The temporary difference is at the transport/privacy layer, not at the consensus layer.

What this change does affect:

* transport-level privacy only

A network observer may have greater visibility into block and transaction relay patterns while plaintext transport is the active recommended mode. This is a transport-layer tradeoff, not a chain-integrity issue.

Historical context:

Bitcoin operated for most of its existence without mandatory encrypted P2P transport, at least until 2023. Encrypted transport is a network-layer hardening feature, not a prerequisite for basic blockchain validity or successful initial synchronization.

Current operational conclusion:

Reliable bootstrap from zero to tip takes priority over optional encrypted transport during the present pre-market stage.

Recommended sync instructions:

```bash
git pull origin main
cd build
make clean
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc) sost-node
cp ../genesis_block.json .

pkill -9 sost-node || true
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 \
  --p2p-enc off
```

Plaintext P2P transport is currently the recommended and verified bootstrap path. The explicit `--p2p-enc off` flag is included here for clarity and to avoid ambiguity when testing with older binaries.

Encrypted P2P transport will be re-enabled only after the sync path has been fully audited and externally re-verified under clean bootstrap conditions.


Operational note:

Founder mining is currently paused in order to acknowledge the external testing effort that helped identify synchronization and related issues, and also to facilitate ConvergenceX testing under cleaner network conditions.

The chain is currently approximately 110 blocks behind the expected height at the time of writing this post (block 3,300), as the developer’s miner has been paused during this diagnostic and troubleshooting phase. Mining is now ready to resume. Under the active cASERT V2 parameters — 24-hour half-life and a 12.5% per-block adjustment cap — this level of lag should not take excessive time to normalize, and the network is expected to converge progressively back toward alignment between expected block production and emitted blocks.

The current height can be checked on the official explorers: https://sostprotocol.com/sost-explorer.html and https://sostcore.com/sost-explorer.html

[Rizki Maryanto]

Hi Neob1844,

Encryption fix verified! Using --p2p-enc off works to establish the connection, but the Sync Logic is still broken.

My node is at height 2501. When it requests the next batch, your seed node is sending blocks starting from height 2858. There is a massive gap of 356 blocks (2502 to 2857) that the seed is not sending.

Because the blocks don't connect to my current tip (2501), my node identifies them as invalid forks and has BANNED your seed IP again:
[FORK] Block h=2858 ... does not extend tip (our height=2501)
[P2P] BANNED seed.sostcore.com:19333: invalid block (24h)

The seed is failing to deliver a continuous chain. Please check why the batching logic is skipping the range between 2502 and 2857.



[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[P2PDBG] DONE received from seed.sostcore.com:19333: our_height=2500, their_height=3300, blocks_size=2501
[SYNC] Batch done from seed.sostcore.com:19333. Requesting blocks 2501..3300
[FORK] Block h=2858 bid=13d8c40cd73a34ad does not extend tip (our height=2501).
[ORPHAN] Block h=2858 stored (parent eedcd5f83f338827 unknown). 1 orphans total.
[FORK] Block h=2859 bid=e1277f0b58070e45 does not extend tip (our height=2501).
[SYNC] Block #2859 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=2860 bid=0da52aef078471ec does not extend tip (our height=2501).
[ORPHAN] Block h=2860 stored (parent e1277f0b58070e45 unknown). 2 orphans total.
[FORK] Block h=2861 bid=813592591d527560 does not extend tip (our height=2501).
[SYNC] Block #2861 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=20/100]
[FORK] Block h=2862 bid=111bec12af8a8d5c does not extend tip (our height=2501).
[ORPHAN] Block h=2862 stored (parent 813592591d527560 unknown). 3 orphans total.
[FORK] Block h=2863 bid=ceab02a6e8feb16e does not extend tip (our height=2501).
[SYNC] Block #2863 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=30/100]
[FORK] Block h=2864 bid=653b1452772f2d50 does not extend tip (our height=2501).
[ORPHAN] Block h=2864 stored (parent ceab02a6e8feb16e unknown). 4 orphans total.
[FORK] Block h=2865 bid=bfaf056b01121306 does not extend tip (our height=2501).
[SYNC] Block #2865 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=40/100]
[FORK] Block h=2866 bid=29392a20a5fb73df does not extend tip (our height=2501).
[ORPHAN] Block h=2866 stored (parent bfaf056b01121306 unknown). 5 orphans total.
[FORK] Block h=2867 bid=0082ab3bd73a665e does not extend tip (our height=2501).
[SYNC] Block #2867 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=50/100]
[FORK] Block h=2868 bid=7a6606c459f8c124 does not extend tip (our height=2501).
[ORPHAN] Block h=2868 stored (parent 0082ab3bd73a665e unknown). 6 orphans total.
[FORK] Block h=2869 bid=e237934846232528 does not extend tip (our height=2501).
[SYNC] Block #2869 from seed.sostcore.com:19333 failed validation — stopping sync
[P2P] Misbehavior +10 (invalid block) from seed.sostcore.com:19333 [score=60/100]
[FORK] Block h=2870 bid=a88989e17d4372ac does not extend tip (our height=2501).
[ORPHAN] Block h=2870 stored (parent e237934846232528 unknown). 7 orphans total.
[FORK] Block h=2871 bid=72794888c088731a does not extend tip (our height=2501).
[SYNC] Block #2871 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=2872 bid=2a636266266136bd does not extend tip (our height=2501).
[ORPHAN] Block h=2872 stored (parent 72794888c088731a unknown). 8 orphans total.
[FORK] Block h=2873 bid=e17130e21d38c802 does not extend tip (our height=2501).
[SYNC] Block #2873 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=2874 bid=f39e29a11aa94d02 does not extend tip (our height=2501).
[ORPHAN] Block h=2874 stored (parent e17130e21d38c802 unknown). 9 orphans total.
[FORK] Block h=2875 bid=404e98061801c4fe does not extend tip (our height=2501).
[SYNC] Block #2875 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=2876 bid=ae18a0b4850d6f08 does not extend tip (our height=2501).
[ORPHAN] Block h=2876 stored (parent 404e98061801c4fe unknown). 10 orphans total.
[FORK] Block h=2877 bid=22364bad803a38dc does not extend tip (our height=2501).
[SYNC] Block #2877 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

[Neob1844]

Can you confirm — did you run the sync with --p2p-enc on or --p2p-enc off?

  The encrypted mode has a known bug. Did you try in plaintext mode with a completely clean state?

  git pull origin main
  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 \
    --p2p-enc off

[Neob1844]

Technical update:

The developer miner was restarted at 21:35 UTC to resume live ConvergenceX testing and to observe recovery behavior under current cASERT conditions.

Current network state at the time of capture:
- Actual chain height: 3300
- Expected height: 3476
- Chain lag: 176 blocks behind
- Active anti-stall profile: E4
- Wall-clock elapsed since genesis: 24d 3h 29m 42s
- Chain-time elapsed: 23d 21h 37m 17s
- Time offset: -5h 51m 25s
- Current mining target: 10m 00s average block interval
- Current block in progress: #3301
- Current displayed difficulty: 9.845 bits
- Current block elapsed at capture: 1423m 23s

The present schedule deficit is approximately 29h 20m in block-time terms (176 × 10 minutes). Recovery speed back toward the expected schedule will depend on effective live hashrate, but the network is now being observed directly to measure how quickly block production converges again toward the 10-minute target average.

The current progress can be checked on the official explorers:
https://sostcore.com/sost-explorer.html
https://sostprotocol.com/sost-explorer.html

[Neob1844]

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.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

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.json

Seed node:
seed.sostcore.com:19333

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

Summary:
- 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.

[Neob1844]

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.

[Neob1844]

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.

[Neob1844]

  ▎ 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.

[Rizki Maryanto]

root@srv1561018:~/sost-core/build# tail -f node.log
PoPC registry: 0 active commitments
Wallet rescan: 0 UTXOs registered (balance: 0.00000000 SOST)
UTXO set: 11166 entries | Mempool: 0 txs

[RPC] Listening on 127.0.0.1:18232 — 37 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: version OK, their height=3728
[BLOCK] CX Transcript V2 verified
[BLOCK] Height 3729 accepted: 515cc0231767b310 (txs=1, fees=0, UTXOs=11169, chainwork=0x7528e0)
[P2P] Broadcasting block #3729 to 1 peers
[BLOCK] CX Transcript V2 verified
[BLOCK] Height 3730 accepted: 0c28d4e4d5a9a118 (txs=1, fees=0, UTXOs=11172, chainwork=0x753ece)
[P2P] Broadcasting block #3730 to 1 peers
[BLOCK] CX Transcript V2 verified
[BLOCK] Height 3731 accepted: 9899dad01268d575 (txs=1, fees=0, UTXOs=11175, chainwork=0x755553)
[P2P] Broadcasting block #3731 to 1 peers
[BLOCK] CX Transcript V2 verified
[BLOCK] Height 3732 accepted: ea3a83e1986547e1 (txs=1, fees=0, UTXOs=11178, chainwork=0x756c9a)
[P2P] Broadcasting block #3732 to 1 peers
[BLOCK] CX Transcript V2 verified
[BLOCK] Height 3733 accepted: d3f987956de0c1d7 (txs=1, fees=0, UTXOs=11181, chainwork=0x75845b)
[P2P] Broadcasting block #3733 to 1 peers
[BLOCK] CX Transcript V2 verified
[BLOCK] Height 3734 accepted: 6c188864ab968d9f (txs=1, fees=0, UTXOs=11184, chainwork=0x759cd8)
[P2P] Broadcasting block #3734 to 1 peers
[BLOCK] CX Transcript V2 verified
[BLOCK] Height 3735 accepted: 133e8d0ac5912a2c (txs=1, fees=0, UTXOs=11187, chainwork=0x75b5e2)
[P2P] Broadcasting block #3735 to 1 peers




miner:

Miner address: sost1cb12addd46c4389e3569a292cc394469951544f7
Profile: mainnet | Blocks: 999999 | RPC: 127.0.0.1:18232

Genesis: 6517916b98ab9f807272bf94f89297011dd5512ecea477bd9d692fbafe699f37

Chain loaded: 3742 blocks, height=3741
Continuing from height 3741, tip=b882025f5a15b2a4

[MINING] h=3742 diff=847226 sub=785100863 fees=0 merkle=6673adbe262f6f60 txs=1
[DIAG] Mining h=3742 prev=b882025f5a15b2a4 bitsQ=847226 (12.9276) profile: scale=1 k=5 margin=150 steps=6

[MINING] New block detected! Aborting mining of 3742
[MINING] Local bitsQ=845474, node says 847717 — using node difficulty
[MINING] h=3743 diff=847717 sub=785100863 fees=0 merkle=18e68690b5cbf00a txs=1
[DIAG] Mining h=3743 prev=679239b18ea99c03 bitsQ=847717 (12.9351) profile: scale=1 k=5 margin=150 steps=6

[MINING] New block detected! Aborting mining of 3743
[MINING] Local bitsQ=845976, node says 847448 — using node difficulty

[Rizki Maryanto]

Hi Neob,

Reporting in! I’ve successfully updated both the node and miner to the latest version. Here’s a quick update from my side:

Miner Update: The auto-advance feature is working perfectly. When a new block is detected by the node, the miner now correctly aborts the current nonce search and switches to the new height immediately. No more infinite REJECTED loops.

Memory Handling: For those with tight memory overhead during the ConvergenceX dataset loading, adding a dedicated Swap file works as a solid workaround for the std::bad_alloc crash. Once the dataset is mapped, the miner runs stable.

Current Status: Fully synced and mining at height 3740+. The RPC correctly syncs the tip hash and difficulty after a reconnect.

The infrastructure feels much more robust now. I'm excited to continue testing and securing the network! If there are any early tester rewards or coins for stress-testing, I'd be more than happy to help distribute or hold them.

My Wallet Address: sost1cb12addd46c4389e3569a292cc394469951544f7

Thanks for the hard work, Dev!

[Neob1844]

From what I can observe, Rizki, your node is fully synced and receiving live blocks. Your log shows that CX Transcript V2 verification is passing correctly for blocks 3729–3735.

The network now has 5 connected nodes and 3 active miners.

If you want to start mining, make sure to pull the latest miner code first; there have been several competitive mining fixes in the last 24 hours.

  ▎ cd ~/sost-core
  ▎ git pull origin main
  ▎ cd build
  ▎ make clean
  ▎ cmake .. -DCMAKE_BUILD_TYPE=Release
  ▎ make -j$(nproc) sost-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

[Neob1844]

Thank you for the report. Your note about using a dedicated swap file as a workaround for std::bad_alloc on lower-memory systems is a solid practical suggestion. For constrained environments, this appears to be a reasonable mitigation during ConvergenceX dataset loading, and I will consider adding it as an official recommendation in the miner setup documentation.

I will also send you a SOST transaction to your wallet, mainly to verify that on-chain transfers are functioning correctly under live network conditions.

[oswaldzc]

Thanks to Neob1844, happily mining now!

[Neob1844]

Good to hear, oswaldzc. Thanks for your feedback.

[Neob1844]

● cASERT Equalizer — Technical Reference

  SOST uses a unified per-block difficulty adjustment system called cASERT (cascading Absolutely Scheduled Exponential Rising Targets) with 17 dynamic profiles
  that change ConvergenceX mining parameters — not just the difficulty target, but the actual stability basin verification requirements.

  Control signal: U = 0.05·r + 0.40·lag + 0.15·I + 0.05·burst + 0.02·V
  Slew rate: maximum ±1 profile per block (gradual transitions only)
  Safety rule: if chain is behind schedule, profile is capped at B0 (never hardens when behind)
  Half-life: 24 hours | Max delta per block: 12.5%

  Easing Profiles (chain behind schedule — mining becomes easier)

  

Profile	H	Activation	Scale	K	Steps	Margin	Effect
E4	-4	>75 blocks behind	1	3	2	280	Maximum emergency easing
E3	-3	51-75 behind	1	3	3	240	Strong easing
E2	-2	21-50 behind	1	3	4	225	Moderate easing
E1	-1	6-20 behind	1	4	4	205	Mild easing

  Baseline

  

Profile	H	Activation	Scale	K	Steps	Margin	Effect
B0	0	±5 blocks of target	1	4	4	185	Standard difficulty

  Hardening Profiles (chain ahead of schedule — mining becomes harder)

  

Profile	H	Activation	Scale	K	Steps	Margin	Effect
H1	+1	6-20 ahead	1	4	5	170	Mild hardening
H2	+2	21-50 ahead	1	5	5	160	Moderate hardening
H3	+3	51-75 ahead	1	5	6	150	Strong hardening
H4	+4	>75 ahead	1	6	6	145	Heavy hardening
H5	+5	Sustained high hashrate	2	5	5	140	Scale 2 — larger perturbations
H6	+6	Sustained high hashrate	2	5	6	135	Scale 2
H7	+7	Sustained high hashrate	2	6	6	130	Scale 2
H8	+8	Sustained high hashrate	2	6	7	125	Scale 2
H9	+9	Sustained high hashrate	2	7	7	120	Maximum scale 2
H10	+10	Extreme sustained hashrate	3	6	7	115	Scale 3 — high difficulty
H11	+11	Extreme sustained hashrate	3	7	7	110	Scale 3
H12	+12	Extreme sustained hashrate	3	7	8	105	Maximum absolute difficulty

  Parameter meanings

  

• Scale — perturbation amplitude applied to the ConvergenceX stability basin. Scale 1 = standard, Scale 2 = double-sized perturbations, Scale 3 = triple.
    Higher scale makes it harder to find a stable solution.
• K — number of stability probes per hash attempt. More probes = more compute per attempt.
• Steps — gradient descent iterations per probe. More steps = deeper verification of stability basin.
• Margin — stability basin acceptance threshold. Lower margin = tighter requirement = harder to pass.
• Compute — approximate relative compute cost: K × Steps × Scale.

  Anti-stall recovery

  If no blocks are found for an extended period:
  

• First 2 hours: gradual decay from current profile toward B0
• Next 6 hours at B0: mandatory waiting period
• After 8 hours total: easing profiles activate at 30 minutes per level (E1 → E2 → E3 → E4)
• E4 (maximum easing) reached after approximately 10 hours without a block

  Current network behavior

  With the current network (3 active miners, ~7-8 min average block time), the equalizer oscillates between B0 and H2. Profiles H5-H12 are designed as future
  protection — they activate only under sustained high hashrate scenarios that would be expected when more miners join the network. The system scales automatically
  without requiring any protocol changes.

  Key difference from Bitcoin and Monero

  Bitcoin adjusts difficulty every 2,016 blocks (~2 weeks) using a single time delta. Monero adjusts every block using one EWMA signal. SOST adjusts every block using a
  full PID controller with 5 weighted signals and 17 profiles that modify not just the difficulty target but the actual ConvergenceX proof-of-work parameters. This makes
  SOST significantly more responsive to hashrate changes and more resistant to mining disruptions.

  Live cASERT status is visible on the explorer: sostcore.com/sost-explorer.html

  Copia y pega directamente en BTCTalk.

✻ Sautéed for 43s

❯ PERO AÑADE COMO FUNCIONAN LOS BITS TAMBIEN Y SI PUEDE SER LO MAS CORTO POSIBLE MEJOR, PERO TECNICO Y BIEN

● cASERT Equalizer + Difficulty — Technical Reference

  Difficulty encoding: SOST uses Q16.16 fixed-point format called bitsQ.
  

• bitsQ = raw integer stored in block header (e.g. 786457)
• bits_real = bitsQ ÷ 65536 (e.g. 786457 ÷ 65536 = 12.000)
• Higher bitsQ = harder to mine. Lower bitsQ = easier.
• Max change per block: 12.5% (hard cap). Half-life: 24 hours.
• Zero floating-point in consensus — all integer arithmetic.

  Equalizer: U = 0.05·r + 0.40·lag + 0.15·I + 0.05·burst + 0.02·V
  Slew rate: ±1 profile/block. Behind schedule → capped at B0 (never hardens when behind).

  

Profile	H	When	Scale	K	Steps	Margin
E4	-4	>75 behind	1	3	2	280
E3	-3	51-75 behind	1	3	3	240
E2	-2	21-50 behind	1	3	4	225
E1	-1	6-20 behind	1	4	4	205
B0	0	±5 of target	1	4	4	185
H1	+1	6-20 ahead	1	4	5	170
H2	+2	21-50 ahead	1	5	5	160
H3	+3	51-75 ahead	1	5	6	150
H4	+4	>75 ahead	1	6	6	145
H5-H9	+5 to +9	Sustained high hashrate	2	5-7	5-7	140-120
H10-H12	+10 to +12	Extreme sustained hashrate	3	6-7	7-8	115-105

  Parameters: Scale = perturbation size on stability basin. K = probes per attempt. Steps = gradient descent iterations. Margin = acceptance threshold (lower =
  harder). Profiles H5-H12 activate only under massive sustained hashrate — they are future-proofing, not currently reachable with 3 miners.

  Anti-stall: No blocks for 2h → decay to B0. No blocks for 8h+ → E1-E4 activate (30 min/level). E4 reached at ~10h.

  Live status: sostcore.com/sost-explorer.html / sostprotocol.com/sost-explorer.html

[Neob1844]

To @visibleplayer, @oswaldzc, @yoshikiazuma, and Rizki:

Your early reports helped identify and fix issues in P2P sync, rate limiting, checkpoints, and transport behavior.

I would like to send each of you a small SOST transaction to acknowledge your testing and to verify on-chain transfers under live conditions.

If interested, please share your wallet address (sost1...) here or by PM.

Thank you for your feedback.