External Review Notes — Kaito

Primechain / MRPC launch-testnet review notes. See also the whitepaper v2.

This note summarizes external review comments from Kaito <kaitozero@proton.me>, who mined on launch-testnet-1, reviewed the Primechain implementation, opened hardening and client-performance pull requests, and analyzed observed mining behavior across frontier records.

Kaito gave permission to credit these notes publicly as Kaito <kaitozero@proton.me>.

1. GET_FACTORIZATION CPU-Burn Finding

Kaito identified that GET_FACTORIZATION, when the optional factorization helper was enabled, could pass a large unauthenticated integer into trial-division primality testing before the proof index rejected it. The live public validators were not running with that helper exposed, but the code path was still worth hardening.

Short excerpt: "tie up a connection thread".

Project response: public sync-server hardening now bounds and constrains helper behavior so a large unauthenticated factorization request is rejected before it can burn validator CPU.

2. Checked Credit Arithmetic

Kaito noted that SequentialNode::credit() used raw addition while debit and transaction-batch paths used checked arithmetic. This was not an immediate exploit under current per-prime supply conservation, but it was an inconsistency.

Project response: this is suitable defense-in-depth work. Credits should use the same checked arithmetic discipline as debits and transaction aggregation.

3. Client Latency and Competitive Mining

Kaito profiled the frontier miner and found that sequential network calls in status probing, endpoint discovery, and commit propagation added avoidable client-side latency.

Short excerpt: "client-side sequencing, not just validator response time".

Project response: parallelizing independent client network calls is a valid reference-client improvement. The reference client should become more competitive, but consensus must not depend on the reference client being slow.

4. The `p - 1` Proof-Cache Effect

Kaito analyzed records 3309-4012 and compared prime wins with the provider that proved p - 1. His own multi-role mining setup showed a visible relationship between winning composite p - 1 and then winning prime p. Other miners in that range were split by role: some addresses submitted only composites and some submitted only primes, so the same-address test did not show the same pattern for them.

Short excerpt: "the p-1 factorization available with no network round trip".

The technical interpretation is that a client which runs composite and prime work together can place newly found composite proofs into its local proof index before the confirmed record is visible to other miners through sync. That local proof state can help construct the Pratt certificate for the next prime quickly. A multi-role client coordinating prime and composite identities can therefore outperform split-role miners.

Project response: this is currently treated as expected client-level competition. Optimized clients, multiple provider identities, and local proof reuse are allowed as long as submitted messages satisfy protocol rules. The protocol should not rely on slow client design or artificial separation between prime and composite work.

5. Remaining Weak Area

The review discussion reinforced that the weakest current area is validator admission and BFT economics, not the basic prime reward path. The network can require reserve locks and validator votes can adjust admission policy, but the exact economic meaning of a large reserve and how strongly it guarantees validator honesty remain open research questions.