From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 05 Jun 2025 05:55:42 -0700 Received: from mail-yb1-f184.google.com ([209.85.219.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uNA8C-0005Ci-GU for bitcoindev@gnusha.org; Thu, 05 Jun 2025 05:55:42 -0700 Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e812e1573ecsf1044103276.2 for ; Thu, 05 Jun 2025 05:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1749128134; x=1749732934; 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=zQ0OUEg42PWGpLT/ndFPGYOmUcjWeSuDXLIkv96KjGE=; b=pFkZ8EjrKehO8O42t25R6cidKEW02wiO9AZV6Q8wz9FM8dwUDf3hONCscGVQW7rNkk gkkvDPoECaTKdbKdYyCINowVgHkQFQa3DL1pGY32N+7dzS5K4D5ifHl0LN4751ZSqgYI PMeNPSI7Py7S1ChsfRERukUsGN6nPsnoVxrbXIR0po8VluTF7CBJrNTs760s0YvLcabn t0ejXPHlV9Ep6V86WU8P58rX/OlhuezCtXjPoF9M/jfRgm5BEAD0PhkDNMDy2AI02vfL VQWzO0nDzDlHcGKkGKO11c1f2oDamCnpltt5aEZfMfVLp+M8zVUjz5/Ra6IlDjBp5QNd xg6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749128134; x=1749732934; 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=zQ0OUEg42PWGpLT/ndFPGYOmUcjWeSuDXLIkv96KjGE=; b=h74moNW+8mEY17oC1wUZhX/+R2Q2QPzKIdM0Zkny/zoOcC5BmYPWatU+hbIBcPpf2C eXu0qsYKMfF9bgKdtBu/mXReOs2jhfsY1DWlQAH2prUJgORd54+qLP7J0ZwpmxT+P2zQ RV7QsjWTcapEGExrTCXUEvmOnCV2I3Qv+ZWA29r6m+iMOu1Qjx5S1DSuqFO/VC/qHH3r s6ZXfc1ewGi0+HEapaYf6uvMQMDWhD3KdYWPOGWxNL17ty7JT+eOVWoM3m6uXN7YOg0h wWGdlBUr/Sh7ESrf/oESKNK00/zfU2W1+s0ERXnzHRnGaByfc3WRmBQZXLNvrpNm7o5j 1vAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749128134; x=1749732934; 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=zQ0OUEg42PWGpLT/ndFPGYOmUcjWeSuDXLIkv96KjGE=; b=SaTywWz7FgDi6oY9rMNOmk74wz/XUiPMBPFAtapAfaZFG7QKz4w4Li6CTfG7iGAB6r wzMfMod3AcHRPg05n6srajMhsd/iEagMIcWR8Y45kkPRcYQVhZVxBGebjgOWECGmwIgc B0hC8abr9f8UyMxqe7z2iBMbAqr/0riTfAiM7hZicwcvHmvq/mrzzz1KFASKux+aKxzm 00iWQ8gqYpazSyfJl0gbSC44CzYUTnG0Tl9Ywg8a55anoIq1rdc6CY7QN+Mgh6O9IC+l qcAO530GDAqYesRF7Vdq32wEpfm2TKVn/HMR/b+eP0PpmL2deGMl7SztGaIVAS+ImJHI 47xA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUD/JROPE5OC7qohY7eDW+dzghSxrRkif7l6KoLGZitjm9UY2ZuGWG3JQBWNITdVKnPK4+04L+vtZCx@gnusha.org X-Gm-Message-State: AOJu0YwX2Yh4P6JlBC9X/cLp2g9nBfDn9NV0waPyRsbkBz6Sctndc+AS UfovugF+eCCPlTkgIXOTcgg45tCsEcdqWbBWmXumbWEQMVPtnhIkd4iY X-Google-Smtp-Source: AGHT+IFHCqNqHUi198ud1/QlGt1uO+wxYYR6GicJcsgfOJGDHyx4uFfvAvbrPbSR5U4ciuB4onkniw== X-Received: by 2002:a05:6902:2193:b0:e81:2d89:4e with SMTP id 3f1490d57ef6-e817b3f1eb3mr8137199276.28.1749128134547; Thu, 05 Jun 2025 05:55:34 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZd7pyi2UCmI+VLZglT+lemTLdtenlN17aoItcTvJVpOIg== Received: by 2002:a25:d3c5:0:b0:e76:1290:e47f with SMTP id 3f1490d57ef6-e81889738d6ls989942276.2.-pod-prod-07-us; Thu, 05 Jun 2025 05:55:31 -0700 (PDT) X-Received: by 2002:a05:690c:74c4:b0:709:176d:2b5 with SMTP id 00721157ae682-710d9a1f3femr96428457b3.2.1749128130987; Thu, 05 Jun 2025 05:55:30 -0700 (PDT) Received: by 2002:a0d:d201:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-710d6e595f0ms7b3; Thu, 5 Jun 2025 01:18:28 -0700 (PDT) X-Received: by 2002:a05:690c:3381:b0:70f:83ef:de07 with SMTP id 00721157ae682-710d9e7b590mr81315157b3.33.1749111507229; Thu, 05 Jun 2025 01:18:27 -0700 (PDT) Date: Thu, 5 Jun 2025 01:18:26 -0700 (PDT) From: Leo Wandersleb To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <44b5aa4c-a71b-49ed-beee-071140b16aacn@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> Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_72546_464363642.1749111506764" 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_72546_464363642.1749111506764 Content-Type: multipart/alternative; boundary="----=_Part_72547_955101479.1749111506764" ------=_Part_72547_955101479.1749111506764 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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/= ea71bbd5-1325-445b-977f-a52b8017eab4n%40googlegroups.com. ------=_Part_72547_955101479.1749111506764 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 shou= ld still hold as they have less urgency. If the attacker sees the transacti= on in a strong announcement with a full transaction, he cannot win even if = he gets into a block first, as the strong announcement proves a prior commi= tment to that transaction and would win even if it gets mined only some blo= cks later.

A scheme where the announcement does = not contain the full transaction is problematic as the transaction might th= en turn out to not be valid. Then 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 announc= ement=C2=A0
2. **Commitment** to a wTXID that spends the vulnerable UT= XO. Multiple 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 norma= l transaction yet
4. **Counter Reveal**: For 144 blocks, others c= an reveal older commitments. This protects exposed pubkeys!
5. **After= 144 blocks**: The UTXO can be spent according to the strongest announcemen= t (oldest commitment of valid transaction wins).

As (5) is just the normal transaction, the scheme is a soft fork and compa= tible with pre-recorded transactions where the keys were lost. It would at = least double the on-chain costs for these vulnerable UTXOs as they would ha= ve to store the full transaction twice. We can make the announcements pruna= ble 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 s= ize of a weak announcement (strong announcements can already be small: just= a txid or a Merkle root of many txids).

Importantly= , we cannot include the whole signed transaction in 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 publi= c key until the actual spending transaction is broadcast.

We need a scheme where the EC public key is not leaked in a weak announc= ement, 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 verify a past= weak announcement (to validate the transaction when it is broadcast). This= reduces to the following requirement: we need a proof of knowledge 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-knowledge pr= oof. One simple approach could be to apply a tagged hash function to the co= ncatenation of the EC public key and the future wTXID, and include this in = the weak announcement. The structure would be:
  • =C2=A0 =C2=A0 UTX= O (previous TXID and output index)
  • =C2=A0 =C2=A0 future spending wT= XID
  • =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 pa= rticular future transaction. Otherwise, someone could copy a weak announcem= ent and substitute their own wTXID.

Satoshi could publish a strong a= nnouncement now and then monitor all weak announcements involving his UTXOs= . If someone publishes a weak announcement for one of his coins, he could v= erify the "proof" field. If it is valid, it would mean someone ha= s cracked his key with a quantum computer, and he would need to use his str= ong announcement immediately to reclaim the funds 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 s= trong would have to not be transactions yet to be compatible with legacy no= des and thus keep 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 ac= tual transaction. This would mean the transaction would be both in full in = the OP_RETURN strong 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 blockc= hain to find announcements if we don't introduce a time frame for actua= lly using the announcements. We could also say that any announcement has to= be used within another 1000 blocks. Then the upgrading node would have to = re-index the last 1000 blocks.

The legitimate owne= r of a UTXO might 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 an= d 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 pe= ople started to panic because of imminent quantum breakthroughs.
= Hmm ... a problem is the weak announcement doesn't require keys, so any= body could provoke Satoshi to come forward. Maybe we have to add key owners= hip as a requirement for the "weak" announcement, too. So it shou= ld also contain a serialized transaction.

Best= ,

Leo

O= n 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

--
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/ea71bbd5-1325-445b-977f-a52b8017eab4n%40googlegroups.com.
------=_Part_72547_955101479.1749111506764-- ------=_Part_72546_464363642.1749111506764--