path: root/9f/ed5fdc188154f2007a0e3dd43c64e8fba19e04

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 <bitcoindev+bncBD2IRYOX4AFRBD4KQLBAMGQEVMOIWZQ@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <lwandersleb@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <dba216d2-2b69-46e4-bfd9-a3a121b35866n@googlegroups.com>
In-Reply-To: <bb0cb7ad140e0960b55a6f18c48f047cb42d6b0a.camel@timruffing.de>
References: <2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a@gmail.com>
 <CAFC_Vt7z5Vj=r90J8RoH3sC5592BO4G9U3L9gdcX+D3DruC1PQ@mail.gmail.com>
 <33f67e84-5d1c-4c14-80b9-90a3fec3cb36@gmail.com>
 <ZmYpRwmVDoJBUhiCRb909Lgwws_dT9d_CNUjfddVt128pyjdH0UcYfXgA_uguwRu44ZC8_x_SwlrooqKhyvdwJjnO1h3BvzQxVRbdCpVfjg=@proton.me>
 <5e393f57-ac87-40fd-93ef-e1006accdb55n@googlegroups.com>
 <bb0cb7ad140e0960b55a6f18c48f047cb42d6b0a.camel@timruffing.de>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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,<div><br /></div><div>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.</div><div><br /></div><div>B=
est,</div><div><br /></div><div>Leo<br /><br /></div><div class=3D"gmail_qu=
ote"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, 3 June 2025 at 22:1=
0:02 UTC+2 Tim Ruffing wrote:<br/></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); pad=
ding-left: 1ex;">What about this attack?
<br>
<br>1. (Honestly) own some UTXO=20
<br>2. Commit the UTXO
<br>3. Wait for the fork
<br>4. Spend the UTXO to some recipient
<br>5. Double-spend using the pre-fork commitment=20
<br>
<br>On Tue, 2025-06-03 at 10:26 -0700, Leo Wandersleb wrote:
<br>&gt; Hi conduition,
<br>&gt;=20
<br>&gt; Thanks for your careful analysis - excellent catches.
<br>&gt;=20
<br>&gt; You&#39;re absolutely right about the txid vulnerability. The comm=
itment
<br>&gt; must be to the complete transaction including witness data (wTXID =
or
<br>&gt; equivalent) to prevent an attacker from pre-committing to unsigned
<br>&gt; transactions. This is essential - otherwise an attacker could inde=
ed
<br>&gt; enumerate the UTXO set and create commitments without knowing the
<br>&gt; private keys.
<br>&gt;=20
<br>&gt; Regarding updates: You&#39;re correct that frequent updates would =
be
<br>&gt; needed as wallets receive new UTXOs. However, I don&#39;t see this=
 as a
<br>&gt; major issue - users could batch their commitments periodically (sa=
y,
<br>&gt; monthly) rather than after every transaction. The scheme is
<br>&gt; particularly important for existing UTXOs that already have expose=
d
<br>&gt; pubkeys (old P2PK, reused addresses, etc.). For new UTXOs, wallets
<br>&gt; should ideally migrate to quantum-safe addresses once available.
<br>&gt; OpenTimestamps aggregation would indeed help with scaling and prov=
ide
<br>&gt; plausible deniability about the number of UTXOs being protected.
<br>&gt;=20
<br>&gt; The time delay serves a different purpose than you might expect. I=
t&#39;s
<br>&gt; not about preventing commitment forgery after pubkey exposure, but
<br>&gt; rather about allowing priority based on commitment age when multip=
le
<br>&gt; parties claim the same UTXO:
<br>&gt;=20
<br>&gt; 1. Weak announcement starts the 144-block window
<br>&gt; 2. During this window, anyone with a strong commitment can reveal =
it
<br>&gt; 3. The oldest valid commitment wins
<br>&gt;=20
<br>&gt; This creates the &quot;poison pill&quot; effect: an attacker might=
 crack a key
<br>&gt; and try to spend a UTXO, but if the original owner has an older
<br>&gt; commitment, they can reclaim it during the window. The uncertainty
<br>&gt; about which UTXOs have poison pills makes attacking large &quot;lo=
st&quot;
<br>&gt; UTXOs risky - hence less disruptive to the network.
<br>&gt;=20
<br>&gt; The delay essentially allows a &quot;commitment priority contest&q=
uot; where
<br>&gt; age determines the winner, protecting users who prepared early whi=
le
<br>&gt; still allowing these users to not move their funds.
<br>&gt;=20
<br>&gt; Best,
<br>&gt;=20
<br>&gt; Leo
<br>&gt; --=20
<br>&gt; You received this message because you are subscribed to the Google
<br>&gt; Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it,
<br>&gt; send an email to <a href data-email-masked rel=3D"nofollow">bitcoi=
ndev+...@googlegroups.com</a>.
<br>&gt; To view this discussion visit
<br>&gt; <a href=3D"https://groups.google.com/d/msgid/bitcoindev/5e393f57-a=
c87-40fd-93ef-e1006accdb55n%40googlegroups.com" target=3D"_blank" rel=3D"no=
follow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den-GB&amp;q=
=3Dhttps://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e10=
06accdb55n%2540googlegroups.com&amp;source=3Dgmail&amp;ust=3D17491430760730=
00&amp;usg=3DAOvVaw0T8iaOPzbjPVPl_QPOlXjj">https://groups.google.com/d/msgi=
d/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.com</a>
<br>&gt; .
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/dba216d2-2b69-46e4-bfd9-a3a121b35866n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/dba216d2-2b69-46e4-bfd9-a3a121b35866n%40googlegroups.com</a>.<br />

------=_Part_66487_1589012726.1749057298495--

------=_Part_66486_1375114074.1749057298495--