A Signatureless transaction model, Post-Quantum blockchain design

[IgnotusNemo]

hi, i have an idea to eliminate signatures in bitcoin model and address post-quantum constraints.

specter is a transaction model that replaces digital signatures with zero-knowledge proofs of authorization.

instead of publishing public keys and signatures, transactions prove that spending conditions are satisfied without revealing the underlying identity.

this reduces on-chain data and avoids the need to expose keys, which becomes increasingly important as signature sizes grow in post-quantum systems.

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

feedback welcome

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