From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 04 Jun 2025 10:41:00 -0700 Received: from mail-yb1-f192.google.com ([209.85.219.192]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uMs6k-0007QR-PH for bitcoindev@gnusha.org; Wed, 04 Jun 2025 10:40:59 -0700 Received: by mail-yb1-f192.google.com with SMTP id 3f1490d57ef6-e7d961b8930sf242140276.1 for ; Wed, 04 Jun 2025 10:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749058853; x=1749663653; 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=5sQTHwKJc0qn+UWbQnVD3WHy9CaYnp85iDuWL0W0RTc=; b=JsQYLZ8VJep9nQeOZib+OQmCh4ryRSVOHUhq/BUvUN3sbKC5yxmfypiFoTTbe2oUGt pbR8F1qOoj9CMjeUGXvtU7lSs5L8AB4Zifq0H+6gVnQvvlqK5U57p/iXNA3uqoZ8PlUd 0xXYD/2NsCoSb+XB4/GyGuqf46a9PudJTbp7K2UXWFiJ1/SnlTx4QjozR0/Cerau6T3y HLi+nQim3kMP3/qBcwAsqkLFX0amyWN/ues2sr2a7SM7S+AlwepugdS5QoT5McXc7uPH tTn37dcwdlw0iifRkyghPIn09V0kXeM6bHvMX0JUSYSq3XFFRFYVEP6v1Syei5nO9f5h CANA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749058853; x=1749663653; 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=5sQTHwKJc0qn+UWbQnVD3WHy9CaYnp85iDuWL0W0RTc=; b=hNmwdhF7i7sCQnh1JbL+XJ6np8UZmzegxGzXVhkxmfP7wzYCb2U358wXODOCb0YVi2 dVpZZnR0wNrizixYSOLQ+M4wF5Jrt8nmDVTTrAogdFiTXbEMtD3a6dvW+CIIgR0+ZlCA nB3lDKbKOFb/ZQ9MFYbU9E/si54H3idSAcJ1Z0R6UiMx94glkCkTPgvQqFub2Lt/KDWv T9aJLO2Tvdik19BBCn4SCbcg7rhCsp1pv21ah97bcSv21G3KuyjsljkECg4kA/bfb+AI ale8xflCVKKCGIAjSIv0znrsjclGHCdv58qs8x1IIeM3CARNFRReUlW5QEVO6H7FyVLW NLYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749058853; x=1749663653; 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=5sQTHwKJc0qn+UWbQnVD3WHy9CaYnp85iDuWL0W0RTc=; b=cDpvZPv45GCeR9ScseLO3PQlU9N4ZMRwOetWdiX6ijOMjZ/ydkhdgi/89VKpARPRe2 ink2uQMhzs0U8ybZOBkidUuUSpJQ+XecaCQ0+dUGTH0gCIl5Wa4Sia1fIQv7hMTe2fex q8WeBs6ss1fBEqDvvk6fuFwITNv/wR4/L5RwLgeJCpSIAfXVYLsiaa9J7vMjfiITIIcv Ur3RMebIOL7d8crJw3Mqnf7CAmSMg5sw25zXo8Oa4I97+18zn1KoO/r/psrhQOmVf4db 23W13omIzv6kHS/rUt+66VXHqqJsTspU+UCdPDt1Soye6BSREUYgZHEYD2yOJKEFtro/ aMFg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVDtL11AfYbcNH0WGsSzxM7vei6yr7VE0PFshjs1CT8ChfwlMMMfOioBoo9LdWh5CpoFR3WuE0SWpb/@gnusha.org X-Gm-Message-State: AOJu0YxGI2m63GZGmueVy6tfiZQskaH9K7TqmBQ6Dzm8l4E/wx1/HDhR nnZGble6wcS3huqtU14BscWe8KpwiS8gPs7UhU8ULR3NRJVXnForiYr8 X-Google-Smtp-Source: AGHT+IFO+MpryWazwAoVbhknhWs6wzdQeAKgDaoChtjX7/pV8ZFVwniaY4KjfIkjqTYFRAmmxNLw5g== X-Received: by 2002:a05:6902:2b91:b0:e81:4a97:b8dc with SMTP id 3f1490d57ef6-e8179da3539mr4975919276.48.1749058853036; Wed, 04 Jun 2025 10:40:53 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcketC3ziYZTBKrcWUFt9IfwSAk6K1UbuI/0L+i05bXiw== Received: by 2002:a25:b327:0:b0:e7d:cffc:6cc with SMTP id 3f1490d57ef6-e8188a154d7ls35666276.2.-pod-prod-06-us; Wed, 04 Jun 2025 10:40:49 -0700 (PDT) X-Received: by 2002:a05:690c:6502:b0:70e:1874:b914 with SMTP id 00721157ae682-710d9dbabd1mr47917157b3.9.1749058849380; Wed, 04 Jun 2025 10:40:49 -0700 (PDT) Received: by 2002:a0d:d201:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-710d6e595f0ms7b3; Wed, 4 Jun 2025 10:39:39 -0700 (PDT) X-Received: by 2002:a05:690c:25ca:b0:702:d85:5347 with SMTP id 00721157ae682-710da01a419mr51847067b3.36.1749058778658; Wed, 04 Jun 2025 10:39:38 -0700 (PDT) Date: Wed, 4 Jun 2025 10:39:38 -0700 (PDT) From: Leo Wandersleb To: Bitcoin Development Mailing List Message-Id: <5d9f6ac9-a623-4636-8a91-ee7c057bc08an@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> Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_96792_2021222509.1749058778207" 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_96792_2021222509.1749058778207 Content-Type: multipart/alternative; boundary="----=_Part_96793_1100570934.1749058778207" ------=_Part_96793_1100570934.1749058778207 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, > > 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 se= t? > 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 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 wrote: > > > > Hi conduition, > > > > Thanks for your careful analysis - excellent catches. > > > > 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. > > > > 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 protect= ed. > > > > 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: > > > > 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 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. > > > > 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. > > > > Best, > > > > Leo > > > > -- > > 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/5e393f57-ac87-40fd-93ef-e100= 6accdb55n%40googlegroups.com > . > > > > --=20 > Best regards, > Boris Nagaev > --=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/= 5d9f6ac9-a623-4636-8a91-ee7c057bc08an%40googlegroups.com. ------=_Part_96793_1100570934.1749058778207 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Boris,

the announcements, weak and strong would hav= e to not be transactions yet to be compatible with legacy nodes and thus ke= ep it a soft-fork. They could be OP_RETURN data. Only after the 144 blocks,= the upgraded full nodes would allow the inclusion of the actual transactio= n. This would mean the transaction would be both in full in the OP_RETURN s= trong announcement and without the witness part later, 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 ann= ouncements. We could also say that any announcement has to be used within a= nother 1000 blocks. Then the upgrading node would have to re-index the last= 1000 blocks.

The legitimate owner of a UTXO mig= ht wait for an attack for privacy reasons. My proposal 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 becom= es an issue, we would learn about him having been active in 2027 in 2040 wh= en actually somebody tried to attack and not in 2027 when people started to= panic because of imminent quantum breakthroughs.
Hmm ... a probl= em is the weak announcement doesn't require keys, so anybody could provoke = Satoshi to come forward. Maybe we have to add key ownership as a requiremen= t for the "weak" announcement, too. So it should also contain a serialized = transaction.

Best,

<= div>Leo

On Wednesday, 4 June 2025 at 04:15:59 UTC+2 Nagaev Bor= is 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

--
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/5d9f6ac9-a623-4636-8a91-ee7c057bc08an%40googlegroups.com.
------=_Part_96793_1100570934.1749058778207-- ------=_Part_96792_2021222509.1749058778207--