A New Model for Transactions Without Signatures and a PQ Blockchain Based on Recursive Proofs

Hey everyone, I've been working on a concept that eliminates signatures from the Bitcoin model and takes into account post-quantum limitations. Instead of digital signatures, this project called Specter uses zero-knowledge proofs to show that spending conditions are met without exposing any keys or identities. Rather than keeping a complete history of transactions, the system relies on recursive proofs to validate transactions over time. It doesn’t just assume past states; it verifies them using aggregated proofs linked to the proof-of-work chain. This approach cuts down on-chain data requirements, minimizes the risk of key exposure, and offers a way to maintain compact long-term validation while considering post-quantum scenarios. Feedback would be appreciated. UPD Check out the minimal prototype "specter-min". There are no public keys, no signatures, and no elliptic curves involved. Authorization for spending is established through a zero-knowledge proof that demonstrates knowledge of a preimage specific to a state transition. It uses STARK proofs via Winterfell, Blake3 for hashing, binary Merkle trees, and Sled for local persistent storage. This repository is designed to test the core spend authorization process outlined in the Specter whitepaper: deriving hashes for addresses, nullifier-based spent status, binding authorizations, and state transitions guaranteed by STARK proofs.

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

the stylistic parallel is intentional. mimblewimble established a precedent for anonymous proposals where ideas stand on their own. "ignotus nemo" follows that tradition 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 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 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

So does a tail emission. Only difference is the former is pure linear while the latter is affine. 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.

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

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. a nonce space is simple and uniform, while a proof space is not. 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

specter 2.0 whitepaper published this version is a structural change, not an iteration the previous design allowed pruning of proofs but did not fully replace historical validation. this version introduces epoch certificates that recursively compress block proofs into a single validity chain bound to pow. history is not assumed, it is verified state transition and attachment are now separated. ownership proofs can be rebased to a new anchor without full reproving, which changes how spends survive reorgs and makes the mempool viable the spend path is now explicit. intent first, proof later, with defined witness handling instead of implicit assumptions block production is no longer a single role. assembly, aggregation and mining are separated conceptually, with aggregation as the hardware intensive step. pow remains nonce based and independent from proof construction overall this moves the system from transaction level verification to recursive chain level validity with a defined production model https://raw.githubusercontent.com/ignotusnemo/specter/refs/heads/main/docs/specter-whitepaper.txt

i built a minimal prototype "specter-min" https://github.com/ignotusnemo/specter-min there are no signatures, at all. no public keys, no elliptic curves this is an attempt to remove a fundamental primitive completely and see what actually breaks and what doesn't in the standard bitcoin (and other altcoins) model: private key -> signature -> spend this prototype does something else - no signing. spend authorization is a proof that the state transition is correct and that it is valid to execute it not "i control a key" but "this state transition is mathematically valid and can be executed" this is a different primitive. removing keys removes a whole surface nothing to leak nothing to reuse nothing to track an address is not a public key. a signature does not exist. what remains is commitments, nullifiers and a proof a transaction here is not a signed message, it is a proven state transition. a small proof that the system changed correctly pushed far enough, each transaction becomes its own small zk-style execution proof authorization is not separate from execution, it is part of it. there is no signature attached to a transaction. the entire operation is proven correct this makes it possible to encode rules and conditions directly into the proof instead of relying on key ownership or scripts if this model is extended, more logic moves into the circuit, recursion becomes possible, proofs can be aggregated, verification becomes simpler nodes do not need to re-execute complex logic, they verify proofs instead ! this is not a product. not a blockchain. this is a v0 protocol prototype. it exists to answer one question: can signatures be removed as a class of primitives?

development update completed so far: formalized transaction and witness schemas benchmarked proving and verification costs implemented and hardened Poseidon2 + sponge construction arithmetized Poseidon2 inside the STARK AIR achieved witness-free verification with a single-step send flow added output commitment constraints into the AIR replaced hybrid verification with fully in-circuit verification implemented multi-input / multi-output transactions with weight classes current spend proof benchmarks: proving W1: 14.6 ms W2: 36.0 ms W3: 104.7 ms verification W1: 0.376 ms W2: 0.464 ms W3: 0.541 ms proof size W1: 35.5 KB W2: 41.1 KB W3: 45.9 KB for context: W1 = 1 input / 2 outputs W2 = 2 inputs / 4 outputs W3 = 4 inputs / 8 outputs at this stage, the system is already operating in a very competitive range for client-side, post-quantum, signatureless private transaction proving. i'm happy with these numbers 1. verification is almost flat this is one of the most important properties. verification growth is very small: W1 → W2: ~+88 µs W2 → W3: ~+77 µs W1 → W3: only ~+165 µs that means transaction complexity can scale without crushing the verifier. verifier cost matters for blockchain more than people often admit, because verification is what will be performed by: the network block validators light clients future recursive outer proofs if verification stays this flat while transaction expressiveness increases, that is a very strong signal. 2. proof size grows in a controlled way W1: 35.5 KB W2: 41.1 KB W3: 45.9 KB growth: W1 → W2: +5.6 KB W2 → W3: +4.8 KB W1 → W3: +10.4 KB this means: less network pressure lower storage overhead better conditions for recursive aggregation later a healthier future mempool / relay / P2P layer 3. W3 already looks like a real transaction shape W3 = 4 inputs / 8 outputs at roughly 105 ms proving time. this is already enough to support transaction shapes that matter in practice: UTXO consolidation merge / split patterns privacy-friendly note reshaping batch-style spend behavior important this system is being built around a STARK-based proving model, which means: no trusted setup post-quantum friendly design authorization enforced by proofs instead of signatures and a path toward recursive aggregation so yes, these numbers are not being achieved by taking the easy route. that's exactly why I consider them meaningful. development status since there has been very little serious technical engagement here so far, i’ve moved most active development into a private workflow for now. the project will become public in a more complete form around the first proper release / code drop. if someone is genuinely interested in the architecture or has a concrete technical question, feel free to pm me. If the question is specific and serious enough, i can share selected files / internal docs privately. still a lot to build, but the current proving / verification profile is already very encouraging