Parano1d ① Proof-native Layer 1 ordered by PoW

[zygzag]

To avoid any confusion between builds and releases going forward, I moved the latest mining-readiness and exact-tip sync fixes into v2.0.1.

https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.1

v2.0.1 is now the current release. It includes the minor synchronization fixes discussed above.
You can verify the installed GUI version in the upper-left corner, immediately next to the Parano1d logo. For the Core daemon, run parano1d --version in the terminal.

For future issue reports, please include the exact installed version and either the relevant log lines or the exact GUI panel and status where the problem appears.

v2.0.1 is working much better for external mining here.
We are getting consecutive accepted blocks and proving is stable around 6.3–6.4s.
I still see occasional stale recent gap, including one with our_height=3127 highest_announced=3128 stale_secs=111.
Exact version: parano1d 2.0.1.
Do you still plan to reset? What about creating a Discord server?

[zygzag]

v2.0.1 external mining is working and blocks are being accepted consistently. However, stale recent gap is still occurring regularly, usually while only one block behind, with stale_secs reaching 78s. During these gaps proof_ready/nonce_ready drops and mining resumes after the missing tip is recovered. Exact version: parano1d 2.0.1.

[alt_x]

parano1d-core-v2.0.1-linux-x86_64
==============================================
BLOCKTIME DISTRIBUTION: 0-20 SECONDS
==============================================

SECONDS    BLOCKS       PERCENT    

0          1               0.0297%
1          0               0.0000%
2          1               0.0297%
3          2               0.0594%
4          0               0.0000%
5          0               0.0000%
6          9               0.2675%
7          38              1.1293%
8          113             3.3581%
9          144             4.2793%
10         129             3.8336%
11         159             4.7251%
12         140             4.1605%
13         149             4.4279%
14         163             4.8440%
15         182             5.4086%
16         177             5.2600%
17         137             4.0713%
18         144             4.2793%
19         135             4.0119%
20         116             3.4473%


But I’m not able to run the external miner. I keep getting:
template fetch failed: RPC error: {"code":-32000,"message":"mining is waiting for network synchronization"}
It just keeps retrying every 2 seconds.

The bottleneck appears to be the exact suffix terminal verification stage. The actual proof verification lane is single-threaded?
INFO exact suffix terminal verified outside the chain writer height=478 elapsed_ms=3295

[zygzag]

==============================================
BLOCKTIME DISTRIBUTION: 0-20 SECONDS
==============================================

SECONDS    BLOCKS       PERCENT    

0          1               0.0297%
1          0               0.0000%
2          1               0.0297%
3          2               0.0594%
4          0               0.0000%
5          0               0.0000%
6          9               0.2675%
7          38              1.1293%
8          113             3.3581%
9          144             4.2793%
10         129             3.8336%
11         159             4.7251%
12         140             4.1605%
13         149             4.4279%
14         163             4.8440%
15         182             5.4086%
16         177             5.2600%
17         137             4.0713%
18         144             4.2793%
19         135             4.0119%
20         116             3.4473%


But I’m not able to run the external miner. I keep getting:

template fetch failed: RPC error: {"code":-32000,"message":"mining is waiting for network synchronization"}

It just keeps retrying every 2 seconds.

parano1d-core-v2.0.1-linux-x86_64

That error means the Core is reachable, but it does not consider itself fully synchronized / mining-ready yet. Check the Core logs for proof_ready, nonce_ready and stale recent gap. The external miner will only receive templates once the node reaches the exact tip and nonce_ready=true.

[alt_x]

Also GUI just keeps waiting for the synced tip, and when mining finally becomes ready, the usable window can be only a second or two before the next sync/update.
On a normal laptop, that makes the miner spend most of its time waiting instead of mining.
I’m not going to keep testing this if it doesn’t work properly on ordinary hardware.

[IgnotusNemo]

Lets make things clear.

1. A node remaining one block behind for 78 to 111 seconds is not normal. That is a useful networking report, and I need the complete log section around the gap, the CPU model and the peer count to investigate it.

2. A terminal verification taking 3.295 seconds on your machine is a different matter. That log reports total elapsed time. It does not prove that verification is single threaded. The node must verify the selected tip before it can issue a mining template. It will not mine on an unverified parent simply to keep the CPU busy.

3. The testnet targets a complete 20 second block interval. This is not a guaranteed minimum interval. If a machine cannot verify the tip and construct HistoryStep quickly enough to keep up with other miners, then it is below the practical performance required for mining. It can still operate as a wallet and fully verifying node.

Running on ordinary hardware does not mean every laptop is guaranteed to mine competitively. Bitcoin does not provide that guarantee either. More computing power has an advantage in every PoW system.
Parano1d was not designed to make mining easy on the weakest hardware. It was designed as an end to end post quantum proof native architecture where PoW only orders State transitions that have already been proven valid.

I will fix actual networking defects when the logs show them. But if your machine spends most of each block cycle verifying the tip, it is not fast enough for competitive mining. Use faster hardware.

[zygzag]

Lets make things clear.

1. A node remaining one block behind for 78 to 111 seconds is not normal. That is a useful networking report, and I need the complete log section around the gap, the CPU model and the peer count to investigate it.

2. A terminal verification taking 3.295 seconds on your machine is a different matter. That log reports total elapsed time. It does not prove that verification is single threaded. The node must verify the selected tip before it can issue a mining template. It will not mine on an unverified parent simply to keep the CPU busy.

3. The testnet targets a complete 20 second block interval. This is not a guaranteed minimum interval. If a machine cannot verify the tip and construct HistoryStep quickly enough to keep up with other miners, then it is below the practical performance required for mining. It can still operate as a wallet and fully verifying node.

Running on ordinary hardware does not mean every laptop is guaranteed to mine competitively. Bitcoin does not provide that guarantee either. More computing power has an advantage in every PoW system.
Parano1d was not designed to make mining easy on the weakest hardware. It was designed as an end to end post quantum proof native architecture where PoW only orders State transitions that have already been proven valid.

I will fix actual networking defects when the logs show them. But if your machine spends most of each block cycle verifying the tip, it is not fast enough for competitive mining. Use faster hardware.

testnet incentive?

[IgnotusNemo]

To avoid any confusion between builds and releases going forward, I moved the latest mining-readiness and exact-tip sync fixes into v2.0.1.

https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.1

v2.0.1 is now the current release. It includes the minor synchronization fixes discussed above.
You can verify the installed GUI version in the upper-left corner, immediately next to the Parano1d logo. For the Core daemon, run parano1d --version in the terminal.

For future issue reports, please include the exact installed version and either the relevant log lines or the exact GUI panel and status where the problem appears.

v2.0.1 is working much better for external mining here.
We are getting consecutive accepted blocks and proving is stable around 6.3–6.4s.
I still see occasional stale recent gap, including one with our_height=3127 highest_announced=3128 stale_secs=111.
Exact version: parano1d 2.0.1.
Do you still plan to reset? What about creating a Discord server?

One detail about that log: stale_secs currently measures time since your local tip last advanced, not how long your node has known about block 3128. A long block interval can therefore produce stale_secs=111 even if synchronization starts only seconds later.

Please post 20 to 30 log lines before and after that message, including timestamps and peer count. Then I can measure the exact path from announcement through download and terminal verification to commit.

Yes, this is still the public testnet. Mainnet will start from a new genesis after testing is complete. A Discord server also makes sense, but not right now.

[zygzag]

To avoid any confusion between builds and releases going forward, I moved the latest mining-readiness and exact-tip sync fixes into v2.0.1.

https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.1

v2.0.1 is now the current release. It includes the minor synchronization fixes discussed above.
You can verify the installed GUI version in the upper-left corner, immediately next to the Parano1d logo. For the Core daemon, run parano1d --version in the terminal.

For future issue reports, please include the exact installed version and either the relevant log lines or the exact GUI panel and status where the problem appears.

v2.0.1 is working much better for external mining here.
We are getting consecutive accepted blocks and proving is stable around 6.3–6.4s.
I still see occasional stale recent gap, including one with our_height=3127 highest_announced=3128 stale_secs=111.
Exact version: parano1d 2.0.1.
Do you still plan to reset? What about creating a Discord server?

One detail about that log: stale_secs currently measures time since your local tip last advanced, not how long your node has known about block 3128. A long block interval can therefore produce stale_secs=111 even if synchronization starts only seconds later.

Please post 20 to 30 log lines before and after that message, including timestamps and peer count. Then I can measure the exact path from announcement through download and terminal verification to commit.

Yes, this is still the public testnet. Mainnet will start from a new genesis after testing is complete. A Discord server also makes sense, but not right now.

Here are the logs around the stale_secs=111 event.
It looks like the actual recovery from the stale-gap message to height 3128 being verified and committed took about 2 seconds.

12:05:12 INFO block accepted height=3127
12:05:20 INFO external mining template proved history_step_ms=6451
12:05:22 INFO peer connected peer=12D3KooWMVknW5gi91BjRGUbT2pvkb44EKFssr7NjsoTrzNXGn9x
12:05:42 INFO mining network readiness changed authenticated_peers=3 failure_domains=2 frontier_authorizations=2 required_domains=1 isolated=false proof_ready=false nonce_ready=false
12:05:42 INFO stale recent gap — re-requesting authenticated headers our_height=3127 highest_announced=3128 stale_secs=111 peer=12D3KooWNWqCdLxn4uTsEAwwP9BJ7BwrjLcYBcwNRFgqgqva1qUR
12:05:44 INFO exact suffix objects complete — verification/commit started target_height=3128
12:05:44 INFO exact suffix terminal verified outside the chain writer height=3128 elapsed_ms=329
12:05:44 INFO mining network readiness changed authenticated_peers=4 failure_domains=3 frontier_authorizations=2 required_domains=1 isolated=false proof_ready=true nonce_ready=true
12:05:44 INFO header-first exact suffix application completed target_height=3128 height=3128 blocks=1 bytes=540 elapsed_ms=109 complete=true
12:05:59 INFO mining network readiness changed authenticated_peers=4 failure_domains=4 frontier_authorizations=4 required_domains=1 isolated=false proof_ready=false nonce_ready=false
12:06:01 INFO exact suffix objects complete — verification/commit started target_height=3129
12:06:01 INFO exact suffix terminal verified outside the chain writer height=3129 elapsed_ms=336
12:06:02 INFO mining network readiness changed authenticated_peers=5 failure_domains=4 frontier_authorizations=4 required_domains=1 isolated=false proof_ready=true nonce_ready=true
12:06:02 INFO header-first exact suffix application completed target_height=3129 height=3129 blocks=1 bytes=540 elapsed_ms=109 complete=true
12:06:04 INFO external mining template proved history_step_ms=6465

[IgnotusNemo]

Here are the logs around the stale_secs=111 event.
It looks like the actual recovery from the stale-gap message to height 3128 being verified and committed took about 2 seconds.

12:05:12 INFO block accepted height=3127
12:05:20 INFO external mining template proved history_step_ms=6451
12:05:22 INFO peer connected peer=12D3KooWMVknW5gi91BjRGUbT2pvkb44EKFssr7NjsoTrzNXGn9x
12:05:42 INFO mining network readiness changed authenticated_peers=3 failure_domains=2 frontier_authorizations=2 required_domains=1 isolated=false proof_ready=false nonce_ready=false
12:05:42 INFO stale recent gap — re-requesting authenticated headers our_height=3127 highest_announced=3128 stale_secs=111 peer=12D3KooWNWqCdLxn4uTsEAwwP9BJ7BwrjLcYBcwNRFgqgqva1qUR
12:05:44 INFO exact suffix objects complete — verification/commit started target_height=3128
12:05:44 INFO exact suffix terminal verified outside the chain writer height=3128 elapsed_ms=329
12:05:44 INFO mining network readiness changed authenticated_peers=4 failure_domains=3 frontier_authorizations=2 required_domains=1 isolated=false proof_ready=true nonce_ready=true
12:05:44 INFO header-first exact suffix application completed target_height=3128 height=3128 blocks=1 bytes=540 elapsed_ms=109 complete=true
12:05:59 INFO mining network readiness changed authenticated_peers=4 failure_domains=4 frontier_authorizations=4 required_domains=1 isolated=false proof_ready=false nonce_ready=false
12:06:01 INFO exact suffix objects complete — verification/commit started target_height=3129
12:06:01 INFO exact suffix terminal verified outside the chain writer height=3129 elapsed_ms=336
12:06:02 INFO mining network readiness changed authenticated_peers=5 failure_domains=4 frontier_authorizations=4 required_domains=1 isolated=false proof_ready=true nonce_ready=true
12:06:02 INFO header-first exact suffix application completed target_height=3129 height=3129 blocks=1 bytes=540 elapsed_ms=109 complete=true
12:06:04 INFO external mining template proved history_step_ms=6465

Thanks for the logs. Youre right, the node saw height 3128 at 12:05:42 and completed verification and commit at 12:05:44. Height 3129 completed in about three seconds as well.

I traced the incorrect stale_secs=111 value. A block accepted through the external mining API advanced the canonical chain but did not refresh the stale-gap recovery timer. The timer therefore retained an older value and issued a redundant header request. This is a bookkeeping bug in the recovery timer and log, not a 111 second synchronization delay or a consensus failure. I am fix this in next patch

[IgnotusNemo]

Current testnet status:

Public nodes currently have 15–18 connected peers, and several independent miners are active. New big external miner produced 76 of the latest 100 blocks. The average interval over the latest 200 blocks is 20.46 seconds, so difficulty adjustment is tracking the 20-second target correctly.

Found one remaining propagation edge under this higher load. A new header can reach the network immediately while requests for its exact body and recursive terminal wait too long in the producing miner’s serving queue. The chain remains consistent and every node eventually catches up, but I observed a few 30-45 second outliers.

I fix this in next patch too. make that queue shallow, fetch a delayed terminal from an independent provider and keep snapshot traffic from occupying live block-serving capacity.

[garmin]

Current testnet status:

Public nodes currently have 15–18 connected peers, and several independent miners are active. New big external miner produced 76 of the latest 100 blocks. The average interval over the latest 200 blocks is 20.46 seconds, so difficulty adjustment is tracking the 20-second target correctly.

Found one remaining propagation edge under this higher load. A new header can reach the network immediately while requests for its exact body and recursive terminal wait too long in the producing miner’s serving queue. The chain remains consistent and every node eventually catches up, but I observed a few 30–45 second outliers.

I fix this in next patch too. make that queue shallow, fetch a delayed terminal from an independent provider and keep snapshot traffic from occupying live block-serving capacity.

Thought this was an  Announcements (Altcoins) thread..

Altcoin Discussion is another thread entirely https://bitcointalk.org/index.php?board=67.0

Most devs use discord instead of spamming up the ANN thread. Jus sayin