From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <2ed6d831-d87d-44f0-82b9-c8b9abaa8010n@googlegroups.com> References: <2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a@gmail.com> <33f67e84-5d1c-4c14-80b9-90a3fec3cb36@gmail.com> <5e393f57-ac87-40fd-93ef-e1006accdb55n@googlegroups.com> <5d9f6ac9-a623-4636-8a91-ee7c057bc08an@googlegroups.com> <44b5aa4c-a71b-49ed-beee-071140b16aacn@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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 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,

if I understand it right, your prop= osal is closer to=C2=A0Tadge Dryja's "Post-Quantum commit / reveal Fawkescoin variant as a= soft fork"? It would exclusively 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 N= agaev wrote:
= Hi Leo, hi list,

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.

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

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.
This design prevents an attacker from maliciously blocking someone el= se's coin. There is no "earliest announcement wins" 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.
The scheme also preserves Satoshi's privacy: anyone can publish an= announcement for Satoshi's coins, but without the actual spending tran= saction, nobody can tell whether the announcement is valid.

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.

Best,
Bor= is

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

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.

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 "winning" wtxi= d 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 announcement=C2=A0
2. **Commitment** to a wTXID that spends the= vulnerable UTXO. Multiple wTXIDs can be stored in a hash tree in an OP_RET= URN
3. **Reveal** full transaction with proof of prior commitment but no= t as a normal transaction yet
4. **Counter Reveal**: For 144 bloc= ks, others can reveal older commitments. This protects exposed pubkeys!
= 5. **After 144 blocks**: The UTXO can be spent according to the strongest a= nnouncement (oldest commitment of valid transaction wins).

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.

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 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).

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.

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.

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:
  • =C2=A0 = =C2=A0 UTXO (previous TXID and output index)
  • =C2=A0 =C2=A0 future s= pending wTXID
  • =C2=A0 =C2=A0 proof :=3D tagged_hash(EC public key ||= wTXID)
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.

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 "proof" 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.

Best,
Boris

On Wednesday= , June 4, 2025 at 2:40:53=E2=80=AFPM UTC-3 Leo Wandersleb wrote:
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex">Hi Boris,

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?

A node that gets updated would have to re-index all = the blockchain to find announcements if we don't introduce a time frame= for actually using the 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.

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>
Hmm ... a problem is the weak announcement doesn't require ke= ys, 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 should also contain a serialized transaction.

Best,

Leo

On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Boris wrote:
Hi Leo,

Thanks for the clarifications, much appreciated!
I have a couple of questions:

1. How is a weak announcement stored in the blockchain and in the UTXO = set?
I assume it must be a transaction, correct? And it should somehow mark
the UTXO as planned to be spent for 144 blocks?
How would older (non-upgraded) nodes interpret a transaction
containing a weak announcement? Would they just skip over it without
any special processing?
If so, is there a problem for nodes that upgrade after the fork: would
they have to reprocess all blocks since the fork to find and index all
missed weak announcements?

2. In the case of reclaiming a UTXO after a weak announcement by an
attacker: why would the legitimate owner wait for a weak announcement
at all?
If the EC public key was already leaked, it seems they should publish
a strong announcement themselves rather than wait. If the EC public
key wasn't leaked, there's nothing to worry about even if someo= ne
publishes a weak announcement: they are most likely bluffing, since
they wouldn't have the actual public key.

Best,
Boris

On Tue, Jun 3, 2025 at 3:29=E2=80=AFPM Leo Wandersleb <lwand...@gmail.com> wrote:
>
> Hi conduition,
>
> Thanks for your careful analysis - excellent catches.
>
> You're absolutely right about the txid vulnerability. The 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.
>
> 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, 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.
>
> The time delay serves a different purpose than you might expect. I= t'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:
>
> 1. Weak announcement starts the 144-block window
> 2. During this window, anyone with a strong commitment can reveal = it
> 3. The oldest valid commitment wins
>
> This creates the "poison pill" effect: an attacker might= crack a key 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 "lost" UTXOs = risky - hence less disruptive to the network.
>
> The delay essentially allows a "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.
>
> Best,
>
> Leo
>
> --
> 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 email to bitcoindev+...@googlegroups.com.
> To view this discussion visit ht= tps://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006acc= db55n%40googlegroups.com.



--=20
Best regards,
Boris Nagaev
<= /div>

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/ccd3f262-d3c6-45e1-ba89-e84116da36f3n%40googlegroups.com.
------=_Part_117097_1151683106.1749136357155-- ------=_Part_117096_394704256.1749136357155--