Parano1d ① Proof-native Layer 1 ordered by PoW

[Hashrateoptions]

But can be new restarts no thanks.

yes, this is testnet v2. there will definitely be a restart before mainnet

It was an sarcasm I had restart and all my coins are not valid btw linux gui can not be downloaded

[IgnotusNemo]

But can be new restarts no thanks.

yes, this is testnet v2. there will definitely be a restart before mainnet

It was an sarcasm I had restart and all my coins are not valid btw linux gui can not be downloaded

 

CI builds are in progress, will be available soon
https://github.com/ignotusnemo/parano1d/actions/runs/31905214082Published

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

Gui miner state "waiting" most of the time.

Download the latest version now. There is no "waiting" state in the GUI, only "SYNCING TIP". You downloaded a draft build.




“Syncing tip” is normal behavior. It usually takes a few seconds when another miner finds a block, after which mining resumes automatically.

P.s. Use a more powerful CPU if you want to see that message less often

Gui miner state "waiting" most of the time.

Download the latest version now. There is no "waiting" state in the GUI, only "SYNCING TIP". You downloaded a draft build.

 I tried one from the latest release, and one from:
https://github.com/ignotusnemo/parano1d/actions/runs/31905214082/job/95061872608

 Both stay most of time as waiting.


Btw. Insane amount of work you have done in such small time.

remove the current GUI and download it again from the v2.0.0 release: https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.0

It makes hardly no CPU load and still at rigth top corner it says waiting.

If it says “WAITING FOR PEERS”, you are running the earlier v2.0.0 build.
Please download and reinstall  from the release page https://github.com/ignotusnemo/parano1d/releases/tag/v2.0.0.
The updated build shows “SYNCING TIP” and resumes mining automatically after verification.

I’m also still not seeing any 0–5 second block intervals in the chain, so I’m not betting anything on this yet.

You are still using a metric you do not understand. A block cannot appear before proof construction finishes, so 0–5 second intervals are not expected.

Read this: https://lab.parano1d.org/research/prove-once-search-nonces/

From a small miner’s perspective, the concern is that the block-production pipeline creates a significant time disadvantage before PoW even begins.

If the chain’s observed minimum is around 6 seconds and the typical blocktime is around 15 seconds, a small miner may spend much of each cycle waiting for the next template/proof pipeline to become available.
A miner with a faster CPU can potentially complete proof construction / HistoryStep sooner and enter the nonce-search phase earlier.

That creates a potential two-layer advantage:

large/fast miner: faster proof construction → earlier PoW start → more time hashing
small miner: slower proof construction → later PoW start → less effective time competing

So the concern isn't simply “small miners have less hash rate.”
It's that they could also lose effective mining time before they even get to hash.

If that effect is significant at the observed ~15-second blocktime, then decentralization could become a serious problem.
A network where smaller miners are routinely waiting while better hardware gets into the PoW phase first could become increasingly concentrated in the hands of the fastest hardware.

I would phrase the conclusion carefully, though: the current data suggests this risk; it doesn't yet prove that small miners are excluded from mining.
A controlled benchmark measuring proof-construction time by CPU would establish whether that advantage is actually large enough to matter.

The current testnet target is 20 seconds, not 15.

Stronger hardware has an advantage in every PoW system. In Parano1d, faster hardware can also finish HistoryStep earlier and begin nonce search sooner.
The important difference is that PoW only orders already proof-valid State transitions. More compute cannot bypass proof verification or make an invalid transition valid.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.

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

==============================================
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 patchCurrent 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.

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

..
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 resulting block to the network. The network will reject it because changing your local validation rules does not change Parano1d consensus.

[Ima_o_lambao]

Since there will be another restart for mainet we dont keep the coins mined on the tesnet right?

[IgnotusNemo]

A technical note on Parano1d was published today on the Cryptography mailing list:
https://www.metzdowd.com/pipermail/cryptography/2026-August/039748.html! Parano1d mainnet launch on August 21 at 16:00 UTC.
Binaries will be available a few hours earlier, giving everyone time to install and start their nodes. Mining will unlock automatically at 16:00 UTC, the genesis timestamp.

Testnet infrastructure has now been reduced to 2 seeds. Some existing nodes may still have the retired seed addresses cached, so their first reconnection or synchronization may take slightly longer during the transition. Fresh nodes will connect normally. Thanks to everyone who stress tested the network. It exposed real P2P liveness issues and they are now fixed before mainnet.

Mainnet parameters
Genesis: August 21, 2026, 16:00 UTC
Block target: 20 seconds
Difficulty adjustment: ASERT, 120-second half-life
Consensus: proof-native state transitions ordered by Poseidon2b PoW
Initial block subsidy: 50 NOID
Finality and reorganization window: 18 blocks
Initial State capacity: 2^24 slots, expanding with network use up to 2^32
Unit: 1 NOID = 1,000,000 μNOID

Since there will be another restart for mainet we dont keep the coins mined on the tesnet right?

Correct. Mainnet is a separate network with a new genesis. Testnet balances and mining rewards have no value on mainnet.

Performance proposal before release.

As a normal miner/user, I do not think the current version is ready for release.
Chain synchronization and miner synchronization are too slow.

The hashing is too heavy, and the code is not optimized enough for normal users.
SHA-256 should be used as an internal hashing algorithm where it is safe and compatible,
while Poseidon2b should remain for the actual PoW mining so the existing mining difficulty and security are preserved.

If the miner cannot synchronize quickly, create a block template in time, or find blocks before the next block arrives, normal users will simply stop using it.
If released in its current state, most users will ignore it and move on.

The developer has a choice:
make it fast and reliable enough for normal users, or risk all this work being for nothing.

A clean testnet full node syncs in around 20 seconds. Sync time does not grow the way it does on traditional blockchains. In ten years it should take minutes not days, so I think 20 seconds is a good tradeoff for the first startup, especially since it includes unpacking the matrices.. Btw, as the P2P network grows, more nodes will share sync data making sync faster and more reliable.

Alternative hashes were not overlooked. Earlier builds deliberately used BLAKE3 for FRI Merkle commitments and PoW. I removed it from consensus when recursive verification was completed because the recursive proof must verify the entire hash path. Suggesting SHA-256 now ignores the exact reason BLAKE3 was removed and would make the proof path worse, not better. Poseidon2b is not used only for PoW. It is used for addresses, transactions, Merkle and State commitments, proof transcripts, recursion and block IDs. Replacing it would require rebuilding consensus, the proof system, production matrices and the security model. The delay in your logs is proof construction and verification, not a generic hash loop. Parano1d is not designed to make mining easy. PoW only orders already proof-valid transitions. More independent mining power strengthens that ordering layer. Ordinary users can run wallets and fully verifying nodes, but competitive mining is a separate workload and is not guaranteed on every machine.

I am not going to spend my time debating AI generated protocol redesigns anymore.

[Seikar]

I give up on this block finding:

CPU(s):                      12
  On-line CPU(s) list:       0-11
Vendor ID:                   GenuineIntel
  BIOS Vendor ID:            QEMU
  Model name:                Intel Xeon Processor (SapphireRapids)

INFO mining complete block height=15449 txs=1 user_pages=0 proof_class=B25 prepare_ms=32284

This evening, I tested an EPYC 7313P on the testnet.  It built proof_class B25 in 12.4 to 12.5 seconds.  Arguably an EPYC 7313P is either a medium or high performance processor, depending on exactly what one considers "medium" or "high".

Taking 32.3 seconds is a long time in context.  I guess your setup (perhaps 12 vCPUs running under a QEMU virtual machine) is not fast enough to suit this coin's nonlinearity.

But you already know that.  Just providing the additional datapoint.

[Tongpu]

Fail alert

Lmao, what a time. Every Indian with free gpt access thinks he can tell real developers what they need to do

AI generated:
32 seconds on a Xeon vs around 12 seconds on an EPYC, with a 15 second block time, is simply an epic fail.

Dude, block target is 20 sec. My EPYC 4464P did B25 in 7.2 sec. Trying to figure out how to start a mining pool: proofs on my side, nonce search on your side. I will charge you a 60% fee, lol.

! Parano1d mainnet launch on August 21 at 16:00 UTC.

Hey Ignotus, big respect. Innovations always take time to be fully appreciated. Im sure it will take a year or two before people realize just how much Paranoid has changed the very concept of what a blockchain can be. Most of us are just silently following you. But we are already here.

[sillvestters]

Your poseidon2b_cryptanalysis.rs audit is pinned against ePrint 2026/306 (Merz & Rodríguez García), and your stated margin over the NIST Category 1 reference is only 3.27 bits. That same paper is the reason Ethereum just abandoned Poseidon2 for its post-quantum stack — not because it's broken, but because the round-skip attack line is new, still being actively improved, and margins dropped 30-50 bits from one paper in one year. Given that history, why should a 3.27-bit margin, computed against the current best-known attack, be treated as durable rather than as a snapshot that the next cryptanalysis paper could erase? Has the end-to-end resource theorem itself (not just the building-block papers) been reviewed by anyone outside this project?

[IgnotusNemo]

Your poseidon2b_cryptanalysis.rs audit is pinned against ePrint 2026/306 (Merz & Rodríguez García), and your stated margin over the NIST Category 1 reference is only 3.27 bits. That same paper is the reason Ethereum just abandoned Poseidon2 for its post-quantum stack — not because it's broken, but because the round-skip attack line is new, still being actively improved, and margins dropped 30-50 bits from one paper in one year. Given that history, why should a 3.27-bit margin, computed against the current best-known attack, be treated as durable rather than as a snapshot that the next cryptanalysis paper could erase? Has the end-to-end resource theorem itself (not just the building-block papers) been reviewed by anyone outside this project?

Good question. The 3.27 bit figure is not a Poseidon2b margin against that paper. It is the gap between Parano1d's end to end gate depth floor 2^173.273866... and the NIST Category 1 reference 2^170.

The 2026/306 attacks are checked separately. Their main results apply to widths 12, 16, 20 and 24, while Parano1d uses width 4 with the M4 external layer. Appendix A does apply to the feed forward compression mode, but its specialization to GF(2^128), t=4, x^7, RF=8 and RP=58 gives a descriptive classical work projection of about 2^409.87 for that attack model. The paper identifies no attack that reduces this production instance to the Category 1 boundary. The calculation and its limits here: https://github.com/ignotusnemo/parano1d/blob/main/noid_soundness/docs/category-one.md#current-poseidon2b-cryptanalysis

Fixed Poseidon2b security remains an explicit premise of the theorem. I am not claiming safety against unknown future attacks. Nobody can. If new cryptanalysis invalidates that premise, the current Category 1 conclusion no longer follows and the production parameters must change. Ethereum's caution is reasonable, but its current work with Poseidon1 does not make the wide instance attacks applicable to Parano1d's binary width 4 construction. Ethereum's own Poseidon cryptanalysis programme is still active through December 2026.

And no, the complete theorem has not yet had an independent expert review. I would welcome one. So far, the certificate has been independently reproduced and mutation tested, but that is not the same as reviewing the theorem itself. This is stated clearly in the documentation.Parano1d now has an official discussion space on github

https://github.com/ignotusnemo/parano1d/discussions

I spend most of my time there, so questions, reports and technical discussions are much easier for me to follow. I do not plan to open Discord, X, Telegram or any other channel people keep asking for. This Bitcointalk thread will remain for major announcements, while I will be active mainly on github. Welcome home, parano1ds )

[alt_x]

Parano1d now has an official discussion space on github

https://github.com/ignotusnemo/parano1d/discussions

I spend most of my time there, so questions, reports and technical discussions are much easier for me to follow. I do not plan to open Discord, X, Telegram or any other channel people keep asking for. This Bitcointalk thread will remain for major announcements, while I will be active mainly on github. Welcome home, parano1ds )

Dev keeps it simple to control, no social channels, no visibility