Parano1d ① Proof-native Layer 1 ordered by PoW

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

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.

My daemon is also stuck.

The launch will likely be remembered as a failed premine-style launch, where individual miners were able to capture a disproportionate share of the initial coins during the early network phase.

[garmin]

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.

so much for a fair launch

o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus

has 26325.006500 of the 96k mined

While most got ZERO

FAIR LAUNCH MY ASS

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

[zygzag]

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.

Great! But setting up a Discord server would be easier for everyone.

[Hashrateoptions]

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.

No that is a fail genesis mined network moving I am mining and what my money do not count ?? I do not agree to restart and most of those who write are just joined or multi accounts I have put money to mine and I dont care for latecommers if you restart then pay me my money back

Thank You, now that will be a fair start.

No that is a bullshit

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.

No it is not right it was said is mainnet and just because of p2p leak you want to restart chain what will be next if there will be bug each time restarts that is really funny network is going and it should go like it is peers connected blocks produced and bugs should be fixed on go you can not just say restart next time I will be not here and I will say as some of you to restart as it was not fair is that a playground for kids ?

[Sparks60]

i am guessing your the miner with 26,000 coins, and you think thats fair? taking most coins,i been trying to mine from the very start. dont matter, no matter what, dev will never be able to make everyone happy. i been in many new coins thats had to reset a few times like this, only fair way is to do what dev says, reset from zero.

[Hashrateoptions]

And if you have no idea how to sync even if network have some problems means it is your problem I think chai should be keeped as jow is stable and after fixes it will be more stable. Yes they will cry as they are late and of course their spam machines was not able to reach chain.

i am guessing your the miner with 26,000 coins, and you think thats fair? taking most coins,i been trying to mine from the very start. dont matter, no matter what, dev will never be able to make everyone happy. i been in many new coins thats had to reset a few times like this, only fair way is to do what dev says, reset from zero.

Yes it is fair and I know will be more fair if you have them.
That are skills and money in to mine.
You can always ask nakamoto too to reatart bitcoin what a bad thinking.

The network is still young and any cpu can mine blocks was a lot of MH now hashrate is small still available for miners
Get good hardware and good internet connection.

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.

so much for a fair launch

o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus

has 26325.006500 of the 96k mined

While most got ZERO

FAIR LAUNCH MY ASS

most got zero so that 70k is zero ? Or my math is bad ?

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.

At start I have not mining until block 1500 then I tried once again and it works. Melted time and money if you will restat it one more time that will be reall fail. They trying to force because some of use weak hardware some have no skills and some are late. I will not agree as I started to mine late and still mine good you can check when I launch mining.

[alt_x]

After the node reaches the Synced state, the issue becomes apparent once mining is running. New blocks do not arrive and get processed one by one as expected. Instead, the Linux GUI appears to receive and process blocks in batches of around 5–10 blocks at a time.

It looks like the miner is still working on an older block/template and is unable to keep up with the latest chain tip while mining.

This gives the impression that the 15-second block time may be too aggressive for the Linux GUI client to reliably follow the network while mining, causing it to fall behind and potentially build its own fork.

At the moment, it also appears that one high-powered miner is effectively pulling the chain forward while other miners struggle to participate. If this continues, the current setup does not provide a realistic opportunity for smaller miners to participate competitively.

[Hashrateoptions]

After the node reaches the Synced state, the issue becomes apparent once mining is running. New blocks do not arrive and get processed one by one as expected. Instead, the Linux GUI appears to receive and process blocks in batches of around 5–10 blocks at a time.

It looks like the miner is still working on an older block/template and is unable to keep up with the latest chain tip while mining.

This gives the impression that the 15-second block time may be too aggressive for the Linux GUI client to reliably follow the network while mining, causing it to fall behind and potentially build its own fork.

At the moment, it also appears that one high-powered miner is effectively pulling the chain forward while other miners struggle to participate. If this continues, the current setup does not provide a realistic opportunity for smaller miners to participate competitively.

I have same situation till block 1500 but after I start to mine normally without a problem.
Do smaller miners have opportunity to mine bitcoin ?
Give me a break with all that shit talk dev said chain should be keeped and all started shit storm to restart because they dont have time to try one more time it is a joke.

[garmin]

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.

so much for a fair launch

o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus

has 26325.006500 of the 96k mined

While most got ZERO

FAIR LAUNCH MY ASS

most got zero so that 70k is zero ? Or my math is bad ?

Well no sync gets zero.  Same games different coin. The shill crews are getting obvious.

[Hashrateoptions]

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.

so much for a fair launch

o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus

has 26325.006500 of the 96k mined

While most got ZERO

FAIR LAUNCH MY ASS

most got zero so that 70k is zero ? Or my math is bad ?

Well no sync gets zero.  Same games different coin. The shill crews are getting obvious.

I have same problems and I dont  cried I can not mine tried arround 1500 height and it works so should I now say reset chain because 1500 was mined without me. No
And your mayhs shows one thing if there is 96 k someone mined 26k 70 k went to others so by that you do not respect others who mine 70k in total so now answer yourself how many miners was there and how many of them will be in bad mode just because few persons  can not mine or sync it does not matter that something is unfair , life is unfair i am not elon musk please restart my life as that was not fair launch really give me a break

[minerminer3456]

lets do a reset. weird launch actually


gui never syncs btw