Parano1d ① Proof-native Layer 1 ordered by PoW

[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

[Arttemkaaa]

lets do a reset. weird launch actually

No need for a reboot. Why reset everything when some disgruntled person comes along?! The network must work.

Many people didn't sleep last night and got nothing. I went to the fork almost immediately and got almost nothing on my second try. But why restart the network?! There will always be dissatisfied people.

[minerminer3456]

fair launch pls

[Sparks60]

tested new version, will sync, win a block, reorg, poof gona, endless loop, at this point i am gona wish you the best on a 15 second block coin, as all i tried fails at 15 seconds. time for me to move on.

[minerminer3456]

impossıble to mine. alot of problems. after two days of work i am giving up.

[tomassamot]

still doesn't work  peers 5 height 0  with new 1.01 version


23:11:31  INFO manifest snapshot boundary ahead — queueing snapshot candidate from=12D3KooWKbNz4TzReuNp5mpyz38nyKGogqbUVXZiVEU12ayAUoHX our_height=0 snapshot_height=3391 snapshot_gap=3391 force_snapshot=true
23:11:31  INFO connected header probe found deep gap — requesting snapshot manifest peer=12D3KooWA4xTVV3kMmkDFTZoaxbBPawjZ8HY3r5oxumBvD3tveAd our_tip=0 peer_tip=19 retention=18
23:11:32  INFO received state manifest from=12D3KooWA4xTVV3kMmkDFTZoaxbBPawjZ8HY3r5oxumBvD3tveAd tip=3396 segments=1
23:11:32  INFO manifest snapshot boundary ahead — queueing snapshot candidate from=12D3KooWA4xTVV3kMmkDFTZoaxbBPawjZ8HY3r5oxumBvD3tveAd our_height=0 snapshot_height=3396 snapshot_gap=3396 force_snapshot=true
23:11:35  INFO connected header probe found deep gap — requesting snapshot manifest peer=12D3KooWHniog4xyYkVwbFjavbEWXzZT6NGiF1Q7JQ27YsnvKSPG our_tip=0 peer_tip=19 retention=18
23:11:35  INFO snapshot manifest election settled — validating strongest advertised chain from=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ tip=3396 bridge_tip=3414 responses_considered=5
23:11:35  INFO snapshot: staging exact headers peer=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ target_height=3396 bridge_tip=3414
23:11:35  INFO snapshot: pipelining exactly correlated headers into disk staging peer=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ next_height=1 target_height=3396 window=4
23:11:35  INFO received state manifest from=12D3KooWHniog4xyYkVwbFjavbEWXzZT6NGiF1Q7JQ27YsnvKSPG tip=3394 segments=1
23:11:35  INFO manifest snapshot boundary ahead — queueing snapshot candidate from=12D3KooWHniog4xyYkVwbFjavbEWXzZT6NGiF1Q7JQ27YsnvKSPG our_height=0 snapshot_height=3394 snapshot_gap=3394 force_snapshot=false
23:11:37  INFO snapshot: exact headers staged — retrying HistoryStep terminal peer=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ target_height=3396
23:11:39  INFO snapshot HistoryStep verification started off-thread from=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ terminal_from=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ tip=3396
23:11:40  INFO snapshot sync phase measurement phase="history_step_terminal" scaling="O(1)" count=1 bytes=971732 elapsed_ms=1063 timing_basis="active_work" outcome="accepted"
23:11:40  INFO snapshot authority accepted — starting exact state staging from=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ tip=3396 bridge_tip=3414


after some time 


23:14:30  INFO received state manifest from=12D3KooWHniog4xyYkVwbFjavbEWXzZT6NGiF1Q7JQ27YsnvKSPG tip=3402 segments=1
23:14:30  INFO manifest snapshot boundary ahead — queueing snapshot candidate from=12D3KooWHniog4xyYkVwbFjavbEWXzZT6NGiF1Q7JQ27YsnvKSPG our_height=0 snapshot_height=3402 snapshot_gap=3402 force_snapshot=false
23:14:31  INFO received state manifest from=12D3KooWGBGvUCfRmiux5n6L8CT76iHWbn5j964qnZ2cMDC7mEvv tip=3403 segments=1
23:14:31  INFO manifest snapshot boundary ahead — queueing snapshot candidate from=12D3KooWGBGvUCfRmiux5n6L8CT76iHWbn5j964qnZ2cMDC7mEvv our_height=0 snapshot_height=3403 snapshot_gap=3403 force_snapshot=false
23:14:32  INFO connected header probe found deep gap — requesting snapshot manifest peer=12D3KooWGBGvUCfRmiux5n6L8CT76iHWbn5j964qnZ2cMDC7mEvv our_tip=0 peer_tip=19 retention=18
23:14:32  INFO connected header probe found deep gap — requesting snapshot manifest peer=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ our_tip=0 peer_tip=19 retention=18
23:14:32  INFO received state manifest from=12D3KooWGBGvUCfRmiux5n6L8CT76iHWbn5j964qnZ2cMDC7mEvv tip=3403 segments=1
23:14:32  INFO manifest snapshot boundary ahead — queueing snapshot candidate from=12D3KooWGBGvUCfRmiux5n6L8CT76iHWbn5j964qnZ2cMDC7mEvv our_height=0 snapshot_height=3403 snapshot_gap=3403 force_snapshot=true
23:14:32  INFO received state manifest from=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ tip=3404 segments=1
23:14:32  INFO manifest snapshot boundary ahead — queueing snapshot candidate from=12D3KooWKc1nxUCCumRwHiv427cKeQ67PhBqpf8PuCWQQsDHxTEZ our_height=0 snapshot_height=3404 snapshot_gap=3404 force_snapshot=true
23:14:36  INFO snapshot manifest election settled — validating strongest advertised chain from=12D3KooWA4xTVV3kMmkDFTZoaxbBPawjZ8HY3r5oxumBvD3tveAd tip=3404 bridge_tip=3422 responses_considered=5
23:14:36  INFO snapshot: staging exact headers peer=12D3KooWA4xTVV3kMmkDFTZoaxbBPawjZ8HY3r5oxumBvD3tveAd target_height=3404 bridge_tip=3422
23:14:36  INFO snapshot: pipelining exactly correlated headers into disk staging peer=12D3KooWA4xTVV3kMmkDFTZoaxbBPawjZ8HY3r5oxumBvD3tveAd next_height=1 target_height=3404 window=4
23:14:38  INFO snapshot: exact headers staged — retrying HistoryStep terminal peer=12D3KooWA4xTVV3kMmkDFTZoaxbBPawjZ8HY3r5oxumBvD3tveAd target_height=340

[IgnotusNemo]

Thank you, everyone, for the detailed reports and logs.

This launch gave me a lot of useful information that could only really show up under live stress. I now have a clear picture of what is wrong with the p2p design.

One of the main goals of Parano1d was to remove a major debt of existing systems. the need to store and replay the entire execution history to prove that the present is valid. This opens the way to real scalability.
The new architecture, together with removing signatures and elliptic curves, also made Parano1d post-quantum from its first block. The entire validity path from genesis to any height is backed by an executable end-to-end post-quantum soundness theorem at the NIST PQC Category 1 resource threshold.

Parano1d was written from scratch over more than six months, often working 12+ hours a day. Most of my work has been around cryptography, proof systems and protocol design.
And we can already see that the consensus and cryptography work exactly as intended. We achieved a fantastic result there.

Networking is probably the part I enjoy the least, and of course network decided to test exactly that first

I will redesign the P2P layer rather than keep adding patches. Headers will propagate first, separately from heavy block bodies, proofs and State data. Synchronization will remain fixed to one exact branch while allowing data to come from different peers. Reorgs will verify one recursive terminal at the selected tip instead of one for every block.

This confirms the decision to delay mainnet. The mainnet launch will start from a new genesis. This is now a technical requirement, not a question of noid distribution among early miners.
Over the next few days I will rebuild and test the networking layer. After the final load tests, we will launch mainnet.

We are only starting to explore what this architecture can make possible in practice. There is a lot ahead.

[rajashek41]

Looks like all the coins are already mined

I have been mining for the pas 5 hours with AMD Ryzen 7 ... I have not come across a single block yet

[alt_x]

OLD CHAIN ISSUES:


==============================================
PARANO1D CHAIN ANALYSIS
==============================================
Chain: #1 - #8493
Total blocks: 8493
Miner reward: 45 NOID/block

==============================================
MINER RICH LIST
==============================================

MINER                                                                    BLOCKS               NOID    PERCENT

o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus               2819          126855.00   33.1920%
o1fnf5fuqsq2cffhh9s30latya9v4qj5scdewyz73p2ad68ec78cws8csj8v               1208           54360.00   14.2235%
o1cu5euacey0kah3n5yjd3h46nfqzlxuva2jue8k9kgrx8lqg9yxgqvzzkcw               1081           48645.00   12.7281%
o1e5vytsgmlu8lmvcerakunafthwg2hc2pptkmcuaes3js9ys23ugq8ddwch                884           39780.00   10.4086%
o1rpwfdltjjssrc3h4as0l9rfdlfph0kz24hp9fe4m923wsxf0kens456q4k                582           26190.00    6.8527%
o189d72tcej2y5f8rr9mhhu2pjvlg2mjuaa34q5sceexsrpp8ghm3st7s8wa                317           14265.00    3.7325%
o19uyx7zs5rnue0u2d77fqgphdnrw3y09nn8edtd7kdhu6vgta7f5qq245qu                299           13455.00    3.5205%
o1syg7srzklvcyumyp8avlz2vxakygqgrz4twpncz6ae2aa04a9n6skypec4                244           10980.00    2.8730%
o1kr90maj55t2mhu4rjfaec2n2kkey6m43hzt64cp4mgz4ndx2m5cq6gj7xn                157            7065.00    1.8486%
o10h74vlp42sxanv26qwhk7d327fujzmtzm7l6ehu0rx60enpccexqm02gcm                146            6570.00    1.7191%
o14665vruv5aw5yrkqk85axtxy0t8dy2y2lxdx6gzg6xx9ljrv8whs5ngncz                119            5355.00    1.4012%
o1jpwqswmyad028hgjml84wzpyy9uxv600t2stzwncp3269d07g3kq6syq5c                119            5355.00    1.4012%


==============================================
LONGEST CONSECUTIVE MINER STREAKS
==============================================

STREAK   START    END      NOID                  PERCENT MINER

779      423      1201     35055.00              9.1723% o1cu5euacey0kah3n5yjd3h46nfqzlxuva2jue8k9kgrx8lqg9yxgqvzzkcw
286      1851     2136     12870.00              3.3675% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
278      1565     1842     12510.00              3.2733% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
93       1        93       4185.00               1.0950% o1fnf5fuqsq2cffhh9s30latya9v4qj5scdewyz73p2ad68ec78cws8csj8v
92       2838     2929     4140.00               1.0832% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
75       2450     2524     3375.00               0.8831% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
73       8421     8493     3285.00               0.8595% o1fnf5fuqsq2cffhh9s30latya9v4qj5scdewyz73p2ad68ec78cws8csj8v
57       2193     2249     2565.00               0.6711% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
54       2138     2191     2430.00               0.6358% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
46       2754     2799     2070.00               0.5416% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
33       2565     2597     1485.00               0.3886% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
32       2397     2428     1440.00               0.3768% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
28       2801     2828     1260.00               0.3297% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
22       2632     2653     990.00                0.2590% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
21       3227     3247     945.00                0.2473% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus
21       3084     3104     945.00                0.2473% o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus




==============================================
BLOCKTIME DISTRIBUTION
==============================================

SECONDS    BLOCKS       PERCENT    

0          0               0.0000%
1          0               0.0000%
2          0               0.0000%
3          0               0.0000%
4          0               0.0000%
5          0               0.0000%
6          6               0.0707%
7          224             2.6378%
8          357             4.2040%
9          389             4.5808%
10         374             4.4041%
11         511             6.0174%
12         527             6.2058%
13         560             6.5944%
14         631             7.4305%
15         556             6.5473%
16         522             6.1470%
17         428             5.0400%
18         398             4.6868%
19         360             4.2393%
20         281             3.3090%


I found something interesting: the chain has only six 6-second block intervals, and all six were mined by the same address. The blocks were #1568, #1643, #1900, #2381, #2451 and #3938 — all by o1wavhkuxgv5ekr9t0wzz573q6567lmsqxfsr4zxj0ksp2hzjvqspqeyemus. That means this miner produced 100% of the fastest observed 6-second blocks in the entire chain.

The data strongly suggests there is a code-level bottleneck in the block-production pipeline: the chain has zero block intervals below 6 seconds, with the first observed intervals appearing at 6 seconds. That indicates the implementation may be unable to produce and commit a new block within roughly 0–5 seconds under the current conditions.

[IgnotusNemo]

The data strongly suggests there is a code-level bottleneck in the block-production pipeline: the chain has zero block intervals below 6 seconds, with the first observed intervals appearing at 6 seconds. That indicates the implementation may be unable to produce and commit a new block within roughly 0–5 seconds under the current conditions.

A block is proof construction first, then PoW, so the shortest possible interval is the proof time plus however long it takes to find a valid nonce. The same miner producing all six is not evidence of a code-level bottleneck.

[alt_x]

The data strongly suggests there is a code-level bottleneck in the block-production pipeline: the chain has zero block intervals below 6 seconds, with the first observed intervals appearing at 6 seconds. That indicates the implementation may be unable to produce and commit a new block within roughly 0–5 seconds under the current conditions.

A block is proof construction first, then PoW, so the shortest possible interval is the proof time plus however long it takes to find a valid nonce. The same miner producing all six is not evidence of a code-level bottleneck.

I think the right way to settle this is to run a stress test with no artificial blocktime floor. That would let us measure the actual time required to construct and commit a block, separately from the time required to find a valid PoW nonce.

It would also answer an important question: can a sufficiently powerful miner actually start mining the next block earlier than other miners because it can complete the block-construction/proof pipeline faster? If so, an efficient miner could gain an additional advantage by getting into the PoW phase sooner, rather than the advantage coming purely from raw hash rate.

[IgnotusNemo]

The data strongly suggests there is a code-level bottleneck in the block-production pipeline: the chain has zero block intervals below 6 seconds, with the first observed intervals appearing at 6 seconds. That indicates the implementation may be unable to produce and commit a new block within roughly 0–5 seconds under the current conditions.

A block is proof construction first, then PoW, so the shortest possible interval is the proof time plus however long it takes to find a valid nonce. The same miner producing all six is not evidence of a code-level bottleneck.

I think the right way to settle this is to run a stress test with no artificial blocktime floor. That would let us measure the actual time required to construct and commit a block, separately from the time required to find a valid PoW nonce.

It would also answer an important question: can a sufficiently powerful miner actually start mining the next block earlier than other miners because it can complete the block-construction/proof pipeline faster? If so, an efficient miner could gain an additional advantage by getting into the PoW phase sooner, rather than the advantage coming purely from raw hash rate.

The code is public. There is no artificial blocktime floor to remove. Block production is proof construction followed by PoW, exactly as implemented.

Please read the code before making more claims about the pipeline:
https://github.com/ignotusnemo/parano1d

I am happy to discuss specific code or measurements. I am not interested in debating AI-generated speculation.