public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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; 14+ 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] 14+ 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
                2025-06-05  8:18               ` Leo Wandersleb
                0 siblings, 1 reply; 14+ 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] 14+ messages in thread

            • • * Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
                  2025-06-04 18:38             ` Boris Nagaev
                @ 2025-06-05  8:18               ` Leo Wandersleb
                  2025-06-05 14:54                 ` Boris Nagaev
                  2025-06-05 15:01                 ` 'conduition' via Bitcoin Development Mailing List
                  0 siblings, 2 replies; 14+ messages in thread
                From: Leo Wandersleb @ 2025-06-05  8:18 UTC (permalink / raw)
                  To: Bitcoin Development Mailing List
                
                
                [-- Attachment #1.1: Type: text/plain, Size: 9897 bytes --]
                
                Hi Boris, hi list,
                
                I think the weak announcement is a bad idea once EC crypto is broken to the 
                point where an attacker can break the key before the transaction gets mined 
                but the strong announcements should still hold as they have less urgency. 
                If the attacker sees the transaction in a strong announcement with a full 
                transaction, he cannot win even if he gets into a block first, as the 
                strong announcement proves a prior commitment to that transaction and would 
                win even if it gets mined only some blocks later.
                
                A scheme where the announcement does not contain the full transaction is 
                problematic as the transaction might then turn out to not be valid. Then 
                nodes would wait for the "winning" wtxid blocking the UTXO forever.
                
                So the scheme is:
                
                After activation at block height X:
                
                1. **Vulnerable UTXOs cannot be spent directly** - they require a prior 
                announcement 
                2. **Commitment** to a wTXID that spends the vulnerable UTXO. Multiple 
                wTXIDs can be stored in a hash tree in an OP_RETURN
                3. **Reveal** full transaction with proof of prior commitment but not as a 
                normal transaction yet
                4. **Counter Reveal**: For 144 blocks, others can reveal older commitments. 
                This protects exposed pubkeys!
                5. **After 144 blocks**: The UTXO can be spent according to the strongest 
                announcement (oldest commitment of valid transaction wins).
                
                As (5) is just the normal transaction, the scheme is a soft fork and 
                compatible with pre-recorded transactions where the keys were lost. It 
                would at least double the on-chain costs for these vulnerable UTXOs as they 
                would have to store the full transaction twice. We can make the 
                announcements prunable again though.
                
                Best,
                
                Leo
                On Wednesday, 4 June 2025 at 20:40:32 UTC+2 Boris Nagaev wrote:
                
                > 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/ea71bbd5-1325-445b-977f-a52b8017eab4n%40googlegroups.com.
                
                [-- Attachment #1.2: Type: text/html, Size: 11407 bytes --]
                
                ^ permalink raw reply	[flat|nested] 14+ messages in thread

              • • * Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
                    2025-06-05  8:18               ` Leo Wandersleb
                  @ 2025-06-05 14:54                 ` Boris Nagaev
                    2025-06-05 15:01                 ` 'conduition' via Bitcoin Development Mailing List
                    1 sibling, 0 replies; 14+ messages in thread
                  From: Boris Nagaev @ 2025-06-05 14:54 UTC (permalink / raw)
                    To: Bitcoin Development Mailing List
                  
                  
                  [-- Attachment #1.1: Type: text/plain, Size: 11604 bytes --]
                  
                  Hi Leo, hi list,
                  
                  You raise a valid point that a wTXID coming from a quantum attacker could 
                  be invalid, and the scheme must be robust against this. In this scenario, 
                  the attacker is not motivated by profit but rather by the desire to harm 
                  the legitimate owner.
                  
                  I think we do not need to include a full transaction in the announcement to 
                  address this.
                  
                  I propose the following scheme. There is just one announcement type, which 
                  was defined as a weak proof in my previous message. An announcement 
                  includes the UTXO, wTXID, and a proof (tagged_hash(EC public key || 
                  wTXID)). This tuple can be stored in an OP_RETURN output. The rule of a 
                  hypothetical soft fork would be: to spend an EC output, there must be an 
                  announcement with the corresponding wTXID and a valid proof published at 
                  least X blocks earlier.
                  
                  This design prevents an attacker from maliciously blocking someone else's 
                  coin. There is no "earliest announcement wins" rule. Any valid announcement 
                  wins once it is sufficiently buried. If an attacker publishes an invalid 
                  announcement, the legitimate owner can simply publish their own and wait X 
                  blocks before sweeping the funds. If they have already published an 
                  announcement (as they should), they can use it without delay.
                  
                  The scheme also preserves Satoshi's privacy: anyone can publish an 
                  announcement for Satoshi's coins, but without the actual spending 
                  transaction, nobody can tell whether the announcement is valid.
                  
                  A downside of the scheme is that all announcements must be stored by nodes 
                  until the corresponding UTXO is spent, and there can be multiple 
                  announcements for a single coin. Another downside is that announcements 
                  cannot be packed into a Merkle root, because the UTXO must be visible for 
                  Satoshi to identify his coins, and he must be able to verify the proof. 
                  Perhaps there are ways to improve the scheme to address these efficiency 
                  issues.
                  
                  Best,
                  Boris
                  
                  On Thursday, June 5, 2025 at 9:55:34 AM UTC-3 Leo Wandersleb wrote:
                  
                  Hi Boris, hi list,
                  
                  I think the weak announcement is a bad idea once EC crypto is broken to the 
                  point where an attacker can break the key before the transaction gets mined 
                  but the strong announcements should still hold as they have less urgency. 
                  If the attacker sees the transaction in a strong announcement with a full 
                  transaction, he cannot win even if he gets into a block first, as the 
                  strong announcement proves a prior commitment to that transaction and would 
                  win even if it gets mined only some blocks later.
                  
                  A scheme where the announcement does not contain the full transaction is 
                  problematic as the transaction might then turn out to not be valid. Then 
                  nodes would wait for the "winning" wtxid blocking the UTXO forever.
                  
                  So the scheme is:
                  
                  After activation at block height X:
                  
                  1. **Vulnerable UTXOs cannot be spent directly** - they require a prior 
                  announcement 
                  2. **Commitment** to a wTXID that spends the vulnerable UTXO. Multiple 
                  wTXIDs can be stored in a hash tree in an OP_RETURN
                  3. **Reveal** full transaction with proof of prior commitment but not as a 
                  normal transaction yet
                  4. **Counter Reveal**: For 144 blocks, others can reveal older commitments. 
                  This protects exposed pubkeys!
                  5. **After 144 blocks**: The UTXO can be spent according to the strongest 
                  announcement (oldest commitment of valid transaction wins).
                  
                  As (5) is just the normal transaction, the scheme is a soft fork and 
                  compatible with pre-recorded transactions where the keys were lost. It 
                  would at least double the on-chain costs for these vulnerable UTXOs as they 
                  would have to store the full transaction twice. We can make the 
                  announcements prunable again though.
                  
                  Best,
                  
                  Leo
                  On Wednesday, 4 June 2025 at 20:40:32 UTC+2 Boris Nagaev wrote:
                  
                  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/2ed6d831-d87d-44f0-82b9-c8b9abaa8010n%40googlegroups.com.
                  
                  [-- Attachment #1.2: Type: text/html, Size: 13421 bytes --]
                  
                  ^ permalink raw reply	[flat|nested] 14+ messages in thread

                • * Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
                    2025-06-05  8:18               ` Leo Wandersleb
                    2025-06-05 14:54                 ` Boris Nagaev
                  @ 2025-06-05 15:01                 ` 'conduition' via Bitcoin Development Mailing List
                    1 sibling, 0 replies; 14+ messages in thread
                  From: 'conduition' via Bitcoin Development Mailing List @ 2025-06-05 15:01 UTC (permalink / raw)
                    To: Leo Wandersleb; +Cc: Bitcoin Development Mailing List
                  
                  
                  [-- Attachment #1.1: Type: text/plain, Size: 11699 bytes --]
                  
                  Hi Leo,
                  
                  When a user reveals a transaction + commitment proof, are you
                  assuming it will be included in a block? Or is the reveal TX
                  somehow put "on ice" for those 144 blocks, and only then mined? 
                  
                  
                  If the former, this implies your protocol would need to allow
                  double-spending of UTXOs even after many confirmations, as
                  Tim has noted. Otherwise having an older announcement wouldn't
                  give any advantage. I don't see how you'd implement this without
                  breaking many founding assumptions of Bitcoin, maybe introducing
                  some new special "confirmed-but-pending" state specifically
                  for the outputs of these reveal TXs.
                  
                  If the latter, and the TX isn't immediately mineable, then how
                  exactly do nodes know when to consider it consensus-valid?
                  Imagine you're a node and you receive a reveal transaction
                  with a valid (old enough) commitment proof. The TX claims
                  to have been created 144 blocks ago and thus should be
                  mineable. But how do you verify that, if the TX wasn't
                  included in a past block?
                  
                  regards,
                  conduition
                  
                  On Thursday, June 5th, 2025 at 7:55 AM, Leo Wandersleb <lwandersleb@gmail•com> wrote:
                  
                  > Hi Boris, hi list,
                  > I think the weak announcement is a bad idea once EC crypto is broken to the point where an attacker can break the key before the transaction gets mined but the strong announcements should still hold as they have less urgency. If the attacker sees the transaction in a strong announcement with a full transaction, he cannot win even if he gets into a block first, as the strong announcement proves a prior commitment to that transaction and would win even if it gets mined only some blocks later.
                  > 
                  
                  > A scheme where the announcement does not contain the full transaction is problematic as the transaction might then turn out to not be valid. Then nodes would wait for the "winning" wtxid blocking the UTXO forever.
                  > 
                  
                  > So the scheme is:
                  > 
                  
                  > After activation at block height X:
                  > 
                  
                  > 1. **Vulnerable UTXOs cannot be spent directly** - they require a prior announcement
                  > 2. **Commitment** to a wTXID that spends the vulnerable UTXO. Multiple wTXIDs can be stored in a hash tree in an OP_RETURN
                  > 3. **Reveal** full transaction with proof of prior commitment but not as a normal transaction yet
                  > 4. **Counter Reveal**: For 144 blocks, others can reveal older commitments. This protects exposed pubkeys!
                  > 5. **After 144 blocks**: The UTXO can be spent according to the strongest announcement (oldest commitment of valid transaction wins).
                  > 
                  
                  > As (5) is just the normal transaction, the scheme is a soft fork and compatible with pre-recorded transactions where the keys were lost. It would at least double the on-chain costs for these vulnerable UTXOs as they would have to store the full transaction twice. We can make the announcements prunable again though.
                  > 
                  
                  > Best,
                  > 
                  
                  > Leo
                  > On Wednesday, 4 June 2025 at 20:40:32 UTC+2 Boris Nagaev wrote:
                  > 
                  
                  > > 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/ea71bbd5-1325-445b-977f-a52b8017eab4n%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/dupr0g-yupBxLl70WyuEcfAIt1DNXZDY6Z_RuhZsKwAQro1aONB8IIWcsAjytBQjsDmlXsoDjBNI5KEaMqfzqIWLvrXY60gLKxy4n9wKzQg%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] 14+ messages in thread

end of thread, other threads:[~2025-06-05 15:10 UTC | newest]

Thread overview: 14+ 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
2025-06-05  8:18               ` Leo Wandersleb
2025-06-05 14:54                 ` Boris Nagaev
2025-06-05 15:01                 ` 'conduition' via Bitcoin Development Mailing List

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox