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

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

[Leo Wandersleb]

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.

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

[Nagaev Boris]

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.

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

[Leo Wandersleb]

[-- 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 --]

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

[Leo Wandersleb]

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.

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

['conduition' via 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 --]

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

[Leo Wandersleb]

[-- 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 --]

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

[Tim Ruffing]

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.

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

[Nagaev Boris]

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.

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

[Leo Wandersleb]

[-- 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 --]

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

[Leo Wandersleb]

[-- 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 --]

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

[Boris Nagaev]

[-- 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 --]