From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 04 Jun 2025 10:40:42 -0700 Received: from mail-yb1-f189.google.com ([209.85.219.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uMs6T-0007Pw-25 for bitcoindev@gnusha.org; Wed, 04 Jun 2025 10:40:42 -0700 Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-e7b4e43d31asf188941276.1 for ; Wed, 04 Jun 2025 10:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749058835; x=1749663635; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=VJXCCXD99NFnOX44pFd8oLr0E9GR4Wev6Uyu095Q48Q=; b=Dk5YbMrgKMqR13+U8APSF3qGz6iltH3Sv3dZiHkHh0GQMaYE71r01s7GxWf25k0a4z R6ogjeeGQA/IGL02NRl7AXII2Ez/WA6nvkXeas+1MqTFlFqTwYT55mFIHVxelkCm3hiq jX6cAWWk9+N9SACK/U+HjYfCMmScSaOUMM6WS4zoZaUeeCbcjPlZpv8re7pVDQSVFFzw 7VR30Q2lO5XUDwhdyIhPro3JFvnNu9N/wNN30zgg91Q6Nfa44ENDUuLEK5jezeumE1Vp NHHTHm3MKU/UulGbxoJRl+u6epUZXIm+Pw/pLqqbn5fkxlQ2i9f5JZK/lMProAkU4cLT oTcQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749058835; x=1749663635; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=VJXCCXD99NFnOX44pFd8oLr0E9GR4Wev6Uyu095Q48Q=; b=WyF2xQ9JwtXFMRUr7SK0JP7xVbyvF/JsQdzfSqY65zwx3GkqGyZ1EBeX0AO9KnqyI3 fFfIDylREA5pufSoWKa/4RIHyfMFtTS/tN9KVOFf7EGqN9KrOGzhwWeggg/m1W0fRine T2j6e1aO2nWqNSm1fLhzIyfEaXM1KbgUWCtiVAQk9HTruDTOiAq9fzMAtBfhThIL8wBg 2v5Mnsmc+drZdYeHCmmphy2PCpV3z60agYBL4OdiaxRC8Kl4nggpaBqgqWOaJ7kAf0L6 zzutWfOM9SRh8tbpxhmWfbbbytMCHLC58CQgrD3WOigLP6YZln7HP7m2CcSHVyFapF+s ajdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749058835; x=1749663635; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=VJXCCXD99NFnOX44pFd8oLr0E9GR4Wev6Uyu095Q48Q=; b=DA6eTYxLlB2buaPrpytCRPcpASsBhWbB4mGPK+sRG75jPtfUPP/6o0AjRdbgiieJXt 26AK6G3Ezub96cj6NdE7LY/58tqwfPvsXHQ67s7kdzx8+LYk7A3gWcIoRY+m+L8rrwur Rj+ceYe/15esdYY1IfD+MZAigpESVeKWbla/5eQt+nDGb/w4JPT2HZ5ynlAQnfOJaZND AxVdi24En0QdYar9rKornmEifLGd4kMrTwLI9CYJIrkzUnmQo7mP0Ud7gCsojYeVvly/ wrmAa3hctT/1PyUksyxO7OkhP22YCWwSVN4QBVqrr+CFcvTXheBkxxx8p/BzTDdRMWzR YbAA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWTGwkacCs7tmV1wVv32aKiEaPgs8xomevfyNgSgXL6tSoPk7SKEi1MHh0nKZ4gAYV3DgOM6PvkdYDb@gnusha.org X-Gm-Message-State: AOJu0Yx60iVUh0SKn3QQhEEGI2iQzTRADmpoeKkdyB6APuH7BlrLj0WI glDWaVZ7uWDBosd+Opgs0DMucBytqPqvkthLV/lhR7/DH6hX9iDXZfu7 X-Google-Smtp-Source: AGHT+IHAnohFZGELEbsTHkjGCK/yXjdY2iSRMg17us2xBP2PhesPpy8ZZfVnDMBXEVotoN2akG6ofA== X-Received: by 2002:a05:6902:2b10:b0:e81:75da:d7d8 with SMTP id 3f1490d57ef6-e8179d8f1demr4825550276.44.1749058835128; Wed, 04 Jun 2025 10:40:35 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZclIQHNzOs6MVXHfyi5l2KjcRf9htkMaHHlm9nbwfqj8A== Received: by 2002:a25:ce94:0:b0:e7d:c4d4:b14b with SMTP id 3f1490d57ef6-e81889110cbls50740276.0.-pod-prod-09-us; Wed, 04 Jun 2025 10:40:31 -0700 (PDT) X-Received: by 2002:a05:690c:4988:b0:70e:d35:fbf5 with SMTP id 00721157ae682-710d9de0756mr51362937b3.35.1749058831610; Wed, 04 Jun 2025 10:40:31 -0700 (PDT) Received: by 2002:a05:690c:243:b0:70e:2cf8:9db8 with SMTP id 00721157ae682-710d716ada7ms7b3; Wed, 4 Jun 2025 10:14:59 -0700 (PDT) X-Received: by 2002:a05:690c:6a0b:b0:70d:f47a:7e21 with SMTP id 00721157ae682-710d99f46aemr52887507b3.1.1749057298797; Wed, 04 Jun 2025 10:14:58 -0700 (PDT) Date: Wed, 4 Jun 2025 10:14:58 -0700 (PDT) From: Leo Wandersleb To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a@gmail.com> <33f67e84-5d1c-4c14-80b9-90a3fec3cb36@gmail.com> <5e393f57-ac87-40fd-93ef-e1006accdb55n@googlegroups.com> Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_66486_1375114074.1749057298495" X-Original-Sender: LWandersleb@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_66486_1375114074.1749057298495 Content-Type: multipart/alternative; boundary="----=_Part_66487_1589012726.1749057298495" ------=_Part_66487_1589012726.1749057298495 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_66487_1589012726.1749057298495 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tim,

thanks for your question. To be a soft fork, i= t would have to avoid double-spends as interpreted by legacy nodes. This ca= n be achieved by the announcements not being transactions but merely announ= cements or OP_RETURNS as far as legacy nodes are concerned. After the 144 b= locks, 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.

B= est,

Leo

On Tuesday, 3 June 2025 at 22:1= 0:02 UTC+2 Tim Ruffing wrote:
What about this attack?

1. (Honestly) own some UTXO=20
2. Commit the UTXO
3. Wait for the fork
4. Spend the UTXO to some recipient
5. Double-spend using the pre-fork commitment=20

On Tue, 2025-06-03 at 10:26 -0700, Leo Wandersleb wrote:
> Hi conduition,
>=20
> Thanks for your careful analysis - excellent catches.
>=20
> You're absolutely right about the txid vulnerability. The comm= itment
> 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 inde= ed
> enumerate the UTXO set and create commitments without knowing the
> private keys.
>=20
> 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 (sa= y,
> monthly) rather than after every transaction. The scheme is
> particularly important for existing UTXOs that already have expose= d
> 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 prov= ide
> plausible deniability about the number of UTXOs being protected.
>=20
> The time delay serves a different purpose than you might expect. I= t's
> not about preventing commitment forgery after pubkey exposure, but
> rather about allowing priority based on commitment age when multip= le
> parties claim the same UTXO:
>=20
> 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
>=20
> 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 "lo= st"
> UTXOs risky - hence less disruptive to the network.
>=20
> The delay essentially allows a "commitment priority contest&q= uot; where
> age determines the winner, protecting users who prepared early whi= le
> still allowing these users to not move their funds.
>=20
> Best,
>=20
> Leo
> --=20
> 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 bitcoi= ndev+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgi= d/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.com
> .

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/dba216d2-2b69-46e4-bfd9-a3a121b35866n%40googlegroups.com.
------=_Part_66487_1589012726.1749057298495-- ------=_Part_66486_1375114074.1749057298495--