Parano1d ① Proof-native Layer 1 ordered by PoW

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

[Hashrateoptions]

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.

Ok so mined coins stays ? but in basics You need to add some extra feature to sync there is a need to have some resources free for sync and other stuff if someone will force to use all cores threads his node become a bad actor and I understand that orphans can happen thing is my node mine and orphan mine and orphan all arround so it is not normal as if there is some heavy load on main miners who produce most of blocks and there is a leak of communication between nodes it become like it is like for now nodes are ok and sync perfect the only issue is mining behaviour.

can anyone tell average height ?

My server says 5 peers my local gui says 3 but network heights are same. I just do not run my local gui miner as seems my internet is bad and can cause problems server seems works ok maybe you should give some specs on minimum requiments

[IgnotusNemo]

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.

It is what it is.
A one-minute block time would only hide this bug. Authenticated tip polling stops completely, so the node would remain stale anyway. Peer discovery works, sync liveness does not.
I am fixing that layer now and will release the patch.