From: Leo Wandersleb <lwandersleb@gmail•com>
To: Nagaev Boris <bnagaev@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
Date: Tue, 3 Jun 2025 06:19:16 +0200 [thread overview]
Message-ID: <CA+_eyec5LLsAMrVuzGFOKRd1-1Msf8Bc0Aew=f02=pJi19FLNw@mail.gmail.com> (raw)
In-Reply-To: <CAFC_Vt7z5Vj=r90J8RoH3sC5592BO4G9U3L9gdcX+D3DruC1PQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5954 bytes --]
Hi Nagaev,
yes, you are right. The poison pill variant would be a hard fork and
ultimately require post quantum address types but it would allow to prepare
for it even now as you could at the cost of one hash protect all exposed
public keys.against slower brute force attacks as in Tadge's proposal.
With QC further advancement to quick and cheap attacks, Tadge's soft fork
could work with these commitments even protecting now exposed public keys
if the soft fork would require the commitments for those to be old - pre
soft fork for example. But those worried more about confiscations than
about a massively disruptive quantum gold rush might prefer the hard fork
poison pill variant as it would allow protecting exposed keys somewhat.
On Tue, 3 Jun 2025, 01:12 Nagaev Boris, <bnagaev@gmail•com> wrote:
> Hi Leo,
>
> Thanks for sharing your proposal, a very interesting approach! I have
> a few questions and comments:
>
> > Users create and sign transactions moving their funds to quantum-safe
> addresses
> > 1. **No consensus changes needed now** - Users can start protecting
> themselves
> > immediately
>
> How would users prepare transactions moving funds to quantum-safe
> addresses now, before such address types exist? We would need to know
> the structure of a quantum-safe address to create the transaction.
> Either an existing address type would need to support some form of
> quantum protection already (e.g., WOTS implemented via BitVM), or we
> would still need a softfork to introduce a new address type.
>
> Additionally, a future softfork (or possibly a hardfork, see below)
> would still be required to enforce the new spending rules.
>
> > - If attacked, the victim can reveal the commitment to execute the
> recovery
> > transaction
>
> Wouldn't such a recovery transaction require a hardfork? As far as I
> understand, it wouldn't be valid under current consensus rules.
> Enabling it would require relaxing existing rules, which would imply a
> hardfork.
>
> Best,
> Boris
>
> On Mon, Jun 2, 2025 at 6:12 PM Leo Wandersleb <lwandersleb@gmail•com>
> wrote:
> >
> > 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
> .
>
>
>
> --
> Best regards,
> Boris Nagaev
>
--
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/CA%2B_eyec5LLsAMrVuzGFOKRd1-1Msf8Bc0Aew%3Df02%3DpJi19FLNw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7361 bytes --]
next prev parent reply other threads:[~2025-06-03 8:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-02 21:06 Leo Wandersleb
2025-06-02 23:11 ` Nagaev Boris
2025-06-03 4:19 ` Leo Wandersleb [this message]
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='CA+_eyec5LLsAMrVuzGFOKRd1-1Msf8Bc0Aew=f02=pJi19FLNw@mail.gmail.com' \
--to=lwandersleb@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=bnagaev@gmail$(echo .)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