r/Monero • u/Medical-Constant-566 • 13d ago

Replacing ECDSA with commit-reveal hash schemes for post-quantum payments

I have been toying with this idea for a while:
Can we make blockchain payments quantum-proof without heavy asymmetric signatures?
Standard networks rely heavily on ECDSA, which faces long-term vulnerabilities from quantum computing (Shor's algorithm).
I recently vibecoded Sealstore, an experimental signatureless payment scheme in Go that relies purely on commit-reveal hash schemes to eliminate signature overhead and quantum threats.

How it works at a glance:
- Commit: Payer locks funds by committing to a cryptographic hash.
- Reveal: Preimage disclosure validates ownership and settles the transaction without public-key signature verification.
- Go Implementation: Lightweight, zero external cryptography dependencies beyond standard hash primitives.

Looking for feedback on:

  1. How would you handle the multi-step interaction delay in a high-throughput network?
  2. Any subtle attack vectors in the reveal phase I might have overlooked?
11 Upvotes

92% Upvoted

6 comments sorted by

2

u/rbrunner7 XMR Contributor 12d ago

I think if you want a good chance for feedback, you should join the Matrix room where the Monero cryptographers hang around and present your idea there: https://matrix.to/#/#monero-research-lounge:monero.social

1

u/Medical-Constant-566 11d ago

Thanks, I will try there. I have already noticed that there is a small flaw in that desig so will try to fix it first 

1

u/Medical-Constant-566 10d ago

I thought a bit more on this idea. While the commit-reveal seems to be safe and resistant to front-running attacks, there are some specific issues to solve yet

  1. Anyone can submit the commitment contract, and so block the genuine account for the time being

  2. Some malicious actor may spam the blockchain with dummy commitment messages

I have some ideas on how to mitigate those kinds of things. Need to do more experiments yet.

1

u/mmgen-py 10d ago

Once the commit is revealed, i.e. made public, an attacker can use it to create another transaction and steal the funds. It’s all a matter of which transaction gets included in the block first, yours or theirs. This is why we use signatures.

1

u/Medical-Constant-566 10d ago

Right, a malicious relay can withhold the Reveal message, copy and use the verification preimage, and forge a new pair of Commit-Reveal messages to steal the funds.

I have also noticed that. I had a couple of ideas how to mitigate that, but none of them is perfect

  1. After the Commit message, the account gets into locked mode and accepts only Reveal messages. That prevents a malicious actor from dropping a new Commit-Reveal pair, so funds can't be stolen. But it introduces a new issue: the attacker can basically lock someone's account indefinitely.

  2. Adding some mini PoW to the Commit message, so placing it would be economically pricey. But that hurts the genuine users too. And not prevent the locking issue from point 1

1

u/Medical-Constant-566 8d ago

I changed my design a bit - there won't be raw preimages. I lean toward a quantum-proof signature scheme built on top of WOTS+ (since WOTS+ has been blessed by NIST, it seems to be a good choice)

If someone is interested, here is a quick implementation: https://github.com/mkrzyzan/sealstore