path: root/af/4408c489cb48eee8d47ab85201aedd4374d862

Delivery-date: Mon, 09 Jun 2025 03:10:17 -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+bncBD2IRYOX4AFRB7PFTLBAMGQE23FM4TA@googlegroups.com>)
	id 1uOZSJ-0001PX-Lu
	for bitcoindev@gnusha.org; Mon, 09 Jun 2025 03:10:17 -0700
Received: by mail-yw1-f186.google.com with SMTP id 00721157ae682-70e4e62caa7sf68833597b3.1
        for <bitcoindev@gnusha.org>; Mon, 09 Jun 2025 03:10:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749463809; x=1750068609; 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=1HQkPXsEVSHJ6DqzFY7KlAf2XR3Vecm7u3ZBsoYt6dc=;
        b=cxFsCHksi/37fCCQUshJFlpHtvtEmf19eLpxo+NgM3DTlx8n/pH9b/pO+Lee6BpC0Y
         OPQ0U2tJLuXrCGQ45t+QHnMXsb6dcobOdmh4cFKc8ClUB0VX+zVEDaxPh34ygURx5ETs
         CYq/RJkW+uUV9JrjC1+AYDbXLaUXBYuWUNekf1EC7iqb/RQdVaUEnD+I8qWtYNzXrxGU
         caj5JnBDo8bl7Zjk62pMvMkRsI5O0CBDWYAo6MYdMDsr1OSLw16WJ5tboA7NccYvBHL3
         c/BbKzSie0bQQYPtXooebg2KdP3hopDhSciJLx/ho7QDST4eFU1IvOPl34UFrS+n8R4j
         vm2A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749463809; x=1750068609; 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=1HQkPXsEVSHJ6DqzFY7KlAf2XR3Vecm7u3ZBsoYt6dc=;
        b=fSPthlZniU2OkW8i1QTR9/JB8grBk9vDwHmoS6vwExb6TJ0fpzTOquqkt2O5f7V5XE
         Cd0yMjAPeG3viOy1OaXamwwEn80VSW/dGly3YczrVs9UVSeP7x6Evd769ftjHuBOdWhw
         OITYG0VWrifMl+IsRk7TkKiDmuTtZLwxEpwSIr4bXJXFqpu9uhEj4t53wDmY2tf3fC3n
         uReQB9ieuMzWt+EFPHkQeKG+R47vjGsHMf5YGfVCga7ctU4Zq1iir3m76PgbARyhDMpR
         KzLIRCUgi3N5yAUqleaS+IeIc2jLmZ+vj4CXthwKAw7N0jCtQP67J/RqEr0N3BrZfaCs
         4xZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749463809; x=1750068609;
        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=1HQkPXsEVSHJ6DqzFY7KlAf2XR3Vecm7u3ZBsoYt6dc=;
        b=oB4gRbm7cGjfNqCbbBdflUtTN0KAau4SvhMsJ5wCk0LQguG5DqQgkgs0Ds3objupKK
         yUIRGtGPQfX2XS32o6+isO9qnhAtEInyqAM9YMXPEQPlBvA634fnLz9MPh8J0bioCX4G
         DF0m4DMHniLv0H+1c79y3Y78VgVcJmE9q058XErOhTE8I0X26B+ApX7SJOkGMJ5veP0q
         wL1O7/3+hVSUvupyzKIfqtlcVDysE1Sp4OSy/y7Jnc+gN3POf/pdPb2ZHqqpDNrsXbjr
         ITZj1b7cNdHgcII8kmSXaNMN2v+kR3rV6R2ZBuiV/W6qPhaocNb70gB3bY95TEQ6L7iq
         SSXg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXyLLXkhe7iVgM+C+bx2Nft87b5r1GbHPGUCO0OgVQfAJfGy4VWRJ77DDm3fncuibF4WeHh3Z2d0T/y@gnusha.org
X-Gm-Message-State: AOJu0YwI+Lx5Al/xQ/pUELwhAzZL45zB/f91e1V6h5aGCTqOybjmv557
	8lZKOf4OFcxLD4lWdxxSFa57G5bSCKffadsgWEz0HQNv6tV7teqa9XCR
X-Google-Smtp-Source: AGHT+IEHezZ0TnnAjCoC+4TzTxJGC+hacVf02FqBl4ZwgS/igS/oR/N8sgaKd2V8aA85VASI2LnhdQ==
X-Received: by 2002:a05:6902:91e:b0:e81:7e20:d737 with SMTP id 3f1490d57ef6-e81c220dc46mr10157859276.18.1749463809455;
        Mon, 09 Jun 2025 03:10:09 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcvoAt2lCsWgn/GY5uwau2QsFkmmdas0KLUiHfzC5k5Jg==
Received: by 2002:a25:d386:0:b0:e7d:804c:d381 with SMTP id 3f1490d57ef6-e8188a2baf7ls4134140276.2.-pod-prod-00-us;
 Mon, 09 Jun 2025 03:10:05 -0700 (PDT)
X-Received: by 2002:a05:690c:6813:b0:70e:2804:9930 with SMTP id 00721157ae682-711088022ffmr107071497b3.10.1749463804900;
        Mon, 09 Jun 2025 03:10:04 -0700 (PDT)
Received: by 2002:a0d:d201:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-710d6e595f0ms7b3;
        Thu, 5 Jun 2025 08:12:38 -0700 (PDT)
X-Received: by 2002:a05:690c:660f:b0:70e:4d8:5cab with SMTP id 00721157ae682-710e7dcc9eemr55074587b3.2.1749136357630;
        Thu, 05 Jun 2025 08:12:37 -0700 (PDT)
Date: Thu, 5 Jun 2025 08:12:37 -0700 (PDT)
From: Leo Wandersleb <lwandersleb@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <ccd3f262-d3c6-45e1-ba89-e84116da36f3n@googlegroups.com>
In-Reply-To: <2ed6d831-d87d-44f0-82b9-c8b9abaa8010n@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>
 <2ed6d831-d87d-44f0-82b9-c8b9abaa8010n@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_117096_394704256.1749136357155"
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_117096_394704256.1749136357155
Content-Type: multipart/alternative; 
	boundary="----=_Part_117097_1151683106.1749136357155"

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

Hi Boris, hi list,

if I understand it right, your proposal is closer to Tadge Dryja's "Post-Qu=
antum=20
commit / reveal Fawkescoin variant as a soft fork"? It would exclusively=20
protect unrevealed pubkeys while I try to also protect bare pubkeys.

Best,

Leo

On Thursday, 5 June 2025 at 16:59:02 UTC+2 Boris Nagaev wrote:

> 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=
=20
> to address this.
>
> I propose the following scheme. There is just one announcement type, whic=
h=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 announceme=
nt=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 node=
s=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 wrot=
e:
>
> Hi Boris, hi list,
>
> I think the weak announcement is a bad idea once EC crypto is broken to=
=20
> the point where an attacker can break the key before the transaction gets=
=20
> mined but the strong announcements should still hold as they have less=20
> urgency. If the attacker sees the transaction in a strong announcement wi=
th=20
> a full transaction, he cannot win even if he gets into a block first, as=
=20
> the strong announcement proves a prior commitment to that transaction and=
=20
> would 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=20
> commitments. 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 th=
ey=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/=
ccd3f262-d3c6-45e1-ba89-e84116da36f3n%40googlegroups.com.

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

Hi Boris, hi list,<div><br /></div><div>if I understand it right, your prop=
osal is closer to=C2=A0<span style=3D"color: rgb(32, 33, 36); font-family: =
Roboto, Arial, sans-serif; letter-spacing: 0.25px; text-wrap-mode: nowrap;"=
>Tadge Dryja's "</span>Post-Quantum commit / reveal Fawkescoin variant as a=
 soft fork"? It would exclusively protect unrevealed pubkeys while I try to=
 also protect bare pubkeys.</div><div><br /></div><div>Best,</div><div><br =
/></div><div>Leo<br /><br /></div><div class=3D"gmail_quote"><div dir=3D"au=
to" class=3D"gmail_attr">On Thursday, 5 June 2025 at 16:59:02 UTC+2 Boris N=
agaev 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, hi list,<br><br>You raise a valid point that a wTXID coming from a =
quantum attacker could be invalid, and the scheme must be robust against th=
is. In this scenario, the attacker is not motivated by profit but rather 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 pr=
opose the following scheme. There is just one announcement type, which was =
defined as a weak proof in my previous message. An announcement includes th=
e UTXO, wTXID, and a proof (tagged_hash(EC public key || wTXID)). This tupl=
e can be stored in an OP_RETURN output. The rule of a hypothetical soft for=
k would be: to spend an EC output, there must be an announcement with the c=
orresponding wTXID and a valid proof published at least X blocks earlier.<b=
r><br>This design prevents an attacker from maliciously blocking someone el=
se&#39;s coin. There is no &quot;earliest announcement wins&quot; rule. Any=
 valid announcement wins once it is sufficiently buried. If an attacker pub=
lishes an invalid announcement, the legitimate owner can simply publish the=
ir own and wait X blocks before sweeping the funds. If they have already pu=
blished an announcement (as they should), they can use it without delay.<br=
><br>The scheme also preserves Satoshi&#39;s privacy: anyone can publish an=
 announcement for Satoshi&#39;s coins, but without the actual spending tran=
saction, nobody can tell whether the announcement is valid.<br><br>A downsi=
de of the scheme is that all announcements must be stored by nodes until th=
e corresponding UTXO is spent, and there can be multiple announcements for =
a single coin. Another downside is that announcements cannot be packed into=
 a Merkle root, because the UTXO must be visible for Satoshi to identify hi=
s 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>Bor=
is<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);padding-left:1ex">Hi B=
oris, hi list,<div><br></div><div>I think the weak announcement is a bad id=
ea once EC crypto is broken to the point where an attacker can break the ke=
y before the transaction gets mined but the strong announcements should sti=
ll 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 get=
s into a block first, as the strong announcement proves a prior commitment =
to that transaction and would win even if it gets mined only some blocks la=
ter.</div><div><br></div><div>A scheme where the announcement does not cont=
ain the full transaction is problematic as the transaction might then turn =
out to not be valid. Then nodes would wait for the &quot;winning&quot; wtxi=
d blocking the UTXO forever.</div><div><br></div><div>So the scheme is:</di=
v><div><br></div><div></div><div>After activation at block 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_RET=
URN<br>3. **Reveal** full transaction with proof of prior commitment but no=
t as a normal transaction yet</div><div>4. **Counter Reveal**: For 144 bloc=
ks, others can reveal older commitments. This protects exposed pubkeys!<br>=
5. **After 144 blocks**: The UTXO can be spent according to the strongest a=
nnouncement (oldest commitment of valid transaction wins).</div><div><br></=
div><div>As (5) is just the normal transaction, the scheme is a soft fork a=
nd compatible with pre-recorded transactions where the keys were lost. It w=
ould at least double the on-chain costs for these vulnerable UTXOs as they =
would have to store the full transaction twice. We can make the announcemen=
ts 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 0p=
x 0px 0.8ex;border-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 red=
uce the size of a weak announcement (strong announcements can already be sm=
all: just a txid or a Merkle root of many txids).<br><div><br></div><div>Im=
portantly, we cannot include the whole signed transaction in the weak annou=
ncement. Doing so would leak the EC public key immediately, allowing an att=
acker to create their own valid weak announcement. We must avoid revealing =
the public key until the actual spending transaction is broadcast.</div><di=
v><br></div>We need a scheme where the EC public key is not leaked in a wea=
k announcement, but the legitimate owner can verify it, while no one else c=
an. Also, once the EC public key is revealed, anyone should be able to veri=
fy a past weak announcement (to validate the transaction when it is broadca=
st). This reduces to the following requirement: we need a proof of knowledg=
e 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-kno=
wledge proof. One simple approach could be to apply a tagged hash function =
to the concatenation 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 s=
pending wTXID</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 pro=
of to a particular future transaction. Otherwise, someone could copy a weak=
 announcement and substitute their own wTXID.<br><br>Satoshi could publish =
a strong announcement now and then monitor all weak announcements involving=
 his UTXOs. If someone publishes a weak announcement for one of his coins, =
he could verify the &quot;proof&quot; field. If it is valid, it would mean =
someone has cracked his key with a quantum computer, and he would need to u=
se his strong announcement immediately to reclaim the funds before the atta=
cker 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);padding-left:1ex">Hi Boris,<div><br></div><div>the announcements, =
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 data. O=
nly after the 144 blocks, the upgraded full nodes would allow the inclusion=
 of the actual transaction. This would mean the transaction would be both i=
n full in the OP_RETURN strong announcement and without the witness part la=
ter, so it would be a bit expensive this way but maybe we can do better?</d=
iv><div><br></div><div>A node that gets updated would have to re-index all =
the blockchain to find announcements if we don&#39;t introduce a time frame=
 for actually using the announcements. We could also say that any announcem=
ent has to be used within another 1000 blocks. Then the upgrading node woul=
d have to re-index the last 1000 blocks.</div><div><br></div><div>The legit=
imate owner of a UTXO might wait for an attack for privacy reasons. My prop=
osal 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 becomes an issue, we would learn about him having been =
active in 2027 in 2040 when actually somebody tried to attack and not in 20=
27 when people started to panic because of imminent quantum breakthroughs.<=
/div><div>Hmm ... a problem is the weak announcement doesn&#39;t require ke=
ys, so anybody could provoke Satoshi to come forward. Maybe we have to add =
key ownership as a requirement for the &quot;weak&quot; 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><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 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=3D1749222418956000&amp;usg=3DAOvVaw1mlpYyWOlxzBokStqVoo6R">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></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/ccd3f262-d3c6-45e1-ba89-e84116da36f3n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/ccd3f262-d3c6-45e1-ba89-e84116da36f3n%40googlegroups.com</a>.<br />

------=_Part_117097_1151683106.1749136357155--

------=_Part_117096_394704256.1749136357155--