path: root/15/ac5898879ba2b2eef15c3c0c7b33a993f0705c

Delivery-date: Thu, 05 Jun 2025 07:59:10 -0700
Received: from mail-yw1-f186.google.com ([209.85.128.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCYMD7OS6ECBBMXBQ3BAMGQEPV3KWFA@googlegroups.com>)
	id 1uNC3g-0000Uv-Nl
	for bitcoindev@gnusha.org; Thu, 05 Jun 2025 07:59:10 -0700
Received: by mail-yw1-f186.google.com with SMTP id 00721157ae682-70e33aeaad4sf13682967b3.0
        for <bitcoindev@gnusha.org>; Thu, 05 Jun 2025 07:59:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749135543; x=1749740343; 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=T8uDtVtCnB9UofsdWzHPcCoeopQh8oQYdFPt92sE56M=;
        b=StdaF+IQ9/0ESmJNXUsgj4a14mnyMYBne9bM2WmwxEa3awLc6We5N9kCRum2VOJksL
         awZy2B5EthH2LX57JTBMrUlI0DSVPpx9G3FSNSg0Po3+0faDiNEXpusMlvX25rjCbVcY
         CKh4r88BWt+MArE0DfAjRGTujoIBxcVHCfirxRFwf5RLjY3VRN4e1Mi52/m50KOKW0Ad
         KJwVo4KiCgCD8p1jLX87UmFsVuC49ccO455sQEGBjkBQGe/L2TvxFRZkpmBBWR+TbmCX
         ArnvzQrfTKEOdlI9IhrZP1FAW2VoLHP3A7KizoDeMimbS6+S7EAuFbSnN1x3Y5r/8SGJ
         NjeQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749135543; x=1749740343; 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=T8uDtVtCnB9UofsdWzHPcCoeopQh8oQYdFPt92sE56M=;
        b=ThioF74PhPEZqcX6XYhnhQNr/Us5gB+wYv8DL2msYm0bGT90uGc2P0T9Q1kiGhzXKF
         NCZ6eoInqklIoDFG0oah6sJ6xrzivyyGdCpxFFlj5i8X3xtuI/Q/B6d4Bu2QTGCPTHUz
         rhgoyaHP0gjQDQsqHk04WDX6arCGWWkqlg3Evc+AFTOw/gzdCmREXCApojEtTfxpbUhl
         cCoWfHecVGdSgwlyouIpGEN8rUspABtheLm7xgP6KTAqBbS12IMwSCYx/C4r+lNZBP4J
         Ie0TQ8fcCIExaRpe08UBRSyM7zoTaFNPsgACm4FbxUMeOal7JsZrgssHf7yo9EewNcy5
         jnQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749135543; x=1749740343;
        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=T8uDtVtCnB9UofsdWzHPcCoeopQh8oQYdFPt92sE56M=;
        b=FRg/W5Il1xIG/PM7rB8no3BHrfz9KbHJTRScqt40b4KYoJ8a0oZCjjQJS2brXHtlIG
         8sB/P7a5k6h7rLWNagPR8+lT3HeM8S1NmDl4Fq38/h9MZuZNoQYVZNhIR1vwUyxg+17a
         5WDkOcrS2GUWTGtMren7RZLwkxgZ10GbeDn1VHgKDqjLWIMH1RVQ2cFynyO4gh3Jwr0w
         6OW6H3aqNoPU2iIUscc8ZVeKq3QJzp8OJF7Lv8U3OTuhjP5UUrP7QqkbZu+HFblBulVV
         6kkO/sj2ReZcwH1H0YbclC1q3V4C4dr9YNv4W6+7oDYyfVVJSPY7U903CctcEiGvq2IG
         2WPw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVZdHvU/G51kF/qu8JORYJ9GDgG3MdAc89OW1We5dMu5q+X7xQnYrxma9BkJFsQhfTeCWZGhgDjxj15@gnusha.org
X-Gm-Message-State: AOJu0YzbYjBI82Km2t0bkLZIXJe/3vKfliLLvotP82YXN2sKeM92nlRK
	qge6xMKlldB9D507rt2Y6nDgzY49MjPk8LxRnZIIYufwxQWiQVo9dgie
X-Google-Smtp-Source: AGHT+IEkbGdfQvEAAzDu/4gcDjSOoARVnHuEQI8jH0dE5qdN12Yjt1BXsQAdj5jrt7sZzNeeVHQ2OA==
X-Received: by 2002:a05:6902:1692:b0:e7d:6a68:f572 with SMTP id 3f1490d57ef6-e81a209d9b2mr114051276.10.1749135542336;
        Thu, 05 Jun 2025 07:59:02 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcLVCTqgw4ygFUF5BY54YqkPy6SS0dghR5DHLhxCxIlQw==
Received: by 2002:a25:d386:0:b0:e7d:804c:d381 with SMTP id 3f1490d57ef6-e8188a2baf7ls1153046276.2.-pod-prod-00-us;
 Thu, 05 Jun 2025 07:58:58 -0700 (PDT)
X-Received: by 2002:a05:690c:f8e:b0:70c:c20a:89a5 with SMTP id 00721157ae682-710e7ef82e5mr49699677b3.19.1749135538443;
        Thu, 05 Jun 2025 07:58:58 -0700 (PDT)
Received: by 2002:a05:690c:7741:b0:710:f35d:a3b2 with SMTP id 00721157ae682-710f35da70ams7b3;
        Thu, 5 Jun 2025 07:54:27 -0700 (PDT)
X-Received: by 2002:a05:690c:f07:b0:70e:25b2:8f42 with SMTP id 00721157ae682-710e7efa238mr55358937b3.18.1749135265946;
        Thu, 05 Jun 2025 07:54:25 -0700 (PDT)
Date: Thu, 5 Jun 2025 07:54:25 -0700 (PDT)
From: Boris Nagaev <bnagaev@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <2ed6d831-d87d-44f0-82b9-c8b9abaa8010n@googlegroups.com>
In-Reply-To: <ea71bbd5-1325-445b-977f-a52b8017eab4n@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>
 <ea71bbd5-1325-445b-977f-a52b8017eab4n@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_116060_1784724860.1749135265323"
X-Original-Sender: bnagaev@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_116060_1784724860.1749135265323
Content-Type: multipart/alternative; 
	boundary="----=_Part_116061_1164823195.1749135265323"

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

Hi Leo, hi list,

You raise a valid point that a wTXID coming from a quantum attacker could=
=20
be invalid, and the scheme must be robust against this. In this scenario,=
=20
the attacker is not motivated by profit but rather by the desire to harm=20
the legitimate owner.

I think we do not need to include a full transaction in the announcement to=
=20
address this.

I propose the following scheme. There is just one announcement type, which=
=20
was defined as a weak proof in my previous message. An announcement=20
includes the UTXO, wTXID, and a proof (tagged_hash(EC public key ||=20
wTXID)). This tuple can be stored in an OP_RETURN output. The rule of a=20
hypothetical soft fork would be: to spend an EC output, there must be an=20
announcement with the corresponding wTXID and a valid proof published at=20
least X blocks earlier.

This design prevents an attacker from maliciously blocking someone else's=
=20
coin. There is no "earliest announcement wins" rule. Any valid announcement=
=20
wins once it is sufficiently buried. If an attacker publishes an invalid=20
announcement, the legitimate owner can simply publish their own and wait X=
=20
blocks before sweeping the funds. If they have already published an=20
announcement (as they should), they can use it without delay.

The scheme also preserves Satoshi's privacy: anyone can publish an=20
announcement for Satoshi's coins, but without the actual spending=20
transaction, nobody can tell whether the announcement is valid.

A downside of the scheme is that all announcements must be stored by nodes=
=20
until the corresponding UTXO is spent, and there can be multiple=20
announcements for a single coin. Another downside is that announcements=20
cannot be packed into a Merkle root, because the UTXO must be visible for=
=20
Satoshi to identify his coins, and he must be able to verify the proof.=20
Perhaps there are ways to improve the scheme to address these efficiency=20
issues.

Best,
Boris

On Thursday, June 5, 2025 at 9:55:34=E2=80=AFAM UTC-3 Leo Wandersleb wrote:

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

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 be=
=20
to apply a tagged hash function to the concatenation of the EC public key=
=20
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 announcement=
=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 funds=
=20
before the attacker does.

Best,
Boris

On Wednesday, June 4, 2025 at 2:40:53=E2=80=AFPM UTC-3 Leo Wandersleb wrote=
:

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,=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 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 must=
=20
be to the complete transaction including witness data (wTXID or equivalent)=
=20
to prevent an attacker from pre-committing to unsigned transactions. This=
=20
is essential - otherwise an attacker could indeed enumerate the UTXO set=20
and create commitments without knowing the private 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 than=
=20
after every transaction. The scheme is particularly important for existing=
=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 not=
=20
about preventing commitment forgery after pubkey exposure, but rather about=
=20
allowing priority based on commitment age when multiple parties claim the=
=20
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 and=
=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 Groups=
=20
"Bitcoin Development Mailing List" group.=20
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
email to bitcoindev+...@googlegroups.com.=20
> To view this discussion visit=20
https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006a=
ccdb55n%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/=
2ed6d831-d87d-44f0-82b9-c8b9abaa8010n%40googlegroups.com.

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

Hi Leo, hi list,<br /><br />You raise a valid point that a wTXID coming fro=
m a quantum attacker could be invalid, and the scheme must be robust agains=
t this. In this scenario, the attacker is not motivated by profit but rathe=
r by the desire to harm the legitimate owner.<br /><br />I think we do not =
need to include a full transaction in the announcement to address this.<br =
/><br />I propose the following scheme. There is just one announcement type=
, which was defined as a weak proof in my previous message. An announcement=
 includes the UTXO, wTXID, and a proof (tagged_hash(EC public key || wTXID)=
). This tuple can be stored in an OP_RETURN output. The rule of a hypotheti=
cal soft fork would be: to spend an EC output, there must be an announcemen=
t with the corresponding wTXID and a valid proof published at least X block=
s earlier.<br /><br />This design prevents an attacker from maliciously blo=
cking someone else's coin. There is no "earliest announcement wins" rule. A=
ny valid announcement wins once it is sufficiently buried. If an attacker p=
ublishes an invalid announcement, the legitimate owner can simply publish t=
heir own and wait X blocks before sweeping the funds. If they have already =
published an announcement (as they should), they can use it without delay.<=
br /><br />The scheme also preserves Satoshi's privacy: anyone can publish =
an announcement for Satoshi's coins, but without the actual spending transa=
ction, nobody can tell whether the announcement is valid.<br /><br />A down=
side of the scheme is that all announcements must be stored by nodes until =
the corresponding UTXO is spent, and there can be multiple announcements fo=
r a single coin. Another downside is that announcements cannot be packed in=
to a Merkle root, because the UTXO must be visible for Satoshi to identify =
his coins, and he must be able to verify the proof. Perhaps there are ways =
to improve the scheme to address these efficiency issues.<br /><br />Best,<=
br />Boris<br /><br /><div><div dir=3D"auto">On Thursday, June 5, 2025 at 9=
:55:34=E2=80=AFAM 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, 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 should still hold as they have less urgency. If the attacker=
 sees the transaction in a strong announcement with a full transaction, he =
cannot win even if he gets into a block first, as the strong announcement p=
roves a prior commitment to that transaction and would win even if it gets =
mined only some blocks later.</div><div><br /></div><div>A scheme where the=
 announcement does not contain the full transaction is problematic as the t=
ransaction might then turn out to not be valid. Then nodes would wait for t=
he "winning" wtxid blocking the UTXO forever.</div><div><br /></div><div>So=
 the scheme is:</div><div><br /></div><div></div><div>After activation at b=
lock height X:<br /><br /></div><div>1. **Vulnerable UTXOs cannot be spent =
directly** - they require a prior announcement=C2=A0<br />2. **Commitment**=
 to a wTXID that spends the vulnerable UTXO. Multiple wTXIDs can be stored =
in a hash tree in an OP_RETURN<br />3. **Reveal** full transaction with pro=
of of prior commitment but not as a normal transaction yet</div><div>4. **C=
ounter Reveal**: For 144 blocks, others can reveal older commitments. This =
protects exposed pubkeys!<br />5. **After 144 blocks**: The UTXO can be spe=
nt according to the strongest announcement (oldest commitment of valid tran=
saction wins).</div><div><br /></div><div>As (5) is just the normal transac=
tion, the scheme is a soft fork and compatible with pre-recorded transactio=
ns where the keys were lost. It would at least double the on-chain costs fo=
r these vulnerable UTXOs as they would have to store the full transaction t=
wice. We can make the announcements prunable again though.<br /></div><div>=
<br /></div><div>Best,</div><div><br /></div><div>Leo</div><div><div dir=3D=
"auto">On Wednesday, 4 June 2025 at 20:40:32 UTC+2 Boris Nagaev wrote:<br /=
></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px sol=
id 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 size 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 cann=
ot include the whole signed transaction in the weak announcement. Doing so =
would leak the EC public key immediately, allowing an attacker to create th=
eir own valid weak announcement. We must avoid revealing the public key unt=
il the actual spending transaction is broadcast.</div><div><br /></div>We n=
eed a scheme where the EC public key is not leaked in a weak announcement, =
but the legitimate owner can verify it, while no one else can. Also, once t=
he EC public key is revealed, anyone should be able to verify a past weak a=
nnouncement (to validate the transaction when it is broadcast). This reduce=
s to the following requirement: we need a proof of knowledge of the EC publ=
ic key that can be verified if the public key is known and provides no info=
rmation otherwise.<br /><br />I think this is called a zero-knowledge proof=
. One simple approach could be to apply a tagged hash function to the conca=
tenation 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 UTXO=
 (previous TXID and output index)</li><li>=C2=A0 =C2=A0 future spending wTX=
ID</li><li>=C2=A0 =C2=A0 proof :=3D tagged_hash(EC public key || wTXID)</li=
></ul>The wTXID is included in the concatenation to bind the proof to a par=
ticular future transaction. Otherwise, someone could copy a weak announceme=
nt and substitute their own wTXID.<br /><br />Satoshi could publish a stron=
g announcement now and then monitor all weak announcements involving his UT=
XOs. If someone publishes a weak announcement for one of his coins, he coul=
d verify the "proof" field. If it is valid, it would mean someone has crack=
ed his key with a quantum computer, and he would need to use his strong ann=
ouncement 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><block=
quote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 2=
04, 204); padding-left: 1ex;">Hi Boris,<div><br /></div><div>the announceme=
nts, weak and strong would have to not be transactions yet to be compatible=
 with legacy nodes and thus keep it a soft-fork. They could be OP_RETURN da=
ta. Only after the 144 blocks, the upgraded full nodes would allow the incl=
usion of the actual transaction. This would mean the transaction would be b=
oth in full in the OP_RETURN strong announcement and without the witness pa=
rt later, so it would be a bit expensive this way but maybe we can do bette=
r?</div><div><br /></div><div>A node that gets updated would have to re-ind=
ex all the blockchain to find announcements if we don't introduce a time fr=
ame for actually using the announcements. We could also say that any announ=
cement has to be used within another 1000 blocks. Then the upgrading node w=
ould have to re-index the last 1000 blocks.</div><div><br /></div><div>The =
legitimate owner of a UTXO might wait for an attack for privacy reasons. My=
 proposal would allow Satoshi himself to make all his UTXOs quantum safe wi=
thout any of us learning about him being active. He could add one 64B OP_RE=
TURN in 2027 and 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 people started to panic because of imminent quantum breakthrou=
ghs.</div><div>Hmm ... a problem is the weak announcement doesn't require k=
eys, so anybody could provoke Satoshi to come forward. Maybe we have to add=
 key ownership as a requirement for the "weak" announcement, too. So it sho=
uld 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">On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Boris wrote:<b=
r /></div><blockquote style=3D"margin: 0px 0px 0px 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 UTX=
O set?
<br />I assume it must be a transaction, correct? And it should somehow mar=
k
<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: woul=
d
<br />they have to reprocess all blocks since the fork to find and index al=
l
<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't leaked, there's nothing to worry about even if someone
<br />publishes a weak announcement: they are most likely bluffing, since
<br />they wouldn'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"n=
ofollow">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're absolutely right about the txid vulnerability. The commit=
ment must be to the complete transaction including witness data (wTXID or e=
quivalent) to prevent an attacker from pre-committing to unsigned transacti=
ons. This is essential - otherwise an attacker could indeed enumerate the U=
TXO set and create commitments without knowing the private keys.
<br />&gt;
<br />&gt; 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) rat=
her than after every transaction. The scheme is particularly important for =
existing UTXOs that already have exposed pubkeys (old P2PK, reused addresse=
s, etc.). For new UTXOs, wallets should ideally migrate to quantum-safe add=
resses once available. OpenTimestamps aggregation would indeed help with sc=
aling and provide plausible deniability about the number of UTXOs being pro=
tected.
<br />&gt;
<br />&gt; The time delay serves a different purpose than you might expect.=
 It's not about preventing commitment forgery after pubkey exposure, but ra=
ther about allowing priority based on commitment age when multiple parties =
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 revea=
l it
<br />&gt; 3. The oldest valid commitment wins
<br />&gt;
<br />&gt; 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 commit=
ment, they can reclaim it during the window. The uncertainty about which UT=
XOs have poison pills makes attacking large "lost" UTXOs risky - hence less=
 disruptive to the network.
<br />&gt;
<br />&gt; The delay essentially allows a "commitment priority contest" whe=
re age determines the winner, protecting users who prepared early while sti=
ll 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 Goog=
le Groups "Bitcoin Development Mailing List" 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.c=
om/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.=
com" rel=3D"nofollow" target=3D"_blank">https://groups.google.com/d/msgid/b=
itcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.com</a>.
<br />
<br />
<br />
<br />--=20
<br />Best regards,
<br />Boris Nagaev
<br /></blockquote></div></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/2ed6d831-d87d-44f0-82b9-c8b9abaa8010n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/2ed6d831-d87d-44f0-82b9-c8b9abaa8010n%40googlegroups.com</a>.<br />

------=_Part_116061_1164823195.1749135265323--

------=_Part_116060_1784724860.1749135265323--