path: root/8a/3ebec4148e62b1da66dca71ac4fc34a8f72647

Delivery-date: Thu, 05 Jun 2025 05:55:42 -0700
Received: from mail-yb1-f184.google.com ([209.85.219.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD2IRYOX4AFRBQ5HQ3BAMGQEFB42FJQ@googlegroups.com>)
	id 1uNA8C-0005Ci-GU
	for bitcoindev@gnusha.org; Thu, 05 Jun 2025 05:55:42 -0700
Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e812e1573ecsf1044103276.2
        for <bitcoindev@gnusha.org>; Thu, 05 Jun 2025 05:55:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749128134; x=1749732934; 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=zQ0OUEg42PWGpLT/ndFPGYOmUcjWeSuDXLIkv96KjGE=;
        b=pFkZ8EjrKehO8O42t25R6cidKEW02wiO9AZV6Q8wz9FM8dwUDf3hONCscGVQW7rNkk
         gkkvDPoECaTKdbKdYyCINowVgHkQFQa3DL1pGY32N+7dzS5K4D5ifHl0LN4751ZSqgYI
         PMeNPSI7Py7S1ChsfRERukUsGN6nPsnoVxrbXIR0po8VluTF7CBJrNTs760s0YvLcabn
         t0ejXPHlV9Ep6V86WU8P58rX/OlhuezCtXjPoF9M/jfRgm5BEAD0PhkDNMDy2AI02vfL
         VQWzO0nDzDlHcGKkGKO11c1f2oDamCnpltt5aEZfMfVLp+M8zVUjz5/Ra6IlDjBp5QNd
         xg6A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749128134; x=1749732934; 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=zQ0OUEg42PWGpLT/ndFPGYOmUcjWeSuDXLIkv96KjGE=;
        b=h74moNW+8mEY17oC1wUZhX/+R2Q2QPzKIdM0Zkny/zoOcC5BmYPWatU+hbIBcPpf2C
         eXu0qsYKMfF9bgKdtBu/mXReOs2jhfsY1DWlQAH2prUJgORd54+qLP7J0ZwpmxT+P2zQ
         RV7QsjWTcapEGExrTCXUEvmOnCV2I3Qv+ZWA29r6m+iMOu1Qjx5S1DSuqFO/VC/qHH3r
         s6ZXfc1ewGi0+HEapaYf6uvMQMDWhD3KdYWPOGWxNL17ty7JT+eOVWoM3m6uXN7YOg0h
         wWGdlBUr/Sh7ESrf/oESKNK00/zfU2W1+s0ERXnzHRnGaByfc3WRmBQZXLNvrpNm7o5j
         1vAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749128134; x=1749732934;
        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=zQ0OUEg42PWGpLT/ndFPGYOmUcjWeSuDXLIkv96KjGE=;
        b=SaTywWz7FgDi6oY9rMNOmk74wz/XUiPMBPFAtapAfaZFG7QKz4w4Li6CTfG7iGAB6r
         wzMfMod3AcHRPg05n6srajMhsd/iEagMIcWR8Y45kkPRcYQVhZVxBGebjgOWECGmwIgc
         B0hC8abr9f8UyMxqe7z2iBMbAqr/0riTfAiM7hZicwcvHmvq/mrzzz1KFASKux+aKxzm
         00iWQ8gqYpazSyfJl0gbSC44CzYUTnG0Tl9Ywg8a55anoIq1rdc6CY7QN+Mgh6O9IC+l
         qcAO530GDAqYesRF7Vdq32wEpfm2TKVn/HMR/b+eP0PpmL2deGMl7SztGaIVAS+ImJHI
         47xA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUD/JROPE5OC7qohY7eDW+dzghSxrRkif7l6KoLGZitjm9UY2ZuGWG3JQBWNITdVKnPK4+04L+vtZCx@gnusha.org
X-Gm-Message-State: AOJu0YwX2Yh4P6JlBC9X/cLp2g9nBfDn9NV0waPyRsbkBz6Sctndc+AS
	UfovugF+eCCPlTkgIXOTcgg45tCsEcdqWbBWmXumbWEQMVPtnhIkd4iY
X-Google-Smtp-Source: AGHT+IFHCqNqHUi198ud1/QlGt1uO+wxYYR6GicJcsgfOJGDHyx4uFfvAvbrPbSR5U4ciuB4onkniw==
X-Received: by 2002:a05:6902:2193:b0:e81:2d89:4e with SMTP id 3f1490d57ef6-e817b3f1eb3mr8137199276.28.1749128134547;
        Thu, 05 Jun 2025 05:55:34 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZd7pyi2UCmI+VLZglT+lemTLdtenlN17aoItcTvJVpOIg==
Received: by 2002:a25:d3c5:0:b0:e76:1290:e47f with SMTP id 3f1490d57ef6-e81889738d6ls989942276.2.-pod-prod-07-us;
 Thu, 05 Jun 2025 05:55:31 -0700 (PDT)
X-Received: by 2002:a05:690c:74c4:b0:709:176d:2b5 with SMTP id 00721157ae682-710d9a1f3femr96428457b3.2.1749128130987;
        Thu, 05 Jun 2025 05:55:30 -0700 (PDT)
Received: by 2002:a0d:d201:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-710d6e595f0ms7b3;
        Thu, 5 Jun 2025 01:18:28 -0700 (PDT)
X-Received: by 2002:a05:690c:3381:b0:70f:83ef:de07 with SMTP id 00721157ae682-710d9e7b590mr81315157b3.33.1749111507229;
        Thu, 05 Jun 2025 01:18:27 -0700 (PDT)
Date: Thu, 5 Jun 2025 01:18:26 -0700 (PDT)
From: Leo Wandersleb <lwandersleb@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <ea71bbd5-1325-445b-977f-a52b8017eab4n@googlegroups.com>
In-Reply-To: <44b5aa4c-a71b-49ed-beee-071140b16aacn@googlegroups.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>
 <5d9f6ac9-a623-4636-8a91-ee7c057bc08an@googlegroups.com>
 <44b5aa4c-a71b-49ed-beee-071140b16aacn@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_72546_464363642.1749111506764"
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_72546_464363642.1749111506764
Content-Type: multipart/alternative; 
	boundary="----=_Part_72547_955101479.1749111506764"

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

Hi Boris, hi list,

I think the weak announcement is a bad idea once EC crypto is broken to the=
=20
point where an attacker can break the key before the transaction gets mined=
=20
but the strong announcements should still hold as they have less urgency.=
=20
If the attacker sees the transaction in a strong announcement with a full=
=20
transaction, he cannot win even if he gets into a block first, as the=20
strong announcement proves a prior commitment to that transaction and would=
=20
win even if it gets mined only some blocks later.

A scheme where the announcement does not contain the full transaction is=20
problematic as the transaction might then turn out to not be valid. Then=20
nodes would wait for the "winning" wtxid blocking the UTXO forever.

So the scheme is:

After activation at block height X:

1. **Vulnerable UTXOs cannot be spent directly** - they require a prior=20
announcement=20
2. **Commitment** to a wTXID that spends the vulnerable UTXO. Multiple=20
wTXIDs can be stored in a hash tree in an OP_RETURN
3. **Reveal** full transaction with proof of prior commitment but not as a=
=20
normal transaction yet
4. **Counter Reveal**: For 144 blocks, others can reveal older commitments.=
=20
This protects exposed pubkeys!
5. **After 144 blocks**: The UTXO can be spent according to the strongest=
=20
announcement (oldest commitment of valid transaction wins).

As (5) is just the normal transaction, the scheme is a soft fork and=20
compatible with pre-recorded transactions where the keys were lost. It=20
would at least double the on-chain costs for these vulnerable UTXOs as they=
=20
would have to store the full transaction twice. We can make the=20
announcements prunable again though.

Best,

Leo
On Wednesday, 4 June 2025 at 20:40:32 UTC+2 Boris Nagaev wrote:

> Hi Leo,
>
> I think it is possible to provide privacy for Satoshi and also reduce the=
=20
> size of a weak announcement (strong announcements can already be small:=
=20
> just a txid or a Merkle root of many txids).
>
> Importantly, we cannot include the whole signed transaction in the weak=
=20
> announcement. Doing so would leak the EC public key immediately, allowing=
=20
> an attacker to create their own valid weak announcement. We must avoid=20
> revealing the public key until the actual spending transaction is broadca=
st.
>
> We need a scheme where the EC public key is not leaked in a weak=20
> announcement, but the legitimate owner can verify it, while no one else=
=20
> can. Also, once the EC public key is revealed, anyone should be able to=
=20
> verify a past weak announcement (to validate the transaction when it is=
=20
> broadcast). This reduces to the following requirement: we need a proof of=
=20
> knowledge of the EC public key that can be verified if the public key is=
=20
> known and provides no information otherwise.
>
> I think this is called a zero-knowledge proof. One simple approach could=
=20
> be to apply a tagged hash function to the concatenation of the EC public=
=20
> key and the future wTXID, and include this in the weak announcement. The=
=20
> structure would be:
>
>    -     UTXO (previous TXID and output index)
>    -     future spending wTXID
>    -     proof :=3D tagged_hash(EC public key || wTXID)
>
> The wTXID is included in the concatenation to bind the proof to a=20
> particular future transaction. Otherwise, someone could copy a weak=20
> announcement and substitute their own wTXID.
>
> Satoshi could publish a strong announcement now and then monitor all weak=
=20
> announcements involving his UTXOs. If someone publishes a weak announceme=
nt=20
> for one of his coins, he could verify the "proof" field. If it is valid, =
it=20
> would mean someone has cracked his key with a quantum computer, and he=20
> would need to use his strong announcement immediately to reclaim the fund=
s=20
> before the attacker does.
>
> Best,
> Boris
>
> On Wednesday, June 4, 2025 at 2:40:53=E2=80=AFPM UTC-3 Leo Wandersleb wro=
te:
>
> Hi Boris,
>
> the announcements, weak and strong would have to not be transactions yet=
=20
> to be compatible with legacy nodes and thus keep it a soft-fork. They cou=
ld=20
> be OP_RETURN data. Only after the 144 blocks, the upgraded full nodes wou=
ld=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 an=
d=20
> without the witness part later, so it would be a bit expensive this way b=
ut=20
> maybe we can do better?
>
> A node that gets updated would have to re-index all the blockchain to fin=
d=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-inde=
x=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 lear=
n=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 imminen=
t=20
> quantum breakthroughs.
> Hmm ... a problem is the weak announcement doesn't require keys, so=20
> anybody could provoke Satoshi to come forward. Maybe we have to add key=
=20
> ownership as a requirement for the "weak" announcement, too. So it should=
=20
> also contain a serialized transaction.
>
> Best,
>
> Leo
>
> On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Boris wrote:
>
> Hi Leo,=20
>
> Thanks for the clarifications, much appreciated!=20
> I have a couple of questions:=20
>
> 1. How is a weak announcement stored in the blockchain and in the UTXO=20
> set?=20
> I assume it must be a transaction, correct? And it should somehow mark=20
> the UTXO as planned to be spent for 144 blocks?=20
> How would older (non-upgraded) nodes interpret a transaction=20
> containing a weak announcement? Would they just skip over it without=20
> any special processing?=20
> If so, is there a problem for nodes that upgrade after the fork: would=20
> they have to reprocess all blocks since the fork to find and index all=20
> missed weak announcements?=20
>
> 2. In the case of reclaiming a UTXO after a weak announcement by an=20
> attacker: why would the legitimate owner wait for a weak announcement=20
> at all?=20
> If the EC public key was already leaked, it seems they should publish=20
> a strong announcement themselves rather than wait. If the EC public=20
> key wasn't leaked, there's nothing to worry about even if someone=20
> publishes a weak announcement: they are most likely bluffing, since=20
> they wouldn't have the actual public key.=20
>
> Best,=20
> Boris=20
>
> On Tue, Jun 3, 2025 at 3:29=E2=80=AFPM Leo Wandersleb <lwand...@gmail.com=
> wrote:=20
> >=20
> > Hi conduition,=20
> >=20
> > Thanks for your careful analysis - excellent catches.=20
> >=20
> > 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.=20
> >=20
> > 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=20
> protected.=20
> >=20
> > 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:=20
> >=20
> > 1. Weak announcement starts the 144-block window=20
> > 2. During this window, anyone with a strong commitment can reveal it=20
> > 3. The oldest valid commitment wins=20
> >=20
> > 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.=20
> >=20
> > 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.=20
> >=20
> > Best,=20
> >=20
> > Leo=20
> >=20
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to bitcoindev+...@googlegroups.com.=20
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e100=
6accdb55n%40googlegroups.com.=20
>
>
>
>
> --=20
> Best regards,=20
> Boris Nagaev=20
>
>

--=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/=
ea71bbd5-1325-445b-977f-a52b8017eab4n%40googlegroups.com.

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

Hi Boris, hi list,<div><br /></div><div>I think the weak announcement is a =
bad idea once EC crypto is broken to the point where an attacker can break =
the key before the transaction gets mined but the strong announcements shou=
ld still hold as they have less urgency. If the attacker sees the transacti=
on in a strong announcement with a full transaction, he cannot win even if =
he gets into a block first, as the strong announcement proves a prior commi=
tment to that transaction and would win even if it gets mined only some blo=
cks later.</div><div><br /></div><div>A scheme where the announcement does =
not contain the full transaction is problematic as the transaction might th=
en turn out to not be valid. Then nodes would wait for the "winning" wtxid =
blocking the UTXO forever.</div><div><br /></div><div>So the scheme is:</di=
v><div><br /></div><div>After activation at block height X:<br /><br />1. *=
*Vulnerable UTXOs cannot be spent directly** - they require a prior announc=
ement=C2=A0<br />2. **Commitment** to a wTXID that spends the vulnerable UT=
XO. Multiple wTXIDs can be stored in a hash tree in an OP_RETURN<br />3. **=
Reveal** full transaction with proof of prior commitment but not as a norma=
l transaction yet</div><div>4. **Counter Reveal**: For 144 blocks, others c=
an reveal older commitments. This protects exposed pubkeys!<br />5. **After=
 144 blocks**: The UTXO can be spent according to the strongest announcemen=
t (oldest commitment of valid transaction wins).</div><div><br /></div><div=
>As (5) is just the normal transaction, the scheme is a soft fork and compa=
tible with pre-recorded transactions where the keys were lost. It would at =
least double the on-chain costs for these vulnerable UTXOs as they would ha=
ve to store the full transaction twice. We can make the announcements pruna=
ble again though.<br /></div><div><br /></div><div>Best,</div><div><br /></=
div><div>Leo</div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gma=
il_attr">On Wednesday, 4 June 2025 at 20:40:32 UTC+2 Boris Nagaev wrote:<br=
/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; bor=
der-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Leo,<br><br>=
I think it is possible to provide privacy for Satoshi and also reduce the s=
ize of a weak announcement (strong announcements can already be small: just=
 a txid or a Merkle root of many txids).<br><div><br></div><div>Importantly=
, we cannot include the whole signed transaction in the weak announcement. =
Doing so would leak the EC public key immediately, allowing an attacker to =
create their own valid weak announcement. We must avoid revealing the publi=
c key until the actual spending transaction is broadcast.</div><div><br></d=
iv>We need a scheme where the EC public key is not leaked in a weak announc=
ement, but the legitimate owner can verify it, while no one else can. Also,=
 once the EC public key is revealed, anyone should be able to verify a past=
 weak announcement (to validate the transaction when it is broadcast). This=
 reduces to the following requirement: we need a proof of knowledge of the =
EC public key that can be verified if the public key is known and provides =
no information otherwise.<br><br>I think this is called a zero-knowledge pr=
oof. One simple approach could be to apply a tagged hash function to the co=
ncatenation of the EC public key and the future wTXID, and include this in =
the weak announcement. The structure would be:<br><ul><li>=C2=A0 =C2=A0 UTX=
O (previous TXID and output index)</li><li>=C2=A0 =C2=A0 future spending wT=
XID</li><li>=C2=A0 =C2=A0 proof :=3D tagged_hash(EC public key || wTXID)</l=
i></ul>The wTXID is included in the concatenation to bind the proof to a pa=
rticular future transaction. Otherwise, someone could copy a weak announcem=
ent and substitute their own wTXID.<br><br>Satoshi could publish a strong a=
nnouncement now and then monitor all weak announcements involving his UTXOs=
. If someone publishes a weak announcement for one of his coins, he could v=
erify the &quot;proof&quot; field. If it is valid, it would mean someone ha=
s cracked his key with a quantum computer, and he would need to use his str=
ong announcement immediately to reclaim the funds before the attacker does.=
<br><br>Best,<br>Boris<br><br><div><div dir=3D"auto">On Wednesday, June 4, =
2025 at 2:40:53=E2=80=AFPM UTC-3 Leo Wandersleb wrote:<br></div><blockquote=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">Hi Boris,<div><br></div><div>the announcements, weak and s=
trong would have to not be transactions yet to be compatible with legacy no=
des and thus keep 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 ac=
tual transaction. This would mean the transaction would be both in full in =
the OP_RETURN strong announcement and without the witness part later, so it=
 would be a bit expensive this way but maybe we can do better?</div><div><b=
r></div><div>A node that gets updated would have to re-index all the blockc=
hain to find announcements if we don&#39;t introduce a time frame for actua=
lly using the announcements. We could also say that any announcement has to=
 be used within another 1000 blocks. Then the upgrading node would have to =
re-index the last 1000 blocks.</div><div><br></div><div>The legitimate owne=
r of a UTXO might 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 an=
d when QC becomes an issue, we would learn about him having been active in =
2027 in 2040 when actually somebody tried to attack and not in 2027 when pe=
ople started to panic because of imminent quantum breakthroughs.</div><div>=
Hmm ... a problem is the weak announcement doesn&#39;t require keys, so any=
body could provoke Satoshi to come forward. Maybe we have to add key owners=
hip as a requirement for the &quot;weak&quot; announcement, too. So it shou=
ld also contain a serialized transaction.<br></div><div><br></div><div>Best=
,</div><div><br></div><div>Leo</div><div><br></div><div><div dir=3D"auto">O=
n Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Boris wrote:<br></div><bl=
ockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,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 rel=3D"nof=
ollow">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 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" rel=3D"nofollow" target=3D"_blank" 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=3D1749156261005000&amp;usg=3DAOvVaw0yWD78lxNnTSafY5AncFTH">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></blockquote></div></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/ea71bbd5-1325-445b-977f-a52b8017eab4n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/ea71bbd5-1325-445b-977f-a52b8017eab4n%40googlegroups.com</a>.<br />

------=_Part_72547_955101479.1749111506764--

------=_Part_72546_464363642.1749111506764--