Parano1d ① Proof-native Layer 1 ordered by PoW

[minerminer3456]

no sync

[garmin]

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

You are right about mining. It must not starve networking, and a node must stop mining if its tip is no longer confirmed as current. Both fixes are in the patch I am testing now.

Current status: best observed height is 528. The three active seeds are at 523-528 with 69-5 peers each.
Please keep mining disabled on any client that is not at the current tip.

Ok does your nodes still are on ?

Does that patch will come soon ?

yes

LAUNCH HUGE FAIL
2ND LAUNCH HUGE FAIL

KEEP IT. I will mine something else. Thanks anyway

[vostokzyf]

垃圾的东西 就不要发出来了/Do not post useless garbage.

[Sparks60]

to be fair, this 3rd try i do think needs reset to zero and start all over, if there is to be a 3rd try, guessing the dev had to just stop and get some sleep to take a much needed break, as we not had a update in a while.

[Hashrateoptions]

to be fair, this 3rd try i do think needs reset to zero and start all over, if there is to be a 3rd try, guessing the dev had to just stop and get some sleep to take a much needed break, as we not had a update in a while.

It will be just update for nodes chain propably remains

[minerminer3456]

working fine now without problem

[Sparks60]

if works or you, your one of the lucky ones

[paulmbcufc]

Nope. Trying again on a different PC. Clean install. Same issue. It's like GUI can't see that node is running. Still height zero & been syncing for 40 mins

[Sparks60]

yes, same for me, always goes on a fork,  think winning some blocks, stop, deleted data, start over same again, and all wins poof, gone

[Hashrateoptions]

The problem I’m experiencing is that the client can sync successfully and reach the chain tip. However, once synchronization is complete, it stops accepting new blocks from other nodes and starts building its own fork instead.

This appears to be a serious consensus/synchronization issue.

Can the miner verify whether I’m correct in saying that a single miner was able to mine all the blocks up to around block 1,900+ on their own?

Simply put: once the initial sync is complete, the client stops properly listening to the network for new blocks and starts building its own fork. This should be a straightforward fix.


Edit: After further testing, the sync only stops once the miner starts. At that point, the client stops properly listening to the network for new blocks and instead starts building its own fork.

I have sync problem but only with gui wallet cli one and daemon works without a problems

[Hashrateoptions]

Nope. Trying again on a different PC. Clean install. Same issue. It's like GUI can't see that node is running. Still height zero & been syncing for 40 mins

Yes gui is problematic for sure.

[IgnotusNemo]

Update:

I pushed the complete v1.0.1 patch to main: https://github.com/ignotusnemo/parano1d/commit/b1d5c073c558131f008bf8ac8ef80d661a35d150

Starting the v1.0.1 release build for all supported OS's. The complete build should take approximately two hours.
!New release will perform a one-time resync. Wallet data, receipts, P2P identity, and peer cache will be preserved. No data needs to be deleted, the migration will run automatically at startup.


What was fixed in the network layer:

Initial synchronization could accept the first valid manifest instead of the strongest chain candidate.
It now performs a bounded election by cumulative work.

A connected node could stop checking whether its tip was still current.
Exact tip probes now continue during normal operation.

Mining could remain enabled after the local tip changed.
It now requires two fresh, expiring confirmations for the exact current height and block hash.

A stronger branch inside the 18-block non-final window was not always recovered correctly.
The node now finds the common ancestor and applies the stronger branch atomically.

Losing the selected block source could discard recovery progress.
Verified progress is now retained while the node switches to another source.

Consecutive branch replacements could leave recursive markers attached to the previous terminal.
Marker rebinding is now part of the same atomic database update.

Recovery could scan permanent history unnecessarily.
Reorganization work is now bounded to the recent finality window.

Fresh nodes repeatedly depended on public seeds.
A node now uses one seed for bootstrap, then moves to ordinary Kademlia-discovered peers.


The patch was tested across all seeds and test nodes, an additional fresh GUI client. Tests included competing tips, a 12-block rollback followed by 26 replacement blocks, source disconnections, restart catch-up and a wallet transfer. All nodes converged on identical stable block hashes. No proof, consensus, database, memory or recovery-loop errors were observed.


The chain has passed height 2,000. Public seeds currently report roughly 50–60 authenticated connections each. Their peer sets overlap, so this is not a unique user count, but it confirms that dozens of public nodes are participating. External miners are active. The latest 100 accepted blocks were produced by a reward address outside the seed infrastructure, with an average interval of 15.85 seconds.

I see no reason to restart the chain from genesis. No invalid block, proof or State was accepted. The failures were confined to P2P sync and competing-branch recovery.

[zygzag]

To make matters worse, there's no Discord... what kind of clown show is this?

[alt_x]

Part of the premine launch by design. The early mining phase was intentionally structured this way, so the initial distribution was not expected to be evenly split among miners.
Stupid way to kill a coin right at the start.

[garmin]

Part of the premine launch by design. The early mining phase was intentionally structured this way, so the initial distribution was not expected to be evenly split among miners.
Stupid way to kill a coin right at the start.

Yea The shitshow started on the first launch. Then 08 UTC restart 4am est
Im gonna keep mining SOSAIEM
This coins dead to this miner. They can keep e'm all.
funny how all the shitty launches have a (Newbie) (Insider) crew being all chatty.

[Sparks60]

reset and start clean, only way to be fair

[zygzag]

Part of the premine launch by design. The early mining phase was intentionally structured this way, so the initial distribution was not expected to be evenly split among miners.
Stupid way to kill a coin right at the start.

: +100

[IgnotusNemo]

I agree. The networking bugs really made access to early mining materially uneven, so keeping the resulting distribution would not be fair.

I will keep the current network running for a few days as a public stress-test network. Anyone who keeps a node or miner online will help us test parano1d under real load and identify any remaining networking issues.
After that, mainnet will relaunch from a new genesis. Before the launch, I will publish the final release and announce the exact date and UTC time well in advance, so everyone can start from the same point.

[Sparks60]

Thank You, now that will be a fair start.

[alt_x]

Yes, this is the right decision. The early mining distribution was affected by the networking issues, so restarting from a new genesis gives everyone a fair and clean starting point.

Keeping the current chain online as a public stress-test network is also a good way to identify and fix the remaining issues before the final mainnet launch.