* [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
@ 2025-06-02 21:06 Leo Wandersleb
2025-06-02 23:11 ` Nagaev Boris
0 siblings, 1 reply; 11+ messages in thread
From: Leo Wandersleb @ 2025-06-02 21:06 UTC (permalink / raw)
To: Bitcoin Development Mailing List
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
2025-06-02 21:06 [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill) Leo Wandersleb
@ 2025-06-02 23:11 ` Nagaev Boris
2025-06-03 4:19 ` Leo Wandersleb
2025-06-03 11:51 ` Leo Wandersleb
0 siblings, 2 replies; 11+ messages in thread
From: Nagaev Boris @ 2025-06-02 23:11 UTC (permalink / raw)
To: Leo Wandersleb; +Cc: Bitcoin Development Mailing List
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/CAFC_Vt7z5Vj%3Dr90J8RoH3sC5592BO4G9U3L9gdcX%2BD3DruC1PQ%40mail.gmail.com.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
2025-06-02 23:11 ` Nagaev Boris
@ 2025-06-03 4:19 ` Leo Wandersleb
2025-06-03 11:51 ` Leo Wandersleb
1 sibling, 0 replies; 11+ messages in thread
From: Leo Wandersleb @ 2025-06-03 4:19 UTC (permalink / raw)
To: Nagaev Boris; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
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
1 sibling, 1 reply; 11+ messages in thread
From: Leo Wandersleb @ 2025-06-03 11:51 UTC (permalink / raw)
To: Nagaev Boris; +Cc: Bitcoin Development Mailing List
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
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
0 siblings, 1 reply; 11+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2025-06-03 15:15 UTC (permalink / raw)
To: Leo Wandersleb; +Cc: Nagaev Boris, Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
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-03 21:49 ` Nagaev Boris
0 siblings, 2 replies; 11+ messages in thread
From: Leo Wandersleb @ 2025-06-03 17:26 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2331 bytes --]
Hi conduition,
Thanks for your careful analysis - excellent catches.
You're absolutely right about the txid vulnerability. The commitment must
be to the complete transaction including witness data (wTXID or equivalent)
to prevent an attacker from pre-committing to unsigned transactions. This
is essential - otherwise an attacker could indeed enumerate the UTXO set
and create commitments without knowing the private keys.
Regarding updates: You're correct that frequent updates would be needed as
wallets receive new UTXOs. However, I don't see this as a major issue -
users could batch their commitments periodically (say, monthly) rather than
after every transaction. The scheme is particularly important for existing
UTXOs that already have exposed pubkeys (old P2PK, reused addresses, etc.).
For new UTXOs, wallets should ideally migrate to quantum-safe addresses
once available. OpenTimestamps aggregation would indeed help with scaling
and provide plausible deniability about the number of UTXOs being protected.
The time delay serves a different purpose than you might expect. It's not
about preventing commitment forgery after pubkey exposure, but rather about
allowing priority based on commitment age when multiple parties claim the
same UTXO:
1. Weak announcement starts the 144-block window
2. During this window, anyone with a strong commitment can reveal it
3. The oldest valid commitment wins
This creates the "poison pill" effect: an attacker might crack a key and
try to spend a UTXO, but if the original owner has an older commitment,
they can reclaim it during the window. The uncertainty about which UTXOs
have poison pills makes attacking large "lost" UTXOs risky - hence less
disruptive to the network.
The delay essentially allows a "commitment priority contest" where age
determines the winner, protecting users who prepared early while still
allowing these users to not move their funds.
Best,
Leo
--
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/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2680 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
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
1 sibling, 1 reply; 11+ messages in thread
From: Tim Ruffing @ 2025-06-03 19:49 UTC (permalink / raw)
To: Leo Wandersleb, Bitcoin Development Mailing List
What about this attack?
1. (Honestly) own some UTXO
2. Commit the UTXO
3. Wait for the fork
4. Spend the UTXO to some recipient
5. Double-spend using the pre-fork commitment
On Tue, 2025-06-03 at 10:26 -0700, Leo Wandersleb wrote:
> Hi conduition,
>
> Thanks for your careful analysis - excellent catches.
>
> You're absolutely right about the txid vulnerability. The commitment
> must be to the complete transaction including witness data (wTXID or
> equivalent) to prevent an attacker from pre-committing to unsigned
> transactions. This is essential - otherwise an attacker could indeed
> enumerate the UTXO set and create commitments without knowing the
> private keys.
>
> Regarding updates: You're correct that frequent updates would be
> needed as wallets receive new UTXOs. However, I don't see this as a
> major issue - users could batch their commitments periodically (say,
> monthly) rather than after every transaction. The scheme is
> particularly important for existing UTXOs that already have exposed
> pubkeys (old P2PK, reused addresses, etc.). For new UTXOs, wallets
> should ideally migrate to quantum-safe addresses once available.
> OpenTimestamps aggregation would indeed help with scaling and provide
> plausible deniability about the number of UTXOs being protected.
>
> The time delay serves a different purpose than you might expect. It's
> not about preventing commitment forgery after pubkey exposure, but
> rather about allowing priority based on commitment age when multiple
> parties claim the same UTXO:
>
> 1. Weak announcement starts the 144-block window
> 2. During this window, anyone with a strong commitment can reveal it
> 3. The oldest valid commitment wins
>
> This creates the "poison pill" effect: an attacker might crack a key
> and try to spend a UTXO, but if the original owner has an older
> commitment, they can reclaim it during the window. The uncertainty
> about which UTXOs have poison pills makes attacking large "lost"
> UTXOs risky - hence less disruptive to the network.
>
> The delay essentially allows a "commitment priority contest" where
> age determines the winner, protecting users who prepared early while
> still allowing these users to not move their funds.
>
> Best,
>
> Leo
> --
> 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/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.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/bb0cb7ad140e0960b55a6f18c48f047cb42d6b0a.camel%40timruffing.de.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
2025-06-03 17:26 ` Leo Wandersleb
2025-06-03 19:49 ` Tim Ruffing
@ 2025-06-03 21:49 ` Nagaev Boris
2025-06-04 17:39 ` Leo Wandersleb
1 sibling, 1 reply; 11+ messages in thread
From: Nagaev Boris @ 2025-06-03 21:49 UTC (permalink / raw)
To: Leo Wandersleb; +Cc: Bitcoin Development Mailing List
Hi Leo,
Thanks for the clarifications, much appreciated!
I have a couple of questions:
1. How is a weak announcement stored in the blockchain and in the UTXO set?
I assume it must be a transaction, correct? And it should somehow mark
the UTXO as planned to be spent for 144 blocks?
How would older (non-upgraded) nodes interpret a transaction
containing a weak announcement? Would they just skip over it without
any special processing?
If so, is there a problem for nodes that upgrade after the fork: would
they have to reprocess all blocks since the fork to find and index all
missed weak announcements?
2. In the case of reclaiming a UTXO after a weak announcement by an
attacker: why would the legitimate owner wait for a weak announcement
at all?
If the EC public key was already leaked, it seems they should publish
a strong announcement themselves rather than wait. If the EC public
key wasn't leaked, there's nothing to worry about even if someone
publishes a weak announcement: they are most likely bluffing, since
they wouldn't have the actual public key.
Best,
Boris
On Tue, Jun 3, 2025 at 3:29 PM Leo Wandersleb <lwandersleb@gmail•com> wrote:
>
> Hi conduition,
>
> Thanks for your careful analysis - excellent catches.
>
> You're absolutely right about the txid vulnerability. The commitment must be to the complete transaction including witness data (wTXID or equivalent) to prevent an attacker from pre-committing to unsigned transactions. This is essential - otherwise an attacker could indeed enumerate the UTXO set and create commitments without knowing the private keys.
>
> Regarding updates: You're correct that frequent updates would be needed as wallets receive new UTXOs. However, I don't see this as a major issue - users could batch their commitments periodically (say, monthly) rather than after every transaction. The scheme is particularly important for existing UTXOs that already have exposed pubkeys (old P2PK, reused addresses, etc.). For new UTXOs, wallets should ideally migrate to quantum-safe addresses once available. OpenTimestamps aggregation would indeed help with scaling and provide plausible deniability about the number of UTXOs being protected.
>
> The time delay serves a different purpose than you might expect. It's not about preventing commitment forgery after pubkey exposure, but rather about allowing priority based on commitment age when multiple parties claim the same UTXO:
>
> 1. Weak announcement starts the 144-block window
> 2. During this window, anyone with a strong commitment can reveal it
> 3. The oldest valid commitment wins
>
> This creates the "poison pill" effect: an attacker might crack a key and try to spend a UTXO, but if the original owner has an older commitment, they can reclaim it during the window. The uncertainty about which UTXOs have poison pills makes attacking large "lost" UTXOs risky - hence less disruptive to the network.
>
> The delay essentially allows a "commitment priority contest" where age determines the winner, protecting users who prepared early while still allowing these users to not move their funds.
>
> Best,
>
> Leo
>
> --
> 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/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.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/CAFC_Vt5X2qrH9EaZNoMMx8367V7iYfXiCcAfT3ED86DtM7UH6A%40mail.gmail.com.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
2025-06-03 19:49 ` Tim Ruffing
@ 2025-06-04 17:14 ` Leo Wandersleb
0 siblings, 0 replies; 11+ messages in thread
From: Leo Wandersleb @ 2025-06-04 17:14 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 3699 bytes --]
Hi Tim,
thanks for your question. To be a soft fork, it would have to avoid
double-spends as interpreted by legacy nodes. This can be achieved by the
announcements not being transactions but merely announcements or OP_RETURNS
as far as legacy nodes are concerned. After the 144 blocks, the legacy
transaction as announced would still have to be broadcast but nodes would
enforce compliance with the correct announcement. This way, legacy nodes
would never see a double-spend.
Best,
Leo
On Tuesday, 3 June 2025 at 22:10:02 UTC+2 Tim Ruffing wrote:
> What about this attack?
>
> 1. (Honestly) own some UTXO
> 2. Commit the UTXO
> 3. Wait for the fork
> 4. Spend the UTXO to some recipient
> 5. Double-spend using the pre-fork commitment
>
> On Tue, 2025-06-03 at 10:26 -0700, Leo Wandersleb wrote:
> > Hi conduition,
> >
> > Thanks for your careful analysis - excellent catches.
> >
> > You're absolutely right about the txid vulnerability. The commitment
> > must be to the complete transaction including witness data (wTXID or
> > equivalent) to prevent an attacker from pre-committing to unsigned
> > transactions. This is essential - otherwise an attacker could indeed
> > enumerate the UTXO set and create commitments without knowing the
> > private keys.
> >
> > Regarding updates: You're correct that frequent updates would be
> > needed as wallets receive new UTXOs. However, I don't see this as a
> > major issue - users could batch their commitments periodically (say,
> > monthly) rather than after every transaction. The scheme is
> > particularly important for existing UTXOs that already have exposed
> > pubkeys (old P2PK, reused addresses, etc.). For new UTXOs, wallets
> > should ideally migrate to quantum-safe addresses once available.
> > OpenTimestamps aggregation would indeed help with scaling and provide
> > plausible deniability about the number of UTXOs being protected.
> >
> > The time delay serves a different purpose than you might expect. It's
> > not about preventing commitment forgery after pubkey exposure, but
> > rather about allowing priority based on commitment age when multiple
> > parties claim the same UTXO:
> >
> > 1. Weak announcement starts the 144-block window
> > 2. During this window, anyone with a strong commitment can reveal it
> > 3. The oldest valid commitment wins
> >
> > This creates the "poison pill" effect: an attacker might crack a key
> > and try to spend a UTXO, but if the original owner has an older
> > commitment, they can reclaim it during the window. The uncertainty
> > about which UTXOs have poison pills makes attacking large "lost"
> > UTXOs risky - hence less disruptive to the network.
> >
> > The delay essentially allows a "commitment priority contest" where
> > age determines the winner, protecting users who prepared early while
> > still allowing these users to not move their funds.
> >
> > Best,
> >
> > Leo
> > --
> > 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+...@googlegroups•com.
> > To view this discussion visit
> >
> https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.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/dba216d2-2b69-46e4-bfd9-a3a121b35866n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5082 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
2025-06-03 21:49 ` Nagaev Boris
@ 2025-06-04 17:39 ` Leo Wandersleb
2025-06-04 18:38 ` Boris Nagaev
0 siblings, 1 reply; 11+ messages in thread
From: Leo Wandersleb @ 2025-06-04 17:39 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5836 bytes --]
Hi Boris,
the announcements, weak and strong would have to not be transactions yet to
be compatible with legacy nodes and thus keep it a soft-fork. They could be
OP_RETURN data. Only after the 144 blocks, the upgraded full nodes would
allow the inclusion of the actual transaction. This would mean the
transaction would be both in full in the OP_RETURN strong announcement and
without the witness part later, so it would be a bit expensive this way but
maybe we can do better?
A node that gets updated would have to re-index all the blockchain to find
announcements if we don't introduce a time frame for actually using the
announcements. We could also say that any announcement has to be used
within another 1000 blocks. Then the upgrading node would have to re-index
the last 1000 blocks.
The legitimate owner of a UTXO might wait for an attack for privacy
reasons. My proposal would allow Satoshi himself to make all his UTXOs
quantum safe without any of us learning about him being active. He could
add one 64B OP_RETURN in 2027 and when QC becomes an issue, we would learn
about him having been active in 2027 in 2040 when actually somebody tried
to attack and not in 2027 when people started to panic because of imminent
quantum breakthroughs.
Hmm ... a problem is the weak announcement doesn't require keys, so anybody
could provoke Satoshi to come forward. Maybe we have to add key ownership
as a requirement for the "weak" announcement, too. So it should also
contain a serialized transaction.
Best,
Leo
On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Boris wrote:
> Hi Leo,
>
> Thanks for the clarifications, much appreciated!
> I have a couple of questions:
>
> 1. How is a weak announcement stored in the blockchain and in the UTXO set?
> I assume it must be a transaction, correct? And it should somehow mark
> the UTXO as planned to be spent for 144 blocks?
> How would older (non-upgraded) nodes interpret a transaction
> containing a weak announcement? Would they just skip over it without
> any special processing?
> If so, is there a problem for nodes that upgrade after the fork: would
> they have to reprocess all blocks since the fork to find and index all
> missed weak announcements?
>
> 2. In the case of reclaiming a UTXO after a weak announcement by an
> attacker: why would the legitimate owner wait for a weak announcement
> at all?
> If the EC public key was already leaked, it seems they should publish
> a strong announcement themselves rather than wait. If the EC public
> key wasn't leaked, there's nothing to worry about even if someone
> publishes a weak announcement: they are most likely bluffing, since
> they wouldn't have the actual public key.
>
> Best,
> Boris
>
> On Tue, Jun 3, 2025 at 3:29 PM Leo Wandersleb <lwand...@gmail•com> wrote:
> >
> > Hi conduition,
> >
> > Thanks for your careful analysis - excellent catches.
> >
> > You're absolutely right about the txid vulnerability. The commitment
> must be to the complete transaction including witness data (wTXID or
> equivalent) to prevent an attacker from pre-committing to unsigned
> transactions. This is essential - otherwise an attacker could indeed
> enumerate the UTXO set and create commitments without knowing the private
> keys.
> >
> > Regarding updates: You're correct that frequent updates would be needed
> as wallets receive new UTXOs. However, I don't see this as a major issue -
> users could batch their commitments periodically (say, monthly) rather than
> after every transaction. The scheme is particularly important for existing
> UTXOs that already have exposed pubkeys (old P2PK, reused addresses, etc.).
> For new UTXOs, wallets should ideally migrate to quantum-safe addresses
> once available. OpenTimestamps aggregation would indeed help with scaling
> and provide plausible deniability about the number of UTXOs being protected.
> >
> > The time delay serves a different purpose than you might expect. It's
> not about preventing commitment forgery after pubkey exposure, but rather
> about allowing priority based on commitment age when multiple parties claim
> the same UTXO:
> >
> > 1. Weak announcement starts the 144-block window
> > 2. During this window, anyone with a strong commitment can reveal it
> > 3. The oldest valid commitment wins
> >
> > This creates the "poison pill" effect: an attacker might crack a key and
> try to spend a UTXO, but if the original owner has an older commitment,
> they can reclaim it during the window. The uncertainty about which UTXOs
> have poison pills makes attacking large "lost" UTXOs risky - hence less
> disruptive to the network.
> >
> > The delay essentially allows a "commitment priority contest" where age
> determines the winner, protecting users who prepared early while still
> allowing these users to not move their funds.
> >
> > Best,
> >
> > Leo
> >
> > --
> > 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+...@googlegroups•com.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.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/5d9f6ac9-a623-4636-8a91-ee7c057bc08an%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7081 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
2025-06-04 17:39 ` Leo Wandersleb
@ 2025-06-04 18:38 ` Boris Nagaev
0 siblings, 0 replies; 11+ messages in thread
From: Boris Nagaev @ 2025-06-04 18:38 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 7793 bytes --]
Hi Leo,
I think it is possible to provide privacy for Satoshi and also reduce the
size of a weak announcement (strong announcements can already be small:
just a txid or a Merkle root of many txids).
Importantly, we cannot include the whole signed transaction in the weak
announcement. Doing so would leak the EC public key immediately, allowing
an attacker to create their own valid weak announcement. We must avoid
revealing the public key until the actual spending transaction is broadcast.
We need a scheme where the EC public key is not leaked in a weak
announcement, but the legitimate owner can verify it, while no one else
can. Also, once the EC public key is revealed, anyone should be able to
verify a past weak announcement (to validate the transaction when it is
broadcast). This reduces to the following requirement: we need a proof of
knowledge of the EC public key that can be verified if the public key is
known and provides no information otherwise.
I think this is called a zero-knowledge proof. One simple approach could be
to apply a tagged hash function to the concatenation of the EC public key
and the future wTXID, and include this in the weak announcement. The
structure would be:
- UTXO (previous TXID and output index)
- future spending wTXID
- proof := tagged_hash(EC public key || wTXID)
The wTXID is included in the concatenation to bind the proof to a
particular future transaction. Otherwise, someone could copy a weak
announcement and substitute their own wTXID.
Satoshi could publish a strong announcement now and then monitor all weak
announcements involving his UTXOs. If someone publishes a weak announcement
for one of his coins, he could verify the "proof" field. If it is valid, it
would mean someone has cracked his key with a quantum computer, and he
would need to use his strong announcement immediately to reclaim the funds
before the attacker does.
Best,
Boris
On Wednesday, June 4, 2025 at 2:40:53 PM UTC-3 Leo Wandersleb wrote:
Hi Boris,
the announcements, weak and strong would have to not be transactions yet to
be compatible with legacy nodes and thus keep it a soft-fork. They could be
OP_RETURN data. Only after the 144 blocks, the upgraded full nodes would
allow the inclusion of the actual transaction. This would mean the
transaction would be both in full in the OP_RETURN strong announcement and
without the witness part later, so it would be a bit expensive this way but
maybe we can do better?
A node that gets updated would have to re-index all the blockchain to find
announcements if we don't introduce a time frame for actually using the
announcements. We could also say that any announcement has to be used
within another 1000 blocks. Then the upgrading node would have to re-index
the last 1000 blocks.
The legitimate owner of a UTXO might wait for an attack for privacy
reasons. My proposal would allow Satoshi himself to make all his UTXOs
quantum safe without any of us learning about him being active. He could
add one 64B OP_RETURN in 2027 and when QC becomes an issue, we would learn
about him having been active in 2027 in 2040 when actually somebody tried
to attack and not in 2027 when people started to panic because of imminent
quantum breakthroughs.
Hmm ... a problem is the weak announcement doesn't require keys, so anybody
could provoke Satoshi to come forward. Maybe we have to add key ownership
as a requirement for the "weak" announcement, too. So it should also
contain a serialized transaction.
Best,
Leo
On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Boris wrote:
Hi Leo,
Thanks for the clarifications, much appreciated!
I have a couple of questions:
1. How is a weak announcement stored in the blockchain and in the UTXO set?
I assume it must be a transaction, correct? And it should somehow mark
the UTXO as planned to be spent for 144 blocks?
How would older (non-upgraded) nodes interpret a transaction
containing a weak announcement? Would they just skip over it without
any special processing?
If so, is there a problem for nodes that upgrade after the fork: would
they have to reprocess all blocks since the fork to find and index all
missed weak announcements?
2. In the case of reclaiming a UTXO after a weak announcement by an
attacker: why would the legitimate owner wait for a weak announcement
at all?
If the EC public key was already leaked, it seems they should publish
a strong announcement themselves rather than wait. If the EC public
key wasn't leaked, there's nothing to worry about even if someone
publishes a weak announcement: they are most likely bluffing, since
they wouldn't have the actual public key.
Best,
Boris
On Tue, Jun 3, 2025 at 3:29 PM Leo Wandersleb <lwand...@gmail•com> wrote:
>
> Hi conduition,
>
> Thanks for your careful analysis - excellent catches.
>
> You're absolutely right about the txid vulnerability. The commitment must
be to the complete transaction including witness data (wTXID or equivalent)
to prevent an attacker from pre-committing to unsigned transactions. This
is essential - otherwise an attacker could indeed enumerate the UTXO set
and create commitments without knowing the private keys.
>
> Regarding updates: You're correct that frequent updates would be needed
as wallets receive new UTXOs. However, I don't see this as a major issue -
users could batch their commitments periodically (say, monthly) rather than
after every transaction. The scheme is particularly important for existing
UTXOs that already have exposed pubkeys (old P2PK, reused addresses, etc.).
For new UTXOs, wallets should ideally migrate to quantum-safe addresses
once available. OpenTimestamps aggregation would indeed help with scaling
and provide plausible deniability about the number of UTXOs being
protected.
>
> The time delay serves a different purpose than you might expect. It's not
about preventing commitment forgery after pubkey exposure, but rather about
allowing priority based on commitment age when multiple parties claim the
same UTXO:
>
> 1. Weak announcement starts the 144-block window
> 2. During this window, anyone with a strong commitment can reveal it
> 3. The oldest valid commitment wins
>
> This creates the "poison pill" effect: an attacker might crack a key and
try to spend a UTXO, but if the original owner has an older commitment,
they can reclaim it during the window. The uncertainty about which UTXOs
have poison pills makes attacking large "lost" UTXOs risky - hence less
disruptive to the network.
>
> The delay essentially allows a "commitment priority contest" where age
determines the winner, protecting users who prepared early while still
allowing these users to not move their funds.
>
> Best,
>
> Leo
>
> --
> 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+...@googlegroups•com.
> To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.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/44b5aa4c-a71b-49ed-beee-071140b16aacn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9084 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-06-04 18:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-06-02 21:06 [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill) Leo Wandersleb
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox