From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 05 Jun 2025 07:59:10 -0700 Received: from mail-yw1-f186.google.com ([209.85.128.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uNC3g-0000Uv-Nl for bitcoindev@gnusha.org; Thu, 05 Jun 2025 07:59:10 -0700 Received: by mail-yw1-f186.google.com with SMTP id 00721157ae682-70e33aeaad4sf13682967b3.0 for ; Thu, 05 Jun 2025 07:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749135543; x=1749740343; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=T8uDtVtCnB9UofsdWzHPcCoeopQh8oQYdFPt92sE56M=; b=StdaF+IQ9/0ESmJNXUsgj4a14mnyMYBne9bM2WmwxEa3awLc6We5N9kCRum2VOJksL awZy2B5EthH2LX57JTBMrUlI0DSVPpx9G3FSNSg0Po3+0faDiNEXpusMlvX25rjCbVcY CKh4r88BWt+MArE0DfAjRGTujoIBxcVHCfirxRFwf5RLjY3VRN4e1Mi52/m50KOKW0Ad KJwVo4KiCgCD8p1jLX87UmFsVuC49ccO455sQEGBjkBQGe/L2TvxFRZkpmBBWR+TbmCX ArnvzQrfTKEOdlI9IhrZP1FAW2VoLHP3A7KizoDeMimbS6+S7EAuFbSnN1x3Y5r/8SGJ NjeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749135543; x=1749740343; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=T8uDtVtCnB9UofsdWzHPcCoeopQh8oQYdFPt92sE56M=; b=ThioF74PhPEZqcX6XYhnhQNr/Us5gB+wYv8DL2msYm0bGT90uGc2P0T9Q1kiGhzXKF NCZ6eoInqklIoDFG0oah6sJ6xrzivyyGdCpxFFlj5i8X3xtuI/Q/B6d4Bu2QTGCPTHUz rhgoyaHP0gjQDQsqHk04WDX6arCGWWkqlg3Evc+AFTOw/gzdCmREXCApojEtTfxpbUhl cCoWfHecVGdSgwlyouIpGEN8rUspABtheLm7xgP6KTAqBbS12IMwSCYx/C4r+lNZBP4J Ie0TQ8fcCIExaRpe08UBRSyM7zoTaFNPsgACm4FbxUMeOal7JsZrgssHf7yo9EewNcy5 jnQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749135543; x=1749740343; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=T8uDtVtCnB9UofsdWzHPcCoeopQh8oQYdFPt92sE56M=; b=FRg/W5Il1xIG/PM7rB8no3BHrfz9KbHJTRScqt40b4KYoJ8a0oZCjjQJS2brXHtlIG 8sB/P7a5k6h7rLWNagPR8+lT3HeM8S1NmDl4Fq38/h9MZuZNoQYVZNhIR1vwUyxg+17a 5WDkOcrS2GUWTGtMren7RZLwkxgZ10GbeDn1VHgKDqjLWIMH1RVQ2cFynyO4gh3Jwr0w 6OW6H3aqNoPU2iIUscc8ZVeKq3QJzp8OJF7Lv8U3OTuhjP5UUrP7QqkbZu+HFblBulVV 6kkO/sj2ReZcwH1H0YbclC1q3V4C4dr9YNv4W6+7oDYyfVVJSPY7U903CctcEiGvq2IG 2WPw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVZdHvU/G51kF/qu8JORYJ9GDgG3MdAc89OW1We5dMu5q+X7xQnYrxma9BkJFsQhfTeCWZGhgDjxj15@gnusha.org X-Gm-Message-State: AOJu0YzbYjBI82Km2t0bkLZIXJe/3vKfliLLvotP82YXN2sKeM92nlRK qge6xMKlldB9D507rt2Y6nDgzY49MjPk8LxRnZIIYufwxQWiQVo9dgie X-Google-Smtp-Source: AGHT+IEkbGdfQvEAAzDu/4gcDjSOoARVnHuEQI8jH0dE5qdN12Yjt1BXsQAdj5jrt7sZzNeeVHQ2OA== X-Received: by 2002:a05:6902:1692:b0:e7d:6a68:f572 with SMTP id 3f1490d57ef6-e81a209d9b2mr114051276.10.1749135542336; Thu, 05 Jun 2025 07:59:02 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcLVCTqgw4ygFUF5BY54YqkPy6SS0dghR5DHLhxCxIlQw== Received: by 2002:a25:d386:0:b0:e7d:804c:d381 with SMTP id 3f1490d57ef6-e8188a2baf7ls1153046276.2.-pod-prod-00-us; Thu, 05 Jun 2025 07:58:58 -0700 (PDT) X-Received: by 2002:a05:690c:f8e:b0:70c:c20a:89a5 with SMTP id 00721157ae682-710e7ef82e5mr49699677b3.19.1749135538443; Thu, 05 Jun 2025 07:58:58 -0700 (PDT) Received: by 2002:a05:690c:7741:b0:710:f35d:a3b2 with SMTP id 00721157ae682-710f35da70ams7b3; Thu, 5 Jun 2025 07:54:27 -0700 (PDT) X-Received: by 2002:a05:690c:f07:b0:70e:25b2:8f42 with SMTP id 00721157ae682-710e7efa238mr55358937b3.18.1749135265946; Thu, 05 Jun 2025 07:54:25 -0700 (PDT) Date: Thu, 5 Jun 2025 07:54:25 -0700 (PDT) From: Boris Nagaev To: Bitcoin Development Mailing List Message-Id: <2ed6d831-d87d-44f0-82b9-c8b9abaa8010n@googlegroups.com> In-Reply-To: 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> Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_116060_1784724860.1749135265323" X-Original-Sender: bnagaev@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_116060_1784724860.1749135265323 Content-Type: multipart/alternative; boundary="----=_Part_116061_1164823195.1749135265323" ------=_Part_116061_1164823195.1749135265323 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Leo, hi list, You raise a valid point that a wTXID coming from a quantum attacker could= =20 be invalid, and the scheme must be robust against this. In this scenario,= =20 the attacker is not motivated by profit but rather by the desire to harm=20 the legitimate owner. I think we do not need to include a full transaction in the announcement to= =20 address this. I propose the following scheme. There is just one announcement type, which= =20 was defined as a weak proof in my previous message. An announcement=20 includes the UTXO, wTXID, and a proof (tagged_hash(EC public key ||=20 wTXID)). This tuple can be stored in an OP_RETURN output. The rule of a=20 hypothetical soft fork would be: to spend an EC output, there must be an=20 announcement with the corresponding wTXID and a valid proof published at=20 least X blocks earlier. This design prevents an attacker from maliciously blocking someone else's= =20 coin. There is no "earliest announcement wins" rule. Any valid announcement= =20 wins once it is sufficiently buried. If an attacker publishes an invalid=20 announcement, the legitimate owner can simply publish their own and wait X= =20 blocks before sweeping the funds. If they have already published an=20 announcement (as they should), they can use it without delay. The scheme also preserves Satoshi's privacy: anyone can publish an=20 announcement for Satoshi's coins, but without the actual spending=20 transaction, nobody can tell whether the announcement is valid. A downside of the scheme is that all announcements must be stored by nodes= =20 until the corresponding UTXO is spent, and there can be multiple=20 announcements for a single coin. Another downside is that announcements=20 cannot be packed into a Merkle root, because the UTXO must be visible for= =20 Satoshi to identify his coins, and he must be able to verify the proof.=20 Perhaps there are ways to improve the scheme to address these efficiency=20 issues. Best, Boris On Thursday, June 5, 2025 at 9:55:34=E2=80=AFAM UTC-3 Leo Wandersleb wrote: Hi Boris, hi list, I think the weak announcement is a bad idea once EC crypto is broken to the= =20 point where an attacker can break the key before the transaction gets mined= =20 but the strong announcements should still hold as they have less urgency.= =20 If the attacker sees the transaction in a strong announcement with a full= =20 transaction, he cannot win even if he gets into a block first, as the=20 strong announcement proves a prior commitment to that transaction and would= =20 win even if it gets mined only some blocks later. A scheme where the announcement does not contain the full transaction is=20 problematic as the transaction might then turn out to not be valid. Then=20 nodes would wait for the "winning" wtxid blocking the UTXO forever. So the scheme is: After activation at block height X: 1. **Vulnerable UTXOs cannot be spent directly** - they require a prior=20 announcement=20 2. **Commitment** to a wTXID that spends the vulnerable UTXO. Multiple=20 wTXIDs can be stored in a hash tree in an OP_RETURN 3. **Reveal** full transaction with proof of prior commitment but not as a= =20 normal transaction yet 4. **Counter Reveal**: For 144 blocks, others can reveal older commitments.= =20 This protects exposed pubkeys! 5. **After 144 blocks**: The UTXO can be spent according to the strongest= =20 announcement (oldest commitment of valid transaction wins). As (5) is just the normal transaction, the scheme is a soft fork and=20 compatible with pre-recorded transactions where the keys were lost. It=20 would at least double the on-chain costs for these vulnerable UTXOs as they= =20 would have to store the full transaction twice. We can make the=20 announcements prunable again though. Best, Leo On Wednesday, 4 June 2025 at 20:40:32 UTC+2 Boris Nagaev wrote: Hi Leo, I think it is possible to provide privacy for Satoshi and also reduce the= =20 size of a weak announcement (strong announcements can already be small:=20 just a txid or a Merkle root of many txids). Importantly, we cannot include the whole signed transaction in the weak=20 announcement. Doing so would leak the EC public key immediately, allowing= =20 an attacker to create their own valid weak announcement. We must avoid=20 revealing the public key until the actual spending transaction is broadcast= . We need a scheme where the EC public key is not leaked in a weak=20 announcement, but the legitimate owner can verify it, while no one else=20 can. Also, once the EC public key is revealed, anyone should be able to=20 verify a past weak announcement (to validate the transaction when it is=20 broadcast). This reduces to the following requirement: we need a proof of= =20 knowledge of the EC public key that can be verified if the public key is=20 known and provides no information otherwise. I think this is called a zero-knowledge proof. One simple approach could be= =20 to apply a tagged hash function to the concatenation of the EC public key= =20 and the future wTXID, and include this in the weak announcement. The=20 structure would be: - UTXO (previous TXID and output index) - future spending wTXID - proof :=3D tagged_hash(EC public key || wTXID) The wTXID is included in the concatenation to bind the proof to a=20 particular future transaction. Otherwise, someone could copy a weak=20 announcement and substitute their own wTXID. Satoshi could publish a strong announcement now and then monitor all weak= =20 announcements involving his UTXOs. If someone publishes a weak announcement= =20 for one of his coins, he could verify the "proof" field. If it is valid, it= =20 would mean someone has cracked his key with a quantum computer, and he=20 would need to use his strong announcement immediately to reclaim the funds= =20 before the attacker does. Best, Boris On Wednesday, June 4, 2025 at 2:40:53=E2=80=AFPM UTC-3 Leo Wandersleb wrote= : Hi Boris, the announcements, weak and strong would have to not be transactions yet to= =20 be compatible with legacy nodes and thus keep it a soft-fork. They could be= =20 OP_RETURN data. Only after the 144 blocks, the upgraded full nodes would=20 allow the inclusion of the actual transaction. This would mean the=20 transaction would be both in full in the OP_RETURN strong announcement and= =20 without the witness part later, so it would be a bit expensive this way but= =20 maybe we can do better? A node that gets updated would have to re-index all the blockchain to find= =20 announcements if we don't introduce a time frame for actually using the=20 announcements. We could also say that any announcement has to be used=20 within another 1000 blocks. Then the upgrading node would have to re-index= =20 the last 1000 blocks. The legitimate owner of a UTXO might wait for an attack for privacy=20 reasons. My proposal would allow Satoshi himself to make all his UTXOs=20 quantum safe without any of us learning about him being active. He could=20 add one 64B OP_RETURN in 2027 and when QC becomes an issue, we would learn= =20 about him having been active in 2027 in 2040 when actually somebody tried= =20 to attack and not in 2027 when people started to panic because of imminent= =20 quantum breakthroughs. Hmm ... a problem is the weak announcement doesn't require keys, so anybody= =20 could provoke Satoshi to come forward. Maybe we have to add key ownership= =20 as a requirement for the "weak" announcement, too. So it should also=20 contain a serialized transaction. Best, Leo On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Boris wrote: Hi Leo,=20 Thanks for the clarifications, much appreciated!=20 I have a couple of questions:=20 1. How is a weak announcement stored in the blockchain and in the UTXO set?= =20 I assume it must be a transaction, correct? And it should somehow mark=20 the UTXO as planned to be spent for 144 blocks?=20 How would older (non-upgraded) nodes interpret a transaction=20 containing a weak announcement? Would they just skip over it without=20 any special processing?=20 If so, is there a problem for nodes that upgrade after the fork: would=20 they have to reprocess all blocks since the fork to find and index all=20 missed weak announcements?=20 2. In the case of reclaiming a UTXO after a weak announcement by an=20 attacker: why would the legitimate owner wait for a weak announcement=20 at all?=20 If the EC public key was already leaked, it seems they should publish=20 a strong announcement themselves rather than wait. If the EC public=20 key wasn't leaked, there's nothing to worry about even if someone=20 publishes a weak announcement: they are most likely bluffing, since=20 they wouldn't have the actual public key.=20 Best,=20 Boris=20 On Tue, Jun 3, 2025 at 3:29=E2=80=AFPM Leo Wandersleb = wrote:=20 >=20 > Hi conduition,=20 >=20 > Thanks for your careful analysis - excellent catches.=20 >=20 > You're absolutely right about the txid vulnerability. The commitment must= =20 be to the complete transaction including witness data (wTXID or equivalent)= =20 to prevent an attacker from pre-committing to unsigned transactions. This= =20 is essential - otherwise an attacker could indeed enumerate the UTXO set=20 and create commitments without knowing the private keys.=20 >=20 > Regarding updates: You're correct that frequent updates would be needed= =20 as wallets receive new UTXOs. However, I don't see this as a major issue -= =20 users could batch their commitments periodically (say, monthly) rather than= =20 after every transaction. The scheme is particularly important for existing= =20 UTXOs that already have exposed pubkeys (old P2PK, reused addresses, etc.).= =20 For new UTXOs, wallets should ideally migrate to quantum-safe addresses=20 once available. OpenTimestamps aggregation would indeed help with scaling= =20 and provide plausible deniability about the number of UTXOs being=20 protected.=20 >=20 > The time delay serves a different purpose than you might expect. It's not= =20 about preventing commitment forgery after pubkey exposure, but rather about= =20 allowing priority based on commitment age when multiple parties claim the= =20 same UTXO:=20 >=20 > 1. Weak announcement starts the 144-block window=20 > 2. During this window, anyone with a strong commitment can reveal it=20 > 3. The oldest valid commitment wins=20 >=20 > This creates the "poison pill" effect: an attacker might crack a key and= =20 try to spend a UTXO, but if the original owner has an older commitment,=20 they can reclaim it during the window. The uncertainty about which UTXOs=20 have poison pills makes attacking large "lost" UTXOs risky - hence less=20 disruptive to the network.=20 >=20 > The delay essentially allows a "commitment priority contest" where age=20 determines the winner, protecting users who prepared early while still=20 allowing these users to not move their funds.=20 >=20 > Best,=20 >=20 > Leo=20 >=20 > --=20 > You received this message because you are subscribed to the Google Groups= =20 "Bitcoin Development Mailing List" group.=20 > To unsubscribe from this group and stop receiving emails from it, send an= =20 email to bitcoindev+...@googlegroups.com.=20 > To view this discussion visit=20 https://groups.google.com/d/msgid/bitcoindev/5e393f57-ac87-40fd-93ef-e1006a= ccdb55n%40googlegroups.com.=20 --=20 Best regards,=20 Boris Nagaev=20 --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 2ed6d831-d87d-44f0-82b9-c8b9abaa8010n%40googlegroups.com. ------=_Part_116061_1164823195.1749135265323 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Leo, hi list,

You raise a valid point that a wTXID coming fro= m a quantum attacker could be invalid, and the scheme must be robust agains= t this. In this scenario, the attacker is not motivated by profit but rathe= r by the desire to harm the legitimate owner.

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

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

This design prevents an attacker from maliciously blo= cking someone else's coin. There is no "earliest announcement wins" rule. A= ny valid announcement wins once it is sufficiently buried. If an attacker p= ublishes an invalid announcement, the legitimate owner can simply publish t= heir own and wait X blocks before sweeping the funds. If they have already = published an announcement (as they should), they can use it without delay.<= br />
The scheme also preserves Satoshi's privacy: anyone can publish = an announcement for Satoshi's coins, but without the actual spending transa= ction, nobody can tell whether the announcement is valid.

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

Best,<= br />Boris

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

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

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

So= the scheme is:

After activation at b= lock 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_RETURN
3. **Reveal** full transaction with pro= of of prior commitment but not as a normal transaction yet
4. **C= ounter Reveal**: For 144 blocks, others can reveal older commitments. This = protects exposed pubkeys!
5. **After 144 blocks**: The UTXO can be spe= nt according to the strongest announcement (oldest commitment of valid tran= saction wins).

As (5) is just the normal transac= tion, the scheme is a soft fork and compatible with pre-recorded transactio= ns where the keys were lost. It would at least double the on-chain costs fo= r these vulnerable UTXOs as they would have to store the full transaction t= wice. We can make the announcements prunable again though.
=
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 size of a weak= announcement (strong announcements can already be small: just a txid or a = Merkle root of many txids).

Importantly, we cann= ot include the whole signed transaction in the weak announcement. Doing so = would leak the EC public key immediately, allowing an attacker to create th= eir own valid weak announcement. We must avoid revealing the public key unt= il the actual spending transaction is broadcast.

We n= eed a scheme where the EC public key is not leaked in a weak announcement, = but the legitimate owner can verify it, while no one else can. Also, once t= he EC public key is revealed, anyone should be able to verify a past weak a= nnouncement (to validate the transaction when it is broadcast). This reduce= s to the following requirement: we need a proof of knowledge of the EC publ= ic key that can be verified if the public key is known and provides no info= rmation otherwise.

I think this is called a zero-knowledge proof= . One simple approach could be to apply a tagged hash function to the conca= tenation of the EC public key and the future wTXID, and include this in the= weak announcement. The structure would be:
  • =C2=A0 =C2=A0 UTXO= (previous TXID and output index)
  • =C2=A0 =C2=A0 future spending wTX= ID
  • =C2=A0 =C2=A0 proof :=3D tagged_hash(EC public key || wTXID)
The wTXID is included in the concatenation to bind the proof to a par= ticular future transaction. Otherwise, someone could copy a weak announceme= nt and substitute their own wTXID.

Satoshi could publish a stron= g announcement now and then monitor all weak announcements involving his UT= XOs. If someone publishes a weak announcement for one of his coins, he coul= d verify the "proof" field. If it is valid, it would mean someone has crack= ed his key with a quantum computer, and he would need to use his strong ann= ouncement immediately to reclaim the funds before the attacker does.
<= br />Best,
Boris

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

the announceme= nts, weak and strong would have to not be transactions yet to be compatible= with legacy nodes and thus keep it a soft-fork. They could be OP_RETURN da= ta. Only after the 144 blocks, the upgraded full nodes would allow the incl= usion of the actual transaction. This would mean the transaction would be b= oth in full in the OP_RETURN strong announcement and without the witness pa= rt later, so it would be a bit expensive this way but maybe we can do bette= r?

A node that gets updated would have to re-ind= ex all the blockchain to find announcements if we don't introduce a time fr= ame for actually using the announcements. We could also say that any announ= cement has to be used within another 1000 blocks. Then the upgrading node w= ould have to re-index the last 1000 blocks.

The = legitimate owner of a UTXO might wait for an attack for privacy reasons. My= proposal would allow Satoshi himself to make all his UTXOs quantum safe wi= thout any of us learning about him being active. He could add one 64B OP_RE= TURN in 2027 and when QC becomes an issue, we would learn about him having = been active in 2027 in 2040 when actually somebody tried to attack and not = in 2027 when people started to panic because of imminent quantum breakthrou= ghs.
Hmm ... a problem is the weak announcement doesn't require k= eys, so anybody could provoke Satoshi to come forward. Maybe we have to add= key ownership as a requirement for the "weak" announcement, too. So it sho= uld also contain a serialized transaction.

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 UTX= O set?
I assume it must be a transaction, correct? And it should somehow mar= k
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: woul= d
they have to reprocess all blocks since the fork to find and index al= l
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 someone
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 commit= ment must be to the complete transaction including witness data (wTXID or e= quivalent) to prevent an attacker from pre-committing to unsigned transacti= ons. This is essential - otherwise an attacker could indeed enumerate the U= TXO set and create commitments without knowing the private keys.
>
> Regarding updates: You're correct that frequent updates would be= needed as wallets receive new UTXOs. However, I don't see this as a major = issue - users could batch their commitments periodically (say, monthly) rat= her than after every transaction. The scheme is particularly important for = existing UTXOs that already have exposed pubkeys (old P2PK, reused addresse= s, etc.). For new UTXOs, wallets should ideally migrate to quantum-safe add= resses once available. OpenTimestamps aggregation would indeed help with sc= aling and provide plausible deniability about the number of UTXOs being pro= tected.
>
> The time delay serves a different purpose than you might expect.= It's not about preventing commitment forgery after pubkey exposure, but ra= ther about allowing priority based on commitment age when multiple parties = claim the same UTXO:
>
> 1. Weak announcement starts the 144-block window
> 2. During this window, anyone with a strong commitment can revea= l 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 older commit= ment, they can reclaim it during the window. The uncertainty about which UT= XOs have poison pills makes attacking large "lost" UTXOs risky - hence less= disruptive to the network.
>
> The delay essentially allows a "commitment priority contest" whe= re age determines the winner, protecting users who prepared early while sti= ll allowing these users to not move their funds.
>
> Best,
>
> Leo
>
> --
> You received this message because you are subscribed to the Goog= le 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 https://groups.google.com/d/msgid/b= itcoindev/5e393f57-ac87-40fd-93ef-e1006accdb55n%40googlegroups.com.



--=20
Best regards,
Boris Nagaev

--
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/2ed6d831-d87d-44f0-82b9-c8b9abaa8010n%40googlegroups.com.
------=_Part_116061_1164823195.1749135265323-- ------=_Part_116060_1784724860.1749135265323--