Parano1d ① Proof-native Layer 1 ordered by PoW

[IgnotusNemo]

Parano1d mainnet is live!

Mainnet activated exactly at 08:00 UTC.

The first block was accepted at 08:00:10 UTC. Block production is running normally.
You can now start v1.0.0 and enable mining normally.

Download Parano1d v1.0.0

No there is no peers your peers do not listenp2p and the connection is 0

45.138.26.80:9400
103.109.13.158:30637
Those two works and run your are not running and that is the truth or they do not allow connections

Give the seeds so we can add them to config or with flags and people should add own ip:port here too so we can build up network

The seed firewalls were incorrectly restricting inbound P2P connections.
TCP port 9400 is now publicly open on all five seed nodes.
Please restart the client.

[IgnotusNemo]

Give the seeds so we can add them to config or with flags and people should add own ip:port here too so we can build up network

The GUI already contains these DNS seeds, so normally nothing needs to be added manually.

For a manual fallback, press F7 → Network → Custom Seeds and add one address per line:

seed1.noid.network:9400
seed2.noid.network:9400
seed3.noid.network:9400
seed4.noid.network:9400
seed5.noid.network:9400


Apply the settings and let the private node restart.

Anyone running a publicly reachable node can keep P2P Listen at 0.0.0.0:9400 and allow inbound TCP 9400. Public nodes will then be discovered automatically through Kademlia.

[IgnotusNemo]

Network status

The network is live and public connections working normally
5 public seed nodes online
39-48 connected peers per seed
Current height: approximately 130
New blocks continue to arrive
No consensus, database or memory errors detected
Several independent miners are already active. Short competing tips are being resolved by cumulative-work fork choice as designed

[paulmbcufc]

I currently have 5 peers but mining won't start because I need "2 authenticated peers". How to get?

[Arttemkaaa]

Network status

The network is live and public connections working normally
5 public seed nodes online
39-48 connected peers per seed
Current height: approximately 130
New blocks continue to arrive
No consensus, database or memory errors detected
Several independent miners are already active. Short competing tips are being resolved by cumulative-work fork choice as designed

It seems like everything is finally working properly 👍


Or am I in a fork again?

[Sparks60]

mine has 58 peers height 226, but says needs two authenticated peers to start mining?

[paulmbcufc]

GUI wallet:

HEIGHT 0

Doesn't seem right ??

[chn520]

no way to mine,bye

[caijh369]

The block height is always 0—how to resolve this?

[paulmbcufc]

The block height is always 0—how to resolve this?

Same for me

[Arttemkaaa]

Network status

The network is live and public connections working normally
5 public seed nodes online
39-48 connected peers per seed
Current height: approximately 130
New blocks continue to arrive
No consensus, database or memory errors detected
Several independent miners are already active. Short competing tips are being resolved by cumulative-work fork choice as designed

It seems like everything is finally working properly 👍


Or am I in a fork again?

It seems everything is working. I did it this way:

stop node

# Clean resynchronization
./parano1d --purge-state

Wait until you see something like: snapshot install completed

Then press Ctrl+C and start mining:

./parano1d --miner --cpu-threads 32 \
  --seed seed1.noid.network:9400 \
  --seed seed2.noid.network:9400 \
  --seed seed3.noid.network:9400 \
  --seed seed4.noid.network:9400 \
  --seed seed5.noid.network:9400

[IgnotusNemo]

Update: the network is recovered.

The problems seen on the mainnet were in connectivity and synchronization, not in consensus, block validation, the proof system or the execution engine. Nodes with the required data consistently validate the same blocks and select the same chain by cumulative work.

The remaining v1.0.0 bug affects nodes that miss block gossip and fall too far behind on a losing fork. Their snapshot recovery can become anchored to the old local branch and stop progressing.
A patch is being prepared to make this recovery automatic.

All five seeds are now synchronized on the same chain, publicly reachable and connected to approximately 55-62 peers each. A clean external client synchronized in about 10 seconds.
Mainnet will not restart from genesis. The current chain and its blocks are valid.

If your client is advancing, do nothing.

If it is stuck, close it and manually remove only the chain database and snapshot folders, not the wallet files. then reopen v1.0.0.

Open the data directory:

Linux/macOS: ~/.parano1d/data

Windows: %USERPROFILE%\.parano1d\data

Delete only:

mdbx.dat
mdbx.lck
snapshot-staging
snapshot-header-staging
snapshot-exports
peers.json


Keep these files:

wallet.key
wallet.meta
wallet.history
wallet.receipts
p2p_identity.key
history-step-cache
parano1d-gui.toml

Then start Parano1d again. It will rebuild the chain database and resynchronize without changing your wallet.


CLI users can instead run:
./parano1d --purge-state
This clears only the chain state and preserves the wallet and P2P identity.

[Arttemkaaa]

Update: the network is recovered.

The problems seen on the final mainnet were in connectivity and synchronization, not in consensus, block validation, the proof system or the execution engine. Nodes with the required data consistently validate the same blocks and select the same chain by cumulative work.

The remaining v1.0.0 bug affects nodes that miss block gossip and fall too far behind on a losing fork. Their snapshot recovery can become anchored to the old local branch and stop progressing.
All five seeds are now synchronized on the same chain, publicly reachable and connected to approximately 55-62 peers each. A clean external client synchronized in about 10 seconds.

Mainnet will not restart from genesis. The current chain and its blocks are valid.

If your client is advancing, do nothing. If it is stuck, close it and manually remove only the chain database and snapshot folders, not the wallet files. then reopen v1.0.0.

A patch is being prepared to make this recovery automatic.

Is there an explorer where we can check the block height?

[chn520]

relaunch  again

[IgnotusNemo]

Is there an explorer where we can check the block height?

there will be no centralized web explorer. old transaction data is pruned by design, payments are proven by receipts, and Scope is built into the GUI to inspect the current chain directly from your own node.

for daemon use parano1d-cli

[caijh369]

Update: the network is recovered.

The problems seen on the mainnet were in connectivity and synchronization, not in consensus, block validation, the proof system or the execution engine. Nodes with the required data consistently validate the same blocks and select the same chain by cumulative work.

The remaining v1.0.0 bug affects nodes that miss block gossip and fall too far behind on a losing fork. Their snapshot recovery can become anchored to the old local branch and stop progressing.
A patch is being prepared to make this recovery automatic.

All five seeds are now synchronized on the same chain, publicly reachable and connected to approximately 55-62 peers each. A clean external client synchronized in about 10 seconds.
Mainnet will not restart from genesis. The current chain and its blocks are valid.

If your client is advancing, do nothing.

If it is stuck, close it and manually remove only the chain database and snapshot folders, not the wallet files. then reopen v1.0.0.

Open the data directory:

Linux/macOS: ~/.parano1d/data

Windows: %USERPROFILE%\.parano1d\data

Delete only:

mdbx.dat
mdbx.lck
snapshot-staging
snapshot-header-staging
snapshot-exports
peers.json


Keep these files:

wallet.key
wallet.meta
wallet.history
wallet.receipts
p2p_identity.key
history-step-cache
parano1d-gui.toml

Then start Parano1d again. It will rebuild the chain database and resynchronize without changing your wallet.


CLI users can instead run:
./parano1d --purge-state
This clears only the chain state and preserves the wallet and P2P identity.

There are 5 nodes displayed, but the block height remains 0 and synchronization has not started yet.

[Hashrateoptions]

Each time I mine a block it gets reorg p2p is really weak.
All same mined a block then reorg
I sugggest to not waste time for it my server says height 424 my gui wallet have 6 peers and it is on 411 height where I mine now blocks so even with peers all is crap and forking all time waste of time before there is no right p2p it is really an testnet

⚠ No UTXOs found on the active address.
       Run 'parano1d-cli scan' to reload the active address; use 'address --list' to switch accounts.
(main) root@C.47617907:/workspace$ ./parano1d-cli  balance
Wallet balance (active address)
  Balance: 135.000000 NOID (135000000 μNOID)  (3 UTXOs)
(main) root@C.47617907:/workspace$ ./parano1d-cli  balance
Wallet balance (active address)
  Balance: 180.000000 NOID (180000000 μNOID)  (4 UTXOs)
(main) root@C.47617907:/workspace$ ./parano1d-cli  balance
Wallet balance (active address)
  Balance: 360.000000 NOID (360000000 μNOID)  (8 UTXOs)
(main) root@C.47617907:/workspace$ screen -rd node
[detached from 3647.node]
(main) root@C.47617907:/workspace$ ./parano1d-cli  balance
Wallet balance (active address)
  Balance: 0.000000 NOID (0 μNOID)  (0 UTXOs)


There is a leak in p2p communication so you can mine mine block or 2 but network is already ahead so do not tell me it is prod ready because p2p is really bad

[IgnotusNemo]

Each time I mine a block it gets reorg p2p is really weak.
All same mined a block then reorg
I sugggest to not waste time for it my server says height 424 my gui wallet have 6 peers and it is on 411 height where I mine now blocks so even with peers all is crap and forking all time waste of time before there is no right p2p it is really an testnet

You are right about the behavior you are seeing. A client at height 411 while the network is at 424 must not mine, it builds on a stale parent, so those blocks are correctly orphaned. 
I reproduced the cause. After the initial peer quorum, v1.0.0 can stop making authenticated tip checks even though the peer counter still looks healthy. Fork choice is rejecting the stale branch correctly, but the mining gate should have stopped mining on it. 
Please stop mining with v1.0.0 for now. I am testing a patch that keeps tip synchronization alive and expires the mining authorization if peers have not recently confirmed the current tip.

[Hashrateoptions]

Each time I mine a block it gets reorg p2p is really weak.
All same mined a block then reorg
I sugggest to not waste time for it my server says height 424 my gui wallet have 6 peers and it is on 411 height where I mine now blocks so even with peers all is crap and forking all time waste of time before there is no right p2p it is really an testnet

You are right about the behavior you are seeing. A client at height 411 while the network is at 424 must not mine, it builds on a stale parent, so those blocks are correctly orphaned. 
I reproduced the cause. After the initial peer quorum, v1.0.0 can stop making authenticated tip checks even though the peer counter still looks healthy. Fork choice is rejecting the stale branch correctly, but the mining gate should have stopped mining on it. 
Please stop mining with v1.0.0 for now. I am testing a patch that keeps tip synchronization alive and expires the mining authorization if peers have not recently confirmed the current tip.

Yes like I said it is testnet you should make all ready then come with ready project in my opinion it is bad calling it mainnet and restarting after few hours block time should be like at least one minute for safety and limit reorgs or make really good p2p also i can agree on seeds but seems all other peers are not discovered maybe few of them and peers should be able to communicate better. In my opinion like I said I would call it testnet.

[IgnotusNemo]

I want to make one thing clear, every issue seen today is in P2P sync and liveness. Consensus, state transitions, proofs, PoW and cryptography are working as intended.
Some nodes stay connected but stop updating their authenticated tip. They then mine valid blocks on an old parent, and consensus correctly rejects or reorganizes those stale branches.

The networking behavior is not acceptable and I am fixing it. But the failure is in synchronization, not in the protocol or cryptography.