A Signatureless Transaction Model and Recursive Proof-Based PQ Blockchain

[IgnotusNemo]

UPDATE 20 July 2026

Specter was archived after the prototype exposed structural problems in its state and proof architecture. The original post below remains unchanged as a historical record.

The work was rewritten from scratch as Parano1d:
https://parano1d.org/

Detailed development update:
https://bitcointalk.org/index.php?topic=5578256.msg66959745#msg66959745

---------------------------------------------------------------

March 2026
hi, i have been working on a design that removes signatures from the bitcoin model and addresses post-quantum constraints

specter replaces digital signatures with zero-knowledge proofs of authorization, where transactions prove that spending conditions are satisfied without revealing keys or identities

instead of preserving full transaction history, the system uses recursive proofs to compress validity over time. historical state is not assumed, it is verified through aggregated proofs bound to the pow chain

this reduces on-chain data, avoids key exposure, and provides a path to compact long-term validation under post-quantum assumptions

https://raw.githubusercontent.com/ignotusnemo/specter/refs/heads/main/docs/specter-whitepaper.txt

feedback welcome

UPD

a minimal prototype "specter-min"
https://github.com/ignotusnemo/specter-min

no public keys. no signatures. no elliptic curves. spend authorization is a zero knowledge proof of preimage knowledge bound to a specific state transition. stark proofs via winterfell. blake3 for all protocol hashing. binary merkle trees. sled for local persistent state

this repo exists to test the core spend authorization pipeline described in the specter whitepaper: hash derived addresses, nullifier based spentness, authorization binding, and stark proved state transitions

[tromp]

Funny how the author mimics the style of the Mimblewimble inventor [1] :

SPECTER
Ignotus Nemo
Version 1.0
23 March, 2026
/****/ Introduction /****/

MIMBLEWIMBLE
Tom Elvis Jedusor
19 July, 2016
\****/
Introduction
/****\

The name is not ideal, given the multiple existing coins called Spectre.

> Proof-of-work using RandomX. CPU-friendly. ASIC-resistant Decentralized mining accessible to commodity hardware.

RandomX suffers from being very complicated and taking a relatively long time to verify.
While you could mine on commodity hardware, only high-end CPUs (or the Bitrmain Antminer X9)
are competitive.

> The block reward decreases smoothly each block (no halvings, no supply shocks):  reward(height) = max(floor(50 * 0.999999 ^ height), 0.6)
> The tail emission then continues indefinitely at 0.6 SPEC per block.

Why not the much simpler and fairer reward(height) = 50 ?

[1] https://scalingbitcoin.org/papers/mimblewimble.txt

[IgnotusNemo]

Funny how the author mimics the style of the Mimblewimble inventor [1] :

the stylistic parallel is intentional. mimblewimble established a precedent for anonymous proposals where ideas stand on their own.
"ignotus nemo" follows that tradition

The name is not ideal, given the multiple existing coins called Spectre.

fair point. there are existing projects using spectre. however, the spelling is distinct (specter vs. spectre) and it is not fundamental and can be revisited

RandomX suffers from being very complicated and taking a relatively long time to verify.
While you could mine on commodity hardware, only high-end CPUs (or the Bitrmain Antminer X9)
are competitive.

yes, on randomx it is more complex and slower to verify than simple hash based pow. this is the trade off for reducing asic advantage.
it does not eliminate asics but raises the cost of specialization. if that balance proves insufficient the algorithm can be replaced

> The block reward decreases smoothly each block (no halvings, no supply shocks):  reward(height) = max(floor(50 * 0.999999 ^ height), 0.6)
> The tail emission then continues indefinitely at 0.6 SPEC per block.

Why not the much simpler and fairer reward(height) = 50 ?

a constant reward is simpler but it produces unbounded linear inflation. the chosen schedule converges to a fixed tail emission maintaining
long term miner incentives while limiting supply growth. early rewards are higher when security is weakest

[tromp]

Why not the much simpler and fairer reward(height) = 50 ?

a constant reward is simpler but it produces unbounded linear inflation.

So does a tail emission. Only difference is the former is pure linear while the latter is affine.

early rewards are higher when security is weakest

That makes no sense. If you're happy with a 0.6 block reward after 6 years when the value to be secured is much higher,
then you should be more than happy with a 0.6 block reward in the first 6 years.
The earlier you are in the emission, the lower the security budget can be.

[IgnotusNemo]

That makes no sense. If you're happy with a 0.6 block reward after 6 years when the value to be secured is much higher,
then you should be more than happy with a 0.6 block reward in the first 6 years.
The earlier you are in the emission, the lower the security budget can be.

you are right that both schedules produce unbounded supply growth. the difference is affine vs linear, not bounded vs unbounded. that was overstated.
on the cold start point the issue is not just absolute security budget but bootstrapping incentive. a decaying schedule front loads distribution to early participants
who take on the most uncertainty, not because higher early security is required.

whether that is the right tradeoff or whether constant emission is fairer is a legitimate design question.

grin shows that constant emission can work. the main reason specter uses decay is a coordination mechanism for early adoption. participants expect declining issuance rates even
when absolute issuance continues, which can help coordinate early demand. this is a pragmatic choice not a technical requirement.

[IgnotusNemo]

been thinking a lot about randomx, asics, and specter’s design philosophy.

specter is supposed to be hash based, simple, and post quantum. it rejects elliptic curves, trusted setups, and unnecessary complexity. but randomx is probably the most complex part of the whole system.

for specter, nodes already need to verify stark proofs per transaction, so adding slow pow verification on top just increases sync and validation cost. every block header during sync needs a randomx evaluation.

also, the bitmain x9 proves the point. even randomx eventually got asics, despite being designed to resist them. so i’m starting to think fighting asics is pointless. it’s just natural hardware evolution. what matters more is fast and cheap verification at the protocol level.

because of that, i decided to use hash based pow with blake3.

why blake3 fits specter better:

-  already used in the stack for hashing and merkle commitments
-  extremely fast verification
-  tiny implementation compared to randomx
-  post quantum safe
-  much easier to audit

yes, blake3 will favor gpus and eventually asics. but specter’s anti spam mechanism is already the stark proof cost, not pow. pow is mainly there for:

- block level sybil resistance
- emission scheduling

for that job, a simple hash pow is enough.

https://github.com/ignotusnemo/specter/blob/main/docs/specter-whitepaper.txt

[tromp]

for specter, nodes already need to verify stark proofs per transaction

Couldn't the PoW simply be the hash of aggregated_proof?
So instead of trying different nonces, the miner makes slight variations in the aggregated_proof ?

Also, couldn't you replace aggregated_proof by cumulative_aggregated_proof,
so that the (N+1)st cumulative_aggregated_proof verifies both
the Nth cumulative_aggregated_proof and the aggregated_proof for block N+1?

Then a single proof would verify the entire chain history.

[IgnotusNemo]

for specter, nodes already need to verify stark proofs per transaction

Couldn't the PoW simply be the hash of aggregated_proof?
So instead of trying different nonces, the miner makes slight variations in the aggregated_proof ?

Also,, couldn't you replace aggregated_proof by cumulative_aggregated_proof,
so that the (N+1)st cumulative_aggregated_proof verifies both
the Nth cumulative_aggregated_proof and the aggregated_proof for block N+1?

Then a single proof would verify the entire chain history.

this is a very good challenge

on cumulative validity, i agree with the direction. i’m already moving specter toward epoch-level recursive compression (will publish an updated wp version soon), and it probably makes sense to push this further so higher-level proofs attest to prior history plus new transitions

on using the proof itself as pow, i’d be more cautious. nonce grinding has a simple and well-defined search space, while proof generation may expose prover-controlled degrees of freedom. if miners can vary proofs to grind for a hash, the proving process itself becomes the mining surface, which introduces non-uniformity, centralization pressure and a harder-to-reason difficulty model

so binding pow to a proof-validated block makes sense, but making the proof itself the grind surface is much less clear

[IgnotusNemo]

specter 2.0 whitepaper published

this version is a major architectural rewrite.

the previous design allowed proofs to be pruned but did not fully replace historical validation. this version introduces epoch certificates that recursively compress block validity into a chain of proofs bound to proof of work.

history is not assumed. it is verified.

https://raw.githubusercontent.com/ignotusnemo/specter/refs/heads/main/docs/specter-whitepaper.txt

[IgnotusNemo]

i built a minimal prototype "specter-min"
https://github.com/ignotusnemo/specter-min

there are no transaction signatures, public keys or elliptic curves.

this is an attempt to remove signatures from the authorization path and see what actually breaks and what does not.

in the standard bitcoin model:

private key -> signature -> spend

this prototype does something else.

spend authorization is a zero-knowledge proof of knowledge of the required secret, bound to a specific state transition.

an address is not a public key. a signature does not exist. what remains is a secret witness, commitments, nullifiers and a proof.

a transaction here is not a signed message. it carries a proof that its authorization and state-transition constraints are satisfied.

authorization is not attached as a separate signature. it is part of the proven relation.

pushed far enough, transactions become small execution proofs. more logic can move into the circuit, proofs can be aggregated, and nodes can verify proofs instead of re-executing that logic.

! this is not a product. not a blockchain. this is a v0 protocol prototype. it exists to answer one question:

can transaction signatures be removed as a class of primitives?

[IgnotusNemo]

development update

completed so far:

formalized transaction and witness schemas
benchmarked proving and verification costs
implemented Poseidon2 and its sponge construction
arithmetized Poseidon2 inside the STARK AIR
added output commitment constraints to the AIR
implemented multi-input and multi-output transactions with weight classes

[IgnotusNemo]

development update. specter led to Parano1d

specter answered the first question: can transaction authorization exist without public keys and signatures?

yes.

it also showed that removing signatures alone is not enough.

the specter design accumulated permanent nullifiers, depended on anchor-specific witnesses and rebasing, separated production into several economic roles, and compressed validity only at epoch boundaries. the prototype demonstrated the authorization primitive, but the surrounding chain architecture did not scale cleanly.

i archived it instead of treating those choices as final.

Parano1d is the rewrite that followed. it is not specter 3.0 and not a rename. the codebase was started again from one rule:

the present state must be independently verifiable without replaying the chain from genesis.

what survived:

- no transaction signatures
- no public keys or elliptic curves in consensus
- ownership proved through knowledge of a hash preimage
- proof-valid state transitions
- recursive historical validity
- nonce-based proof of work for ordering

what changed:

the permanent nullifier set is gone. Parano1d maintains an exact live UTXO state. spending clears a slot, and that slot can be safely reused. state grows with live usage rather than lifetime transaction count.

wallet authorization is now a stateless, freshly randomized zero-knowledge capsule bound to the complete logical transaction. repeated use of the same address does not reuse authorization material.

the miner proves the public transaction relation, the exact state transition, and the previous recursive terminal in one HistoryStep before searching for a nonce. nodes verify the result instead of re-executing the transaction logic.

a new node authenticates the current live state and verifies only the recent reorg suffix. chain age adds no replay requirement and consensus does not require archive nodes.

the proof stack was also replaced. Parano1d uses GF(2^128), Poseidon2b, FROST-GKR and FRI-Binius as one binary arithmetic stack without a trusted setup.

the old specter benchmarks describe an earlier and incomplete relation. they are not performance or security claims for Parano1d

the current system targets 15-second blocks, runs on ordinary hardware, supports transactions with many UTXOs, and is being prepared for a public chain.

site: https://parano1d.org

i will continue this thread for major protocol milestones.

[IgnotusNemo]

development update. Parano1d meets the NIST PQC Category 1 threshold

when i posted the previous update, i described the Parano1d proof stack as GF(2^128). that remains the field used for committed traces, Poseidon2b and FROST-GKR, but it no longer describes the complete production security profile.

after that post i finished an end-to-end QROM analysis of the production verifier. the security game is acceptance of an invalid current state with a claimed valid history from genesis. it covers wallet authorization, the block relation, parent links, exact state writes, recursive verification and every proof on which the accepted terminal depends.

the analysis exposed a problem. security-critical algebraic challenges still lived in GF(2^128). that created a quantum ceiling which could not be removed by simply adding more FRI queries.

so i changed the consensus proof profile.

the launch profile keeps the bulk of proof construction over GF(2^128). committed traces, Poseidon2b executions and FROST-GKR relations remain in the fast binary field. Fiat-Shamir challenges, terminal claims and recursive region authentication now use GF(2^256). challenges are sampled from a trace-one affine set containing exactly 2^255 elements. one joint GF(2^256) transcript binds the three Link regions and six Block regions into the outer polynomial commitment batch.

the query geometry changed with it:

- wallet queries: 64 to 65 at rate 1/32
- History and BaseFold queries: 125 to 133 at rate 1/4
- wallet codeword length: unchanged
- History codeword lengths: 2^19 for B25 and 2^21 for B255
- transcript digest: 256 bits
- Poseidon2b: width 4, x^7, 8 full rounds and 58 partial rounds

the field extension is used only where challenge entropy affects the end-to-end bound. the committed trace remains GF(2^128), so the entire prover was not widened blindly. the final recursive path also combines the wide regions into one joint proof instead of duplicating the complete HistoryStep.

on a laptop with an Intel Core i7-1365U, isolated production B25 construction is 10.734 seconds at p50. this keeps the launch profile within reach of ordinary hardware while retaining the 15-second mean block target.

for the production profile:

- target FRI security: 128 bits
- provable Block and Tiwari FS-FRI security: 127 bits
- conjectured Block and Tiwari FS-FRI security: 127 bits
- NIST PQC category: Category 1
- dominant half-success gate-depth floor: 2^173.273866314232

the NIST Category 1 AES-128 reference is 2^170 in the same depth-aware resource model. the Parano1d production floor therefore has a margin of 3.273866314232 bits over that reference.

the complete ideal success bound inside the NIST resource envelope is 0.053364140323608411.


docs: https://docs.parano1d.org/

research: https://lab.parano1d.org/

Parano1d soundness certificate: https://github.com/ignotusnemo/parano1d-soundness


the public Parano1d network launches on 12 august 2026.

the complete source tree will be public before launch.

① site: https://parano1d.org