From: Leo Wandersleb <lwandersleb@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
Date: Mon, 2 Jun 2025 23:06:35 +0200 [thread overview]
Message-ID: <2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a@gmail.com> (raw)
Hi all,
I'd like to propose a variant of the commit/reveal schemes being discussed for
quantum resistance, but with a different goal and timeline. This builds on ideas
from the recent thread "Post-Quantum commit / reveal Fawkescoin variant as a
soft fork" but targets a different use case.
## The Problem
Current discussions focus on emergency reactive measures - what to do *after*
quantum computers arrive. But this leaves users in a difficult position:
1. They can't prove ownership of their coins without revealing pubkeys (and thus
becoming vulnerable)
2. Moving coins to quantum-safe addresses early reveals which addresses are
active vs. abandoned
3. There's no way to prepare for migration without exposing yourself
## Pre-emptive Commit/Reveal
What if users could commit *today* to future migration transactions, without
revealing which UTXOs they control?
The idea is simple:
- Users create and sign transactions moving their funds to quantum-safe addresses
- They compute a Merkle tree of all these transactions
- They publish only the root hash (e.g., in an OP_RETURN)
- This can be done today, with no consensus changes
If/when quantum computers become a threat:
- We soft fork to require at least n confirmations on quantum vulnerable
transactions
- Transactions work as always but can't be spent for n blocks
- If attacked, the victim can reveal the commitment to execute the recovery
transaction
## Key Advantages
1. **No consensus changes needed now** - Users can start protecting themselves
immediately
2. **Privacy preserved** - The commitment reveals nothing about which UTXOs you own
3. **Efficient** - One hash can commit to migrations for all your UTXOs or even
the UTXOs of several users
4. **Flexible** - Works whether or not a quantum computer ever actually appears
## Differences from Tadge's Proposal
While Tadge's proposal solves post-quantum spending where any pubkey reveal is
dangerous, this proposal is about preparation:
- **Timing**: Pre-quantum (can start now) vs. post-quantum (activates after QC
appears)
- **Scope**: Migration to quantum-safe addresses for all address types in the
worst case vs. general spending of hashed pubkeys
Both use the same cryptographic primitive (commit/reveal) but for different
phases of the quantum transition.
This approach lets users protect their funds without waiting for consensus
changes or revealing their holdings. It's a "poison pill" against quantum
attackers - they might steal coins, but pre-committed owners can reclaim them.
Would love to hear thoughts on this approach.
Leo Wandersleb
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a%40gmail.com.
next reply other threads:[~2025-06-02 21:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-02 21:06 Leo Wandersleb [this message]
2025-06-02 23:11 ` Nagaev Boris
2025-06-03 4:19 ` Leo Wandersleb
2025-06-03 11:51 ` Leo Wandersleb
2025-06-03 15:15 ` 'conduition' via Bitcoin Development Mailing List
2025-06-03 17:26 ` Leo Wandersleb
2025-06-03 19:49 ` Tim Ruffing
2025-06-04 17:14 ` Leo Wandersleb
2025-06-03 21:49 ` Nagaev Boris
2025-06-04 17:39 ` Leo Wandersleb
2025-06-04 18:38 ` Boris Nagaev
2025-06-05 8:18 ` Leo Wandersleb
2025-06-05 14:54 ` Boris Nagaev
2025-06-05 15:01 ` 'conduition' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a@gmail.com \
--to=lwandersleb@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox