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

[Leo Wandersleb <lwandersleb@gmail.com>]

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