path: root/4d/4541db92152ba863c358e230d0bcd4ebf64c52

Delivery-date: Wed, 04 Jun 2025 10:41:00 -0700
Received: from mail-yb1-f192.google.com ([209.85.219.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD2IRYOX4AFRBIMKQLBAMGQE6HIKIFI@googlegroups.com>)
	id 1uMs6k-0007QR-PH
	for bitcoindev@gnusha.org; Wed, 04 Jun 2025 10:40:59 -0700
Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e7d961b8930sf242140276.1
        for <bitcoindev@gnusha.org>; Wed, 04 Jun 2025 10:40:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749058853; x=1749663653; 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=5sQTHwKJc0qn+UWbQnVD3WHy9CaYnp85iDuWL0W0RTc=;
        b=JsQYLZ8VJep9nQeOZib+OQmCh4ryRSVOHUhq/BUvUN3sbKC5yxmfypiFoTTbe2oUGt
         pbR8F1qOoj9CMjeUGXvtU7lSs5L8AB4Zifq0H+6gVnQvvlqK5U57p/iXNA3uqoZ8PlUd
         0xXYD/2NsCoSb+XB4/GyGuqf46a9PudJTbp7K2UXWFiJ1/SnlTx4QjozR0/Cerau6T3y
         HLi+nQim3kMP3/qBcwAsqkLFX0amyWN/ues2sr2a7SM7S+AlwepugdS5QoT5McXc7uPH
         tTn37dcwdlw0iifRkyghPIn09V0kXeM6bHvMX0JUSYSq3XFFRFYVEP6v1Syei5nO9f5h
         CANA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749058853; x=1749663653; 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=5sQTHwKJc0qn+UWbQnVD3WHy9CaYnp85iDuWL0W0RTc=;
        b=hNmwdhF7i7sCQnh1JbL+XJ6np8UZmzegxGzXVhkxmfP7wzYCb2U358wXODOCb0YVi2
         dVpZZnR0wNrizixYSOLQ+M4wF5Jrt8nmDVTTrAogdFiTXbEMtD3a6dvW+CIIgR0+ZlCA
         nB3lDKbKOFb/ZQ9MFYbU9E/si54H3idSAcJ1Z0R6UiMx94glkCkTPgvQqFub2Lt/KDWv
         T9aJLO2Tvdik19BBCn4SCbcg7rhCsp1pv21ah97bcSv21G3KuyjsljkECg4kA/bfb+AI
         ale8xflCVKKCGIAjSIv0znrsjclGHCdv58qs8x1IIeM3CARNFRReUlW5QEVO6H7FyVLW
         NLYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749058853; x=1749663653;
        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=5sQTHwKJc0qn+UWbQnVD3WHy9CaYnp85iDuWL0W0RTc=;
        b=cDpvZPv45GCeR9ScseLO3PQlU9N4ZMRwOetWdiX6ijOMjZ/ydkhdgi/89VKpARPRe2
         ink2uQMhzs0U8ybZOBkidUuUSpJQ+XecaCQ0+dUGTH0gCIl5Wa4Sia1fIQv7hMTe2fex
         q8WeBs6ss1fBEqDvvk6fuFwITNv/wR4/L5RwLgeJCpSIAfXVYLsiaa9J7vMjfiITIIcv
         Ur3RMebIOL7d8crJw3Mqnf7CAmSMg5sw25zXo8Oa4I97+18zn1KoO/r/psrhQOmVf4db
         23W13omIzv6kHS/rUt+66VXHqqJsTspU+UCdPDt1Soye6BSREUYgZHEYD2yOJKEFtro/
         aMFg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVDtL11AfYbcNH0WGsSzxM7vei6yr7VE0PFshjs1CT8ChfwlMMMfOioBoo9LdWh5CpoFR3WuE0SWpb/@gnusha.org
X-Gm-Message-State: AOJu0YxGI2m63GZGmueVy6tfiZQskaH9K7TqmBQ6Dzm8l4E/wx1/HDhR
	nnZGble6wcS3huqtU14BscWe8KpwiS8gPs7UhU8ULR3NRJVXnForiYr8
X-Google-Smtp-Source: AGHT+IFO+MpryWazwAoVbhknhWs6wzdQeAKgDaoChtjX7/pV8ZFVwniaY4KjfIkjqTYFRAmmxNLw5g==
X-Received: by 2002:a05:6902:2b91:b0:e81:4a97:b8dc with SMTP id 3f1490d57ef6-e8179da3539mr4975919276.48.1749058853036;
        Wed, 04 Jun 2025 10:40:53 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcketC3ziYZTBKrcWUFt9IfwSAk6K1UbuI/0L+i05bXiw==
Received: by 2002:a25:b327:0:b0:e7d:cffc:6cc with SMTP id 3f1490d57ef6-e8188a154d7ls35666276.2.-pod-prod-06-us;
 Wed, 04 Jun 2025 10:40:49 -0700 (PDT)
X-Received: by 2002:a05:690c:6502:b0:70e:1874:b914 with SMTP id 00721157ae682-710d9dbabd1mr47917157b3.9.1749058849380;
        Wed, 04 Jun 2025 10:40:49 -0700 (PDT)
Received: by 2002:a0d:d201:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-710d6e595f0ms7b3;
        Wed, 4 Jun 2025 10:39:39 -0700 (PDT)
X-Received: by 2002:a05:690c:25ca:b0:702:d85:5347 with SMTP id 00721157ae682-710da01a419mr51847067b3.36.1749058778658;
        Wed, 04 Jun 2025 10:39:38 -0700 (PDT)
Date: Wed, 4 Jun 2025 10:39:38 -0700 (PDT)
From: Leo Wandersleb <lwandersleb@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <5d9f6ac9-a623-4636-8a91-ee7c057bc08an@googlegroups.com>
In-Reply-To: <CAFC_Vt5X2qrH9EaZNoMMx8367V7iYfXiCcAfT3ED86DtM7UH6A@mail.gmail.com>
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>
 <CAFC_Vt5X2qrH9EaZNoMMx8367V7iYfXiCcAfT3ED86DtM7UH6A@mail.gmail.com>
Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_96792_2021222509.1749058778207"
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_96792_2021222509.1749058778207
Content-Type: multipart/alternative; 
	boundary="----=_Part_96793_1100570934.1749058778207"

------=_Part_96793_1100570934.1749058778207
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Boris,

the announcements, weak and strong would have to not be transactions yet to=
=20
be compatible with legacy nodes and thus keep it a soft-fork. They could be=
=20
OP_RETURN data. Only after the 144 blocks, the upgraded full nodes would=20
allow the inclusion of the actual transaction. This would mean the=20
transaction would be both in full in the OP_RETURN strong announcement and=
=20
without the witness part later, so it would be a bit expensive this way but=
=20
maybe we can do better?

A node that gets updated would have to re-index all the blockchain to find=
=20
announcements if we don't introduce a time frame for actually using the=20
announcements. We could also say that any announcement has to be used=20
within another 1000 blocks. Then the upgrading node would have to re-index=
=20
the last 1000 blocks.

The legitimate owner of a UTXO might wait for an attack for privacy=20
reasons. My proposal would allow Satoshi himself to make all his UTXOs=20
quantum safe without any of us learning about him being active. He could=20
add one 64B OP_RETURN in 2027 and when QC becomes an issue, we would learn=
=20
about him having been active in 2027 in 2040 when actually somebody tried=
=20
to attack and not in 2027 when people started to panic because of imminent=
=20
quantum breakthroughs.
Hmm ... a problem is the weak announcement doesn't require keys, so anybody=
=20
could provoke Satoshi to come forward. Maybe we have to add key ownership=
=20
as a requirement for the "weak" announcement, too. So it should also=20
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 se=
t?
> 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=E2=80=AFPM 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=20
> must be to the complete transaction including witness data (wTXID or=20
> equivalent) to prevent an attacker from pre-committing to unsigned=20
> transactions. This is essential - otherwise an attacker could indeed=20
> enumerate the UTXO set and create commitments without knowing the private=
=20
> keys.
> >
> > Regarding updates: You're correct that frequent updates would be needed=
=20
> as wallets receive new UTXOs. However, I don't see this as a major issue =
-=20
> users could batch their commitments periodically (say, monthly) rather th=
an=20
> after every transaction. The scheme is particularly important for existin=
g=20
> UTXOs that already have exposed pubkeys (old P2PK, reused addresses, etc.=
).=20
> For new UTXOs, wallets should ideally migrate to quantum-safe addresses=
=20
> once available. OpenTimestamps aggregation would indeed help with scaling=
=20
> and provide plausible deniability about the number of UTXOs being protect=
ed.
> >
> > The time delay serves a different purpose than you might expect. It's=
=20
> not about preventing commitment forgery after pubkey exposure, but rather=
=20
> about allowing priority based on commitment age when multiple parties cla=
im=20
> 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 an=
d=20
> try to spend a UTXO, but if the original owner has an older commitment,=
=20
> they can reclaim it during the window. The uncertainty about which UTXOs=
=20
> have poison pills makes attacking large "lost" UTXOs risky - hence less=
=20
> disruptive to the network.
> >
> > The delay essentially allows a "commitment priority contest" where age=
=20
> determines the winner, protecting users who prepared early while still=20
> allowing these users to not move their funds.
> >
> > Best,
> >
> > Leo
> >
> > --
> > You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e100=
6accdb55n%40googlegroups.com
> .
>
>
>
> --=20
> Best regards,
> Boris Nagaev
>

--=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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
5d9f6ac9-a623-4636-8a91-ee7c057bc08an%40googlegroups.com.

------=_Part_96793_1100570934.1749058778207
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Boris,<div><br /></div><div>the announcements, weak and strong would hav=
e to not be transactions yet to be compatible with legacy nodes and thus ke=
ep 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 transactio=
n. This would mean the transaction would be both in full in the OP_RETURN s=
trong announcement and without the witness part later, so it would be a bit=
 expensive this way but maybe we can do better?</div><div><br /></div><div>=
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 ann=
ouncements. We could also say that any announcement has to be used within a=
nother 1000 blocks. Then the upgrading node would have to re-index the last=
 1000 blocks.</div><div><br /></div><div>The legitimate owner of a UTXO mig=
ht 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 becom=
es an issue, we would learn about him having been active in 2027 in 2040 wh=
en actually somebody tried to attack and not in 2027 when people started to=
 panic because of imminent quantum breakthroughs.</div><div>Hmm ... a probl=
em 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 requiremen=
t for the "weak" announcement, too. So it should also contain a serialized =
transaction.<br /></div><div><br /></div><div>Best,</div><div><br /></div><=
div>Leo</div><div><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" =
class=3D"gmail_attr">On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Bor=
is wrote:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 =
0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi =
Leo,
<br>
<br>Thanks for the clarifications, much appreciated!
<br>I have a couple of questions:
<br>
<br>1. How is a weak announcement stored in the blockchain and in the UTXO =
set?
<br>I assume it must be a transaction, correct? And it should somehow mark
<br>the UTXO as planned to be spent for 144 blocks?
<br>How would older (non-upgraded) nodes interpret a transaction
<br>containing a weak announcement? Would they just skip over it without
<br>any special processing?
<br>If so, is there a problem for nodes that upgrade after the fork: would
<br>they have to reprocess all blocks since the fork to find and index all
<br>missed weak announcements?
<br>
<br>2. In the case of reclaiming a UTXO after a weak announcement by an
<br>attacker: why would the legitimate owner wait for a weak announcement
<br>at all?
<br>If the EC public key was already leaked, it seems they should publish
<br>a strong announcement themselves rather than wait. If the EC public
<br>key wasn&#39;t leaked, there&#39;s nothing to worry about even if someo=
ne
<br>publishes a weak announcement: they are most likely bluffing, since
<br>they wouldn&#39;t have the actual public key.
<br>
<br>Best,
<br>Boris
<br>
<br>On Tue, Jun 3, 2025 at 3:29=E2=80=AFPM Leo Wandersleb &lt;<a href data-=
email-masked rel=3D"nofollow">lwand...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt; Hi conduition,
<br>&gt;
<br>&gt; Thanks for your careful analysis - excellent catches.
<br>&gt;
<br>&gt; You&#39;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 transac=
tions. This is essential - otherwise an attacker could indeed enumerate the=
 UTXO set and create commitments without knowing the private keys.
<br>&gt;
<br>&gt; Regarding updates: You&#39;re correct that frequent updates would =
be needed as wallets receive new UTXOs. However, I don&#39;t see this as a =
major issue - users could batch their commitments periodically (say, monthl=
y) rather than after every transaction. The scheme is particularly importan=
t for existing UTXOs that already have exposed pubkeys (old P2PK, reused ad=
dresses, etc.). For new UTXOs, wallets should ideally migrate to quantum-sa=
fe addresses once available. OpenTimestamps aggregation would indeed help w=
ith scaling and provide plausible deniability about the number of UTXOs bei=
ng protected.
<br>&gt;
<br>&gt; The time delay serves a different purpose than you might expect. I=
t&#39;s not about preventing commitment forgery after pubkey exposure, but =
rather about allowing priority based on commitment age when multiple partie=
s claim the same UTXO:
<br>&gt;
<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;
<br>&gt; This creates the &quot;poison pill&quot; effect: an attacker might=
 crack a key and try to spend a UTXO, but if the original owner has an olde=
r commitment, they can reclaim it during the window. The uncertainty about =
which UTXOs have poison pills makes attacking large &quot;lost&quot; UTXOs =
risky - hence less disruptive to the network.
<br>&gt;
<br>&gt; The delay essentially allows a &quot;commitment priority contest&q=
uot; where age determines the winner, protecting users who prepared early w=
hile still allowing these users to not move their funds.
<br>&gt;
<br>&gt; Best,
<br>&gt;
<br>&gt; Leo
<br>&gt;
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@=
googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.co=
m" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Den-GB&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoind=
ev/5e393f57-ac87-40fd-93ef-e1006accdb55n%2540googlegroups.com&amp;source=3D=
gmail&amp;ust=3D1749143699445000&amp;usg=3DAOvVaw3Co40dR0HSwtm72YiXcxJx">ht=
tps://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006acc=
db55n%40googlegroups.com</a>.
<br>
<br>
<br>
<br>--=20
<br>Best regards,
<br>Boris Nagaev
<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/5d9f6ac9-a623-4636-8a91-ee7c057bc08an%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/5d9f6ac9-a623-4636-8a91-ee7c057bc08an%40googlegroups.com</a>.<br />

------=_Part_96793_1100570934.1749058778207--

------=_Part_96792_2021222509.1749058778207--