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
> .