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.

[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

[minerminer3456]

yes admin right. discord pls

[IgnotusNemo]

Parano1d Testnet v2.1.0 is now available.

Download: https://github.com/ignotusnemo/parano1d/releases/tag/v2.1.0

This update improves exact-tip propagation, peer discovery and synchronization recovery under load. Exact block data now spreads through ordinary nodes instead of remaining concentrated on the seeds. A node can obtain block bodies and the recursive terminal from different peers, keep verified progress when a source disappears and continue from another peer without restarting synchronization.

It also fixes VPN-aware seed resolution, redundant stale-gap requests, the recovery timer after locally accepted blocks and a startup race where an older snapshot could finish after the chain had already advanced. v2.1.0 continues on the same testnet chain. No data reset or migration is required.

Public seeds already running v2.1.0 and agree on the same chain.

Lets make final stress test before mainnet. If anything behaves incorrectly, please report the exact version, height and the relevant log section.

[Seikar]

Please give a day or more advance notice, once mainnet relaunch gets a known date.  Although many new coins leave the reader wondering when launch occurred, NOID is of a higher tier in code and could be in scheduling too.

Perhaps already your intent.

[alt_x]

┌──────────── HistoryStep verification ────────────┐
  build commit: c884070814c2c1bcadb4eeb28d442086a5a0c43e
  patched files:
    noid_ivc_core/src/matrix_claim/c1.rs
    noid_recursive/src/acceptance/history_step/relation.rs
    noid_recursive/src/acceptance/history_step/wire.rs
    noid_recursive/src/acceptance/history_step_bank.rs
  height: 11492
├──────────────────────────────────────────────────┤
  CLIENT / WIRE
  decode_history_step_terminal            2 ms       
  decode metadata                          0 ms       
├──────────────────────────────────────────────────┤
  VERIFICATION
  terminal metadata                        0 ms       
  verify_field_c1_deferred_matrix_with_post_commit_context      637 ms
  MATRIX C1
    side A
      total_ms                            4166 ms
      group_ms                            4166 ms
      weighting_ms                           0 ms
    side B
      total_ms                            4160 ms
      group_ms                            4160 ms
      weighting_ms                           0 ms
    total_ms                              4168 ms
  verify_joint_c1_region_sidecar_post_commit      496 ms
  bind_verified_tip_replay                 0 ms       
  verify_history_step_pending_timed      637 ms       
  HistoryStepRuntime::decide_timed     4471 ms       
  RUNTIME.DECIDE
    PendingHistoryStepBankDecision::finish_with_matrix_loader_timed 4471 ms
      load                                  0 ms       
      check_class_matrix_lease          4471 ms       
      loaded classes                       1           
  final checks                              0 ms       
  terminal verify total                  5108 ms       
├──────────────────────────────────────────────────┤
  TOTAL
  decode + verify                        5110 ms       
└──────────────────────────────────────────────────┘
14:34:08  INFO exact suffix terminal verified outside the chain writer height=11492 elapsed_ms=5120

After skipping heavy check:

┌──────────── HistoryStep verification ────────────┐
  build commit: c884070814c2c1bcadb4eeb28d442086a5a0c43e
  patched files:
    noid_ivc_core/src/matrix_claim/c1.rs
    noid_recursive/src/acceptance/history_step/relation.rs
    noid_recursive/src/acceptance/history_step/wire.rs
    noid_recursive/src/acceptance/history_step_bank.rs
  height: 11545
├──────────────────────────────────────────────────┤
  CLIENT / WIRE
  decode_history_step_terminal            1 ms       
  decode metadata                          0 ms       
├──────────────────────────────────────────────────┤
  VERIFICATION
  terminal metadata                        0 ms       
  verify_field_c1_deferred_matrix_with_post_commit_context      662 ms
  MATRIX C1
    side A
      total_ms                               0 ms
      group_ms                               0 ms
      weighting_ms                           0 ms
    side B
      total_ms                               0 ms
      group_ms                               0 ms
      weighting_ms                           0 ms
    total_ms                                 0 ms
  verify_joint_c1_region_sidecar_post_commit      512 ms
  bind_verified_tip_replay                 0 ms       
  verify_history_step_pending_timed      662 ms       
  HistoryStepRuntime::decide_timed        0 ms       
  RUNTIME.DECIDE
    PendingHistoryStepBankDecision::finish_with_matrix_loader_timed    0 ms
      load                                  0 ms       
      check_class_matrix_lease             0 ms       
      loaded classes                       0           
  final checks                              0 ms       
  terminal verify total                   662 ms       
├──────────────────────────────────────────────────┤
  TOTAL
  decode + verify                         663 ms       
└──────────────────────────────────────────────────┘
14:52:09  INFO exact suffix terminal verified outside the chain writer height=11545 elapsed_ms=681

So, patch skipped around 5secs and we are still able to mine?

[IgnotusNemo]

..
So, patch skipped around 5secs and we are still able to mine?

What you are trying to do is called validationless mining. You removed a local consensus check from your own node. You did not bypass Parano1d. Every node still performs the complete matrix verification and will reject any block built on an invalid terminal.

Bitcoin miners tried the same thing in 2015. They started mining before validating the parent, extended an invalid BIP66 chain and lost tens of thousands of dollars. The response was simple: stop SPV mining and return to full validation.

https://bitcointalk.org/index.php?topic=1108304.140

Btw, your 5 seconds result reflects the performance of your machine. On my old Intel i7 laptop with AVX2 (using 12 threads) full terminal verification averages 0.48 seconds.
If you want to mine competitively, use appropriate hardware.

[alt_x]

..
So, patch skipped around 5secs and we are still able to mine?

What you are trying to do is called validationless mining. You removed a local consensus check from your own node. You did not bypass Parano1d. Every node still performs the complete matrix verification and will reject any block built on an invalid terminal.

Bitcoin miners tried the same thing in 2015. They started mining before validating the parent, extended an invalid BIP66 chain and lost tens of thousands of dollars. The response was simple: stop SPV mining and return to full validation.

https://bitcointalk.org/index.php?topic=1108304.140

Btw, your 5 seconds result reflects the performance of your machine. On my old Intel i7 laptop with AVX2 (using 12 threads) full terminal verification averages 0.48 seconds.
If you want to mine competitively, use appropriate hardware.

The Bitcoin issue is not related to this yet.

I first need to test whether the patched Matrix can or cannot create valid blocks.
If it can create a valid block, then your code is broken.
If the proof is included in the block data and I cannot create a valid block with the patched Matrix, then the code is working as intended.
I have not tested that yet.
I don't care about hardware. I'm using an 11th-gen, 12-core laptop.
 
The important question is whether the patch makes mining more accessible by reducing the local validation work, potentially allowing simpler hardware or large-scale botnets to participate more easily.

[IgnotusNemo]

..
So, patch skipped around 5secs and we are still able to mine?

What you are trying to do is called validationless mining. You removed a local consensus check from your own node. You did not bypass Parano1d. Every node still performs the complete matrix verification and will reject any block built on an invalid terminal.

Bitcoin miners tried the same thing in 2015. They started mining before validating the parent, extended an invalid BIP66 chain and lost tens of thousands of dollars. The response was simple: stop SPV mining and return to full validation.

https://bitcointalk.org/index.php?topic=1108304.140

Btw, your 5 seconds result reflects the performance of your machine. On my old Intel i7 laptop with AVX2 (using 12 threads) full terminal verification averages 0.48 seconds.
If you want to mine competitively, use appropriate hardware.

The Bitcoin issue is not related to this yet.

I first need to test whether the patched Matrix can or cannot create valid blocks.
If it can create a valid block, then your code is broken.
If the proof is included in the block data and I cannot create a valid block with the patched Matrix, then the code is working as intended.
I have not tested that yet.
I don't care about hardware. I'm using an 11th-gen, 12-core laptop.
 
The important question is whether the patch makes mining more accessible by reducing the local validation work, potentially allowing simpler hardware or large-scale botnets to participate more easily.

If you skip verification and mine on a valid parent, your block may still be valid. That proves nothing. You simply trusted the parent and happened to be right.
The real test is to mine on an invalid terminal and submit the result to an unmodified v2.1.0 node. If it accepts the block, that is a bug. Otherwise this is simply validationless mining.