path: root/2f/f134fcb147d72c70116c7a1785da3f719ece5b

Delivery-date: Mon, 09 Jun 2025 03:10:47 -0700
Received: from mail-ot1-f60.google.com ([209.85.210.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD2IRYOX4AFRBEHGTLBAMGQEUI5Y7IA@googlegroups.com>)
	id 1uOZSn-0001V9-Bi
	for bitcoindev@gnusha.org; Mon, 09 Jun 2025 03:10:47 -0700
Received: by mail-ot1-f60.google.com with SMTP id 46e09a7af769-735a61e2d55sf4130885a34.2
        for <bitcoindev@gnusha.org>; Mon, 09 Jun 2025 03:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749463839; x=1750068639; 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=nBS9rsO9Qhx0tUJPOwYVI5240cw1jaogMugFmkMDc2M=;
        b=dC3+w+mRgcfFBQKayCVrEAXRzY0XuiEBmf0ZkgM5Y+nTd6S1weeapkBv0JaLReESdu
         Drlc9f/QrjABrsPssVUcRn//9Ovg/9S6zS6m6/9TG0ouReyouhtVGFvzs+qJliAufsib
         9QA1t7PhgzoUYIbePmNTFsZMVPQ/+UBBbaabPZfkQbZoehSKqHAB+gOBVsv49Z+NuqWD
         FsIsZ2D5VUonad1OER26Rg0cCfaGzaxwpuiKkQ+eqi65rCnNakqRRzIooLwV9ghfCGtT
         XAmh4UtOwCQb4A+VBWFXLiBl00UrEulScq+O6Xz4GeUMVyLSGI6UjqzC4JpV4WbgtFiD
         IEcA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749463839; x=1750068639; 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=nBS9rsO9Qhx0tUJPOwYVI5240cw1jaogMugFmkMDc2M=;
        b=GPixWGtncJHos0JwuEpPvQnvq/K9Nu6yqc/jCTQr67S+uvx/h3VmwXIU/UWhvx/xfL
         AKnVyYaSNgaUe3fXaH0cRfU0hXB5/g9krG1cfCyslcsOApBlAEtL4Ln+JpwIzXQeXoKi
         biRV609c9pdQVR0nj+Rc6PS5EsDjHw4dg+L2LArfU0ILa1GUwIR4r07eMHXFvu2WDggv
         eqvp+E16xNa8CfeIwlSpa2b970PGTnnVD5grwrDtpqrgMhjNOZp2IueObF2ACbWJLZpo
         mI67+d4xK7Nh919XZiV0oFh8SqiZq/Y95TKf9+4iffKuMpMw0EBrzn5TPMjzoVcxx50V
         UtTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749463839; x=1750068639;
        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=nBS9rsO9Qhx0tUJPOwYVI5240cw1jaogMugFmkMDc2M=;
        b=LgJwm6e6pxDq1av72yTL70FKXW1tbQMTB87jHEeZsVKy+LINXrrRLIjtYrw6LX+2jX
         DrLQIoGGE8eHgL1FIzgplXVA+CcYVEa24/SaNtUbYRFfnIzIxNWy4t86ZPR8MY37akxV
         dJhD36KuWn6+r0UDRIK3WiDCXnWZV2ctLJlkiZMDSuoRtz7i5NMFmcM7beKNYNkr91CY
         L7LCcDF+TwbNz1vLzs9nVaTUxgGyex7cIVy0ar3CgQKk0DgLKcVNoLdZQcwbax7wTFKa
         YaCoND+3JWaLjQlU8NbR7vbNr4SmFiSS7AP8DY3Hb5e1bE6o3v5c+JK7b5GfCjFMytpY
         Y9YQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUGVo5W6kXqWYbAIE8QDbBGWGn3oX9cjVbPVGUCHWps3nH+0xBm72gFNv07GufLCxbqKC8ZbinKmLkD@gnusha.org
X-Gm-Message-State: AOJu0YxAtPSkiDEUBoOfrQBtF9Xzdel+ti3Fi2eeWW8EeaDYSz8FoZsE
	bMqJOHJO+ofawxes5biID4JL595kdgayVB5TDvDBcgbIQuIzXLIU9Kke
X-Google-Smtp-Source: AGHT+IEf5MgJjf4aROsDufElrCc47ftFefGbPfIhsnf3JSusTEP0tk2TBcAC+kKJ0I22HOeafps+Nw==
X-Received: by 2002:a05:6820:1a06:b0:60f:874e:6601 with SMTP id 006d021491bc7-60f874e665emr5164874eaf.0.1749463827439;
        Mon, 09 Jun 2025 03:10:27 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZd1QfvvZvN2UxopAwIcXrXkoc9uH6Q+hurAMpx5JnTvSQ==
Received: by 2002:a4a:e9fb:0:b0:60b:a53c:36af with SMTP id 006d021491bc7-60f2845d792ls1147460eaf.2.-pod-prod-04-us;
 Mon, 09 Jun 2025 03:10:24 -0700 (PDT)
X-Received: by 2002:a05:6808:399a:b0:409:c6:c147 with SMTP id 5614622812f47-409051b6a89mr9242914b6e.6.1749463824322;
        Mon, 09 Jun 2025 03:10:24 -0700 (PDT)
Received: by 2002:a05:6808:5068:b0:3fa:da36:efcd with SMTP id 5614622812f47-408f0237c79msb6e;
        Thu, 5 Jun 2025 08:23:05 -0700 (PDT)
X-Received: by 2002:a05:690c:399:b0:70d:f673:1412 with SMTP id 00721157ae682-710d997e6bemr92166307b3.0.1749136973316;
        Thu, 05 Jun 2025 08:22:53 -0700 (PDT)
Date: Thu, 5 Jun 2025 08:22:52 -0700 (PDT)
From: Leo Wandersleb <lwandersleb@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <d6196c29-267f-4172-8b39-9e2abd344378n@googlegroups.com>
In-Reply-To: <dupr0g-yupBxLl70WyuEcfAIt1DNXZDY6Z_RuhZsKwAQro1aONB8IIWcsAjytBQjsDmlXsoDjBNI5KEaMqfzqIWLvrXY60gLKxy4n9wKzQg=@proton.me>
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>
 <dupr0g-yupBxLl70WyuEcfAIt1DNXZDY6Z_RuhZsKwAQro1aONB8IIWcsAjytBQjsDmlXsoDjBNI5KEaMqfzqIWLvrXY60gLKxy4n9wKzQg=@proton.me>
Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_118864_863109812.1749136972813"
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_118864_863109812.1749136972813
Content-Type: multipart/alternative; 
	boundary="----=_Part_118865_26444108.1749136972813"

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

Hi conduition,

I see the confusion - let me clarify step 3:

The "reveal" is an on-chain announcement that includes the full transaction=
=20
data, but it's not executed as a spending transaction yet. Think of it as:

```
Block N: Announcement TX containing:
- Full spending transaction (with signatures, witness data)
- Merkle proof linking to prior commitment
- Reference to target UTXO
```

This announcement transaction gets mined immediately (paying fees with=20
other inputs), but the vulnerable UTXO remains unspent. It's essentially=20
storing the transaction data on-chain for the contest period.

After 144 blocks, the winning transaction (oldest valid commitment) can be=
=20
executed as a normal spend. No double-spending or special states needed -=
=20
the UTXO simply can't be spent until the contest period ends and we know=20
which commitment won.

So yes, we're storing the transaction data twice (once in announcement,=20
once in actual execution), but this avoids any consensus-breaking changes=
=20
while protecting against quantum attacks.

Regards,

Leo

---

On Thursday, 5 June 2025 at 17:10:46 UTC+2 conduition wrote:

> Hi Leo,
>
> When a user reveals a transaction + commitment proof, are you
> assuming it will be included in a block? Or is the reveal TX
> somehow put "on ice" for those 144 blocks, and only then mined?=20
>
>
> If the former, this implies your protocol would need to allow
> double-spending of UTXOs even after many confirmations, as
> Tim has noted. Otherwise having an older announcement wouldn't
> give any advantage. I don't see how you'd implement this without
> breaking many founding assumptions of Bitcoin, maybe introducing
> some new special "confirmed-but-pending" state specifically
> for the outputs of these reveal TXs.
>
> If the latter, and the TX isn't immediately mineable, then how
> exactly do nodes know when to consider it consensus-valid?
> Imagine you're a node and you receive a reveal transaction
> with a valid (old enough) commitment proof. The TX claims
> to have been created 144 blocks ago and thus should be
> mineable. But how do you verify that, if the TX wasn't
> included in a past block?
>
> regards,
> conduition
>
> On Thursday, June 5th, 2025 at 7:55 AM, Leo Wandersleb <lwand...@gmail.co=
m>=20
> wrote:
>
> > 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.
> >=20
>
> > A scheme where the announcement does not contain the full transaction i=
s=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.
> >=20
>
> > So the scheme is:
> >=20
>
> > After activation at block height X:
> >=20
>
> > 1. **Vulnerable UTXOs cannot be spent directly** - they require a prior=
=20
> announcement
> > 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 a=
s=20
> a 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=20
> strongest announcement (oldest commitment of valid transaction wins).
> >=20
>
> > 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.
> >=20
>
> > Best,
> >=20
>
> > Leo
> > On Wednesday, 4 June 2025 at 20:40:32 UTC+2 Boris Nagaev wrote:
> >=20
>
> > > Hi Leo,
> > >=20
>
> > > I think it is possible to provide privacy for Satoshi and also reduce=
=20
> the size of a weak announcement (strong announcements can already be smal=
l:=20
> just a txid or a Merkle root of many txids).
> > >=20
>
> > > Importantly, we cannot include the whole signed transaction in the=20
> weak announcement. Doing so would leak the EC public key immediately,=20
> allowing an attacker to create their own valid weak announcement. We must=
=20
> avoid revealing the public key until the actual spending transaction is=
=20
> broadcast.
> > >=20
>
> > > 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.
> > >=20
>
> > > I think this is called a zero-knowledge proof. One simple approach=20
> could be to apply a tagged hash function to the concatenation of the EC=
=20
> public key and the future wTXID, and include this in the weak announcemen=
t.=20
> The structure would be:
> > >=20
>
> > > - UTXO (previous TXID and output index)
> > > - future spending wTXID
> > > - proof :=3D tagged_hash(EC public key || wTXID)
> > >=20
>
> > > 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.
> > >=20
>
> > > Satoshi could publish a strong announcement now and then monitor all=
=20
> weak announcements involving his UTXOs. If someone publishes a weak=20
> announcement for one of his coins, he could verify the "proof" field. If =
it=20
> is valid, it would mean someone has cracked his key with a quantum=20
> computer, and he would need to use his strong announcement immediately to=
=20
> reclaim the funds before the attacker does.
> > >=20
>
> > > Best,
> > > Boris
> > >=20
>
> > > On Wednesday, June 4, 2025 at 2:40:53=E2=80=AFPM UTC-3 Leo Wandersleb=
 wrote:
> > >=20
>
> > > > Hi Boris,
> > > > the announcements, weak and strong would have to not be transaction=
s=20
> yet to be compatible with legacy nodes and thus keep it a soft-fork. They=
=20
> could be OP_RETURN data. Only after the 144 blocks, the upgraded full nod=
es=20
> would 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?
> > > >=20
>
> > > > A node that gets updated would have to re-index all the blockchain=
=20
> to find announcements if we don't introduce a time frame for actually usi=
ng=20
> the 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.
> > > >=20
>
> > > > 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.
> > > >=20
>
> > > > Best,
> > > >=20
>
> > > > Leo
> > > >=20
>
> > > > On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Boris wrote:
> > > >=20
>
> > > > > Hi Leo,
> > > > >=20
>
> > > > > Thanks for the clarifications, much appreciated!
> > > > > I have a couple of questions:
> > > > >=20
>
> > > > > 1. How is a weak announcement stored in the blockchain and in the=
=20
> UTXO set?
> > > > > I assume it must be a transaction, correct? And it should somehow=
=20
> mark
> > > > > the UTXO as planned to be spent for 144 blocks?
> > > > > How would older (non-upgraded) nodes interpret a transaction
> > > > > containing a weak announcement? Would they just skip over it=20
> without
> > > > > any special processing?
> > > > > If so, is there a problem for nodes that upgrade after the fork:=
=20
> would
> > > > > they have to reprocess all blocks since the fork to find and inde=
x=20
> all
> > > > > missed weak announcements?
> > > > >=20
>
> > > > > 2. In the case of reclaiming a UTXO after a weak announcement by =
an
> > > > > attacker: why would the legitimate owner wait for a weak=20
> announcement
> > > > > at all?
> > > > > If the EC public key was already leaked, it seems they should=20
> publish
> > > > > a strong announcement themselves rather than wait. If the EC publ=
ic
> > > > > key wasn't leaked, there's nothing to worry about even if someone
> > > > > publishes a weak announcement: they are most likely bluffing, sin=
ce
> > > > > they wouldn't have the actual public key.
> > > > >=20
>
> > > > > Best,
> > > > > Boris
> > > > >=20
>
> > > > > On Tue, Jun 3, 2025 at 3:29=E2=80=AFPM Leo Wandersleb <lwand...@g=
mail.com>=20
> wrote:
> > > > > >
> > > > > > Hi conduition,
> > > > > >
> > > > > > Thanks for your careful analysis - excellent catches.
> > > > > >
> > > > > > You're absolutely right about the txid vulnerability. The=20
> commitment must be to the complete transaction including witness data=20
> (wTXID or equivalent) to prevent an attacker from pre-committing to=20
> unsigned transactions. This is essential - otherwise an attacker could=20
> indeed enumerate the UTXO set and create commitments without knowing the=
=20
> private keys.
> > > > > >
> > > > > > Regarding updates: You're correct that frequent updates would b=
e=20
> needed as wallets receive new UTXOs. However, I don't see this as a major=
=20
> issue - users could batch their commitments periodically (say, monthly)=
=20
> rather than after every transaction. The scheme is particularly important=
=20
> for existing UTXOs that already have exposed pubkeys (old P2PK, reused=20
> addresses, etc.). For new UTXOs, wallets should ideally migrate to=20
> quantum-safe addresses once available. OpenTimestamps aggregation would=
=20
> indeed help with scaling and provide plausible deniability about the numb=
er=20
> of UTXOs being protected.
> > > > > >
> > > > > > The time delay serves a different purpose than you might expect=
.=20
> It's not about preventing commitment forgery after pubkey exposure, but=
=20
> rather about allowing priority based on commitment age when multiple=20
> parties claim the same UTXO:
> > > > > >
> > > > > > 1. Weak announcement starts the 144-block window
> > > > > > 2. During this window, anyone with a strong commitment can=20
> reveal it
> > > > > > 3. The oldest valid commitment wins
> > > > > >
> > > > > > This creates the "poison pill" effect: an attacker might crack =
a=20
> key and try to spend a UTXO, but if the original owner has an older=20
> commitment, they can reclaim it during the window. The uncertainty about=
=20
> which UTXOs have poison pills makes attacking large "lost" UTXOs risky -=
=20
> hence less disruptive to the network.
> > > > > >
> > > > > > The delay essentially allows a "commitment priority contest"=20
> where age determines the winner, protecting users who prepared early whil=
e=20
> still allowing these users to not move their funds.
> > > > > >
> > > > > > Best,
> > > > > >
> > > > > > Leo
> > > > > >
> > > > > > --
> > > > > > You received this message because you are subscribed to the=20
> Google Groups "Bitcoin Development Mailing List" group.
> > > > > > To unsubscribe from this group and stop receiving emails from=
=20
> it, send an email to bitcoindev+...@googlegroups.com.
> > > > > > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e100=
6accdb55n%40googlegroups.com
> .
> > > > >=20
>
> > > > >=20
>
> > > > >=20
>
> > > > > --
> > > > > Best regards,
> > > > > Boris Nagaev
> >=20
>
> > --
> > You received this message because you are subscribed to the Google=20
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/ea71bbd5-1325-445b-977f-a52b=
8017eab4n%40googlegroups.com
> .

--=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/=
d6196c29-267f-4172-8b39-9e2abd344378n%40googlegroups.com.

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

Hi conduition,<div><br />I see the confusion - let me clarify step 3:<br />=
<br />The "reveal" is an on-chain announcement that includes the full trans=
action data, but it's not executed as a spending transaction yet. Think of =
it as:<br /><br />```<br />Block N: Announcement TX containing:<br />- Full=
 spending transaction (with signatures, witness data)<br />- Merkle proof l=
inking to prior commitment<br />- Reference to target UTXO<br />```<br /><b=
r />This announcement transaction gets mined immediately (paying fees with =
other inputs), but the vulnerable UTXO remains unspent. It's essentially st=
oring the transaction data on-chain for the contest period.<br /><br />Afte=
r 144 blocks, the winning transaction (oldest valid commitment) can be exec=
uted as a normal spend. No double-spending or special states needed - the U=
TXO simply can't be spent until the contest period ends and we know which c=
ommitment won.<br /><br />So yes, we're storing the transaction data twice =
(once in announcement, once in actual execution), but this avoids any conse=
nsus-breaking changes while protecting against quantum attacks.</div><div><=
br /></div><div>Regards,</div><div><br /></div><div>Leo<br /><br />---<br /=
><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_at=
tr">On Thursday, 5 June 2025 at 17:10:46 UTC+2 conduition wrote:<br/></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Leo,
<br>
<br>When a user reveals a transaction + commitment proof, are you
<br>assuming it will be included in a block? Or is the reveal TX
<br>somehow put &quot;on ice&quot; for those 144 blocks, and only then mine=
d?=20
<br>
<br>
<br>If the former, this implies your protocol would need to allow
<br>double-spending of UTXOs even after many confirmations, as
<br>Tim has noted. Otherwise having an older announcement wouldn&#39;t
<br>give any advantage. I don&#39;t see how you&#39;d implement this withou=
t
<br>breaking many founding assumptions of Bitcoin, maybe introducing
<br>some new special &quot;confirmed-but-pending&quot; state specifically
<br>for the outputs of these reveal TXs.
<br>
<br>If the latter, and the TX isn&#39;t immediately mineable, then how
<br>exactly do nodes know when to consider it consensus-valid?
<br>Imagine you&#39;re a node and you receive a reveal transaction
<br>with a valid (old enough) commitment proof. The TX claims
<br>to have been created 144 blocks ago and thus should be
<br>mineable. But how do you verify that, if the TX wasn&#39;t
<br>included in a past block?
<br>
<br>regards,
<br>conduition
<br>
<br>On Thursday, June 5th, 2025 at 7:55 AM, Leo Wandersleb &lt;<a href data=
-email-masked rel=3D"nofollow">lwand...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Hi Boris, hi list,
<br>&gt; I think the weak announcement is a bad idea once EC crypto is brok=
en 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 wit=
h a full transaction, he cannot win even if he gets into a block first, as =
the strong announcement proves a prior commitment to that transaction and w=
ould win even if it gets mined only some blocks later.
<br>&gt;=20
<br>
<br>&gt; A scheme where the announcement does not contain the full transact=
ion is problematic as the transaction might then turn out to not be valid. =
Then nodes would wait for the &quot;winning&quot; wtxid blocking the UTXO f=
orever.
<br>&gt;=20
<br>
<br>&gt; So the scheme is:
<br>&gt;=20
<br>
<br>&gt; After activation at block height X:
<br>&gt;=20
<br>
<br>&gt; 1. **Vulnerable UTXOs cannot be spent directly** - they require a =
prior announcement
<br>&gt; 2. **Commitment** to a wTXID that spends the vulnerable UTXO. Mult=
iple wTXIDs can be stored in a hash tree in an OP_RETURN
<br>&gt; 3. **Reveal** full transaction with proof of prior commitment but =
not as a normal transaction yet
<br>&gt; 4. **Counter Reveal**: For 144 blocks, others can reveal older com=
mitments. This protects exposed pubkeys!
<br>&gt; 5. **After 144 blocks**: The UTXO can be spent according to the st=
rongest announcement (oldest commitment of valid transaction wins).
<br>&gt;=20
<br>
<br>&gt; 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>&gt;=20
<br>
<br>&gt; Best,
<br>&gt;=20
<br>
<br>&gt; Leo
<br>&gt; On Wednesday, 4 June 2025 at 20:40:32 UTC+2 Boris Nagaev wrote:
<br>&gt;=20
<br>
<br>&gt; &gt; Hi Leo,
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; I think it is possible to provide privacy for Satoshi and als=
o reduce the size of a weak announcement (strong announcements can already =
be small: just a txid or a Merkle root of many txids).
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; Importantly, we cannot include the whole signed transaction i=
n 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 public key until the actual spending transaction is bro=
adcast.
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; We need a scheme where the EC public key is not leaked in a w=
eak announcement, 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 ve=
rify a past weak announcement (to validate the transaction when it is broad=
cast). This reduces to the following requirement: we need a proof of knowle=
dge of the EC public key that can be verified if the public key is known an=
d provides no information otherwise.
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; I think this is called a zero-knowledge proof. One simple app=
roach 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 announceme=
nt. The structure would be:
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; -   UTXO (previous TXID and output index)
<br>&gt; &gt; -   future spending wTXID
<br>&gt; &gt; -   proof :=3D tagged_hash(EC public key || wTXID)
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; The wTXID is included in the concatenation to bind the proof =
to a particular future transaction. Otherwise, someone could copy a weak an=
nouncement and substitute their own wTXID.
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; Satoshi could publish a strong announcement now and then moni=
tor all weak announcements involving his UTXOs. If someone publishes a weak=
 announcement for one of his coins, he could verify the &quot;proof&quot; f=
ield. If it is valid, it would mean someone has cracked his key with a quan=
tum computer, and he would need to use his strong announcement immediately =
to reclaim the funds before the attacker does.
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; Best,
<br>&gt; &gt; Boris
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; On Wednesday, June 4, 2025 at 2:40:53=E2=80=AFPM UTC-3 Leo Wa=
ndersleb wrote:
<br>&gt; &gt;=20
<br>
<br>&gt; &gt; &gt; Hi Boris,
<br>&gt; &gt; &gt; 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. Only after the 144 blocks, the upgrade=
d full nodes would allow the inclusion of the actual transaction. This woul=
d mean the transaction would be both in full in the OP_RETURN strong announ=
cement and without the witness part later, so it would be a bit expensive t=
his way but maybe we can do better?
<br>&gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; 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 announcement =
has to be used within another 1000 blocks. Then the upgrading node would ha=
ve to re-index the last 1000 blocks.
<br>&gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; The legitimate owner of a UTXO might wait for an attack =
for privacy reasons. My proposal would allow Satoshi himself to make all hi=
s 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 t=
ried to attack and not in 2027 when people started to panic because of immi=
nent quantum breakthroughs.
<br>&gt; &gt; &gt; Hmm ... a problem is the weak announcement doesn&#39;t r=
equire keys, so anybody could provoke Satoshi to come forward. Maybe we hav=
e to add key ownership as a requirement for the &quot;weak&quot; announceme=
nt, too. So it should also contain a serialized transaction.
<br>&gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; Best,
<br>&gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; Leo
<br>&gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Boris=
 wrote:
<br>&gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; &gt; Hi Leo,
<br>&gt; &gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; &gt; Thanks for the clarifications, much appreciated!
<br>&gt; &gt; &gt; &gt; I have a couple of questions:
<br>&gt; &gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; &gt; 1. How is a weak announcement stored in the blockch=
ain and in the UTXO set?
<br>&gt; &gt; &gt; &gt; I assume it must be a transaction, correct? And it =
should somehow mark
<br>&gt; &gt; &gt; &gt; the UTXO as planned to be spent for 144 blocks?
<br>&gt; &gt; &gt; &gt; How would older (non-upgraded) nodes interpret a tr=
ansaction
<br>&gt; &gt; &gt; &gt; containing a weak announcement? Would they just ski=
p over it without
<br>&gt; &gt; &gt; &gt; any special processing?
<br>&gt; &gt; &gt; &gt; If so, is there a problem for nodes that upgrade af=
ter the fork: would
<br>&gt; &gt; &gt; &gt; they have to reprocess all blocks since the fork to=
 find and index all
<br>&gt; &gt; &gt; &gt; missed weak announcements?
<br>&gt; &gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; &gt; 2. In the case of reclaiming a UTXO after a weak an=
nouncement by an
<br>&gt; &gt; &gt; &gt; attacker: why would the legitimate owner wait for a=
 weak announcement
<br>&gt; &gt; &gt; &gt; at all?
<br>&gt; &gt; &gt; &gt; If the EC public key was already leaked, it seems t=
hey should publish
<br>&gt; &gt; &gt; &gt; a strong announcement themselves rather than wait. =
If the EC public
<br>&gt; &gt; &gt; &gt; key wasn&#39;t leaked, there&#39;s nothing to worry=
 about even if someone
<br>&gt; &gt; &gt; &gt; publishes a weak announcement: they are most likely=
 bluffing, since
<br>&gt; &gt; &gt; &gt; they wouldn&#39;t have the actual public key.
<br>&gt; &gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; &gt; Best,
<br>&gt; &gt; &gt; &gt; Boris
<br>&gt; &gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; &gt; On Tue, Jun 3, 2025 at 3:29=E2=80=AFPM Leo Wandersl=
eb &lt;<a href data-email-masked rel=3D"nofollow">lwand...@gmail.com</a>&gt=
; wrote:
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; Hi conduition,
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; Thanks for your careful analysis - excellent c=
atches.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; You&#39;re absolutely right about the txid vul=
nerability. The commitment must be to the complete transaction including wi=
tness data (wTXID or equivalent) to prevent an attacker from pre-committing=
 to unsigned transactions. This is essential - otherwise an attacker could =
indeed enumerate the UTXO set and create commitments without knowing the pr=
ivate keys.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; Regarding updates: You&#39;re correct that fre=
quent 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 perio=
dically (say, monthly) rather than after every transaction. The scheme is p=
articularly important for existing UTXOs that already have exposed pubkeys =
(old P2PK, reused addresses, etc.). For new UTXOs, wallets should ideally m=
igrate to quantum-safe addresses once available. OpenTimestamps aggregation=
 would indeed help with scaling and provide plausible deniability about the=
 number of UTXOs being protected.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; The time delay serves a different purpose than=
 you might expect. It&#39;s not about preventing commitment forgery after p=
ubkey exposure, but rather about allowing priority based on commitment age =
when multiple parties claim the same UTXO:
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; 1. Weak announcement starts the 144-block wind=
ow
<br>&gt; &gt; &gt; &gt; &gt; 2. During this window, anyone with a strong co=
mmitment can reveal it
<br>&gt; &gt; &gt; &gt; &gt; 3. The oldest valid commitment wins
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; This creates the &quot;poison pill&quot; effec=
t: an attacker might crack a key and try to spend a UTXO, but if the origin=
al owner has an older commitment, they can reclaim it during the window. Th=
e uncertainty about which UTXOs have poison pills makes attacking large &qu=
ot;lost&quot; UTXOs risky - hence less disruptive to the network.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; The delay essentially allows a &quot;commitmen=
t priority contest&quot; where age determines the winner, protecting users =
who prepared early while still allowing these users to not move their funds=
.
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; Best,
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; Leo
<br>&gt; &gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; &gt; --
<br>&gt; &gt; &gt; &gt; &gt; You received this message because you are subs=
cribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; gr=
oup.
<br>&gt; &gt; &gt; &gt; &gt; To unsubscribe from this group and stop receiv=
ing emails from it, send an email to <a href data-email-masked rel=3D"nofol=
low">bitcoindev+...@googlegroups.com</a>.
<br>&gt; &gt; &gt; &gt; &gt; To view this discussion visit <a href=3D"https=
://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb5=
5n%40googlegroups.com" target=3D"_blank" rel=3D"nofollow" data-saferedirect=
url=3D"https://www.google.com/url?hl=3Den-GB&amp;q=3Dhttps://groups.google.=
com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%2540googlegrou=
ps.com&amp;source=3Dgmail&amp;ust=3D1749222761458000&amp;usg=3DAOvVaw2IZDdU=
Zh5q4I-AyCejp8VV">https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac8=
7-40fd-93ef-e1006accdb55n%40googlegroups.com</a>.
<br>&gt; &gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; &gt;=20
<br>
<br>&gt; &gt; &gt; &gt; --
<br>&gt; &gt; &gt; &gt; Best regards,
<br>&gt; &gt; &gt; &gt; Boris Nagaev
<br>&gt;=20
<br>
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@=
googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/ea71bbd5-1325-445b-977f-a52b8017eab4n%40googlegroups.co=
m" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Den-GB&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoind=
ev/ea71bbd5-1325-445b-977f-a52b8017eab4n%2540googlegroups.com&amp;source=3D=
gmail&amp;ust=3D1749222761458000&amp;usg=3DAOvVaw2OOgChp94Mw5vkkSB9f8E_">ht=
tps://groups.google.com/d/msgid/bitcoindev/ea71bbd5-1325-445b-977f-a52b8017=
eab4n%40googlegroups.com</a>.</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/d6196c29-267f-4172-8b39-9e2abd344378n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/d6196c29-267f-4172-8b39-9e2abd344378n%40googlegroups.com</a>.<br />

------=_Part_118865_26444108.1749136972813--

------=_Part_118864_863109812.1749136972813--