Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)

["'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>]

[-- Attachment #1.1: Type: text/plain, Size: 9383 bytes --]

Hey Leo, thanks for your ideas. I do see a couple issues though.

A prospective Quantum attacker could trivially break your scheme
as follows:

- Enumerate the entire UTXO set.
- Create a transaction to steal each available P2WPKH/P2TR UTXO one by one.
- Commit to all of those transactions' IDs in one big merkle root OP_RETURN.
- Repeat occasionally as the UTXO set changes.

This would give the QC attacker a valid pre-emptive commitment,
same as any honest user. It is possible because anyone can create
a valid unsigned transaction to spend a segwit UTXO without
knowing the pubkey. Segwit inputs don't include the witness
data (pubkeys, signatures) in the TXID.

I think instead you should commit to the witness TXIDs (wTXID) of
the recovery transactions, which include witness data like pubkeys
and signatures in the preimage, which the QC attacker shouldn't be
able to predict.

A second problem. An aggregated, pre-emptive commitment of the
fashion you describe would need to be updated constantly, as a
new merkle root would be needed every time you add a new UTXO
to your wallet. Rather than publishing this merkle root in your
own OP_RETURN, it'd be better for scaling if it were published
in something like OpenTimestamps, so that a majority of users
can aggregate their commitments together and save blockspace.

Finally a question: Why do we need to "require at least n
confirmations on quantum vulnerable transactions"? By the
way, I'm assuming here you mean that quantum vulnerable
UTXOs can only be spent after n blocks, like OP_CSV style.
Can you help me see why that helps here?

In my mind, the only thing we need a time-delay on is the
commitment opening. The commitment merkle root must be old
enough when opened to ensure the QC attacker couldn't have
forged one after learning a victim's pubkey.

regards,
conduition




On Tuesday, June 3rd, 2025 at 6:00 AM, Leo Wandersleb <lwandersleb@gmail.com> wrote:

> Hi Boris,
> 

> Actually, I think the poison pill approach could be implemented as a soft fork
> after all, with a cleaner mechanism:
> 

> After activation at block height X:
> 

> 1. Vulnerable UTXOs cannot be spent directly - they require a prior announcement
> 2. Weak announcement with no private key needed: "I intend to spend UTXO A
> with transaction X after block B+144"
> 3. Strong announcement with a commitment proof: References a potentially
> old, pre-fork commitment and provides proof that this UTXO was included
> 4. After 144 blocks: The UTXO can be spent according to the strongest
> announcement (oldest commitment wins)
> 

> This is a soft fork because:
> - We're not "undoing" transactions
> - We're adding new rules about when certain UTXOs can be spent
> - Old nodes still see valid transactions, just with different timing
> 

> The key insight is that the "weak announcement" doesn't require private keys -
> it just declares intent. This preserves the validity of pre-signed transactions
> (they can still be announced and executed, just with a delay).
> 

> Meanwhile, anyone who created commitments before the fork can use "strong
> announcements" to override potential quantum attackers during the window.
> 

> This gives us poison pill protection while maintaining backward compatibility.
> No transaction reversal needed - just a new spending process for vulnerable UTXOs.
> 

> Does this address your hard fork concern?
> 

> ---
> 

> This formulation avoids implementation details while focusing on the conceptual
> mechanism that makes it a soft fork rather than a hard fork.
> 

> On 6/3/25 01:11, Nagaev Boris 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.
> 

> 

> --
> 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/33f67e84-5d1c-4c14-80b9-90a3fec3cb36%40gmail.com.

-- 
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/ZmYpRwmVDoJBUhiCRb909Lgwws_dT9d_CNUjfddVt128pyjdH0UcYfXgA_uguwRu44ZC8_x_SwlrooqKhyvdwJjnO1h3BvzQxVRbdCpVfjg%3D%40proton.me.

[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]