From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 03 Jun 2025 01:01:09 -0700 Received: from mail-oi1-f191.google.com ([209.85.167.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uMMa3-0008GN-LL for bitcoindev@gnusha.org; Tue, 03 Jun 2025 01:01:08 -0700 Received: by mail-oi1-f191.google.com with SMTP id 5614622812f47-407ac0a3bdbsf2034138b6e.3 for ; Tue, 03 Jun 2025 01:01:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1748937661; cv=pass; d=google.com; s=arc-20240605; b=hDjx7eoyu6bLxEHBD5Fi1ghoTDE+YTRPUz7ytlH7jqXgJiTxIe1EJ9j8TS9Moo3JUx JWx9wjezqmQJ9npKNkKqoie/MvkSBy5Z8aGZ0Z4b98kTDNQPHD87NDDJ5rS+e+665FCU EpAzXa64H9CdqtA6WBSQfYKCCX1FVeKIHIVGvx3AbxlSCjcotqDBAgUaLVBw1nUZE0/v LnpzgcPJdi3pujd847OW+B3ieVEwsRFkbBr3i4VYFj8AQ92pLD9uMlvQjJPsKAIf5eyL U0sPnP0E6ucvvFjddtwUeBchNl3HnO5E1rODyrbeyYk07FbtY2p/4qTwevK8gJubUWXq bGpg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=U88vxZ0PNgczCOtbrbp5wgcxKYkBRxk9DCqRwbkuWoM=; fh=3ub2m5orKVPc1cWaEjBkXL5ozHWvzStoEoxp5RbPI1s=; b=Iu5ahWn3MmwHrj0ipJ3oHrvb3AZwdw8yQq+jP+1w27RFQQR+G2W8xtD4K6rNmQw+HI nLS+CIwD6xKosPmxXoHmv0hgNIBfB3QCXzv49Ih0K89RsYOPGT84SdObE+fCaJvVpwuy tmzWZTr+8Z1gc/DMvS2dl3Iw5Ffr4/zrT7btmg8742NAiDj/uRcpsdro9tyMrib6l+Mn ucHHK16TWb9FbZ/fSdDwuRBchEm9WaSwHUOK5X0p7Xtw/OuC+ksRIPCdse/OTaV6DyV6 vNKYMyFoqOZs6X5FJTNTdc/pyzmggRXQOpU48KVt+QP5xRx6VmysTcDxyrqQP5k8v7Ym hEKg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=gVOtXOE4; spf=pass (google.com: domain of lwandersleb@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=lwandersleb@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1748937661; x=1749542461; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=U88vxZ0PNgczCOtbrbp5wgcxKYkBRxk9DCqRwbkuWoM=; b=PpwXAysDlr8i1r+pK4oKzR9ctGIkuSnXei3UfHQUiS0uHsucANNlK9u/MFpNq+ZODn Sv2zYou/cOgG+WIF0F8PBhlEQfI6tCP25hZuzEAGS3dFN0QFA4qpqqqBUbnHcD7BGVZW KQDFXJbr19fmuGIpiPDAyY9DDjKUx79mmld/d1m1SlpMIDL5SneNdnE5we2akL90xxHf 8FDl4oAIZLoxosWXKq4CShov2nu9sWMwyAE2gckvfSKK/QKPrORTIgJUpFFYVnAjq1hU VvTa1ccC9SO3ZCVL+zElcSwrIKKLzIXQqvisd9QhFgnJjs/R08B2F1wpCovwpi5DrH9V kikg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748937661; x=1749542461; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=U88vxZ0PNgczCOtbrbp5wgcxKYkBRxk9DCqRwbkuWoM=; b=C9IHR/OMPn2ncZL39bFq2CypvyQY3gFhlCUx+4U8Mgwpr4BRXOr8ZCsBHjSB67gBPV 0vr0eYVDLbWmMKuqdn1vKTDKOt6wAmisZoNZ4ZOUoELF/MlYii2NiijTY5vlHLrl1ve2 smSiGoZmaipMghhEt78m9gqvaJe5ED3JkHFq5Ho63Lu8Q9w9HKY8xIIShC+8INWIcOpr LVGd3N0BuyxP79pHx+jEXMRvWYDCo/LgkkPETbZa+BAVxmz9eLOQuLlKJBvex28SmBrI 7XHFtlNLIXdgLuhoXGjLW85YbBb5FQZwJqO1hkKrRoY6m8cVMVICEtaaByDse4nX8sYD bTOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748937661; x=1749542461; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=U88vxZ0PNgczCOtbrbp5wgcxKYkBRxk9DCqRwbkuWoM=; b=eYXAdrVz6/xxY6SFei5eRK6fbHdFvjWDFv9yHMfeunJamQFdjNnd0rsW8nrE9q4Zqs 9LY0tDA5EwVXu81AIVVRZDGx1gafsfgEL6gXtPyeGQKIqceyuLMiAFbI3WYzFiXHUpkr PvankuP+lsyQZIj/WyS2IeNuaKc7WixJv4U6Prt46mJPAkoGI/s6a0GxTG3XZ6x/KmkI EAQ9Z8LqE/KYa2l/nfsKQ/ifSqbP5G286dcsraf/JVYwEsADJysnNTxSe/ji8sp5iXEV udH/aZ4YWxs9IEIaqVaFgM5ADXieHGjiMVrpMqI+lUS7LHNALW9u6O+wv89yCGkJpUZ9 mJuw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUGgN6NPZ44pWVWq1UwWeu9EOlAOijldFlpiagk9IREMXYGCBhugQTCn7e/C33khAjfxiL590HTkR7m@gnusha.org X-Gm-Message-State: AOJu0YyftytTPSLjJzj4/H/rGIhceuSr3CP4huI5SC0lVIP4lT8hO5ot IsA41a8ic0diDnbR7aI+eGTra9hRTiRHaK++D1qgG2B+Ly0pZDdkKWcy X-Google-Smtp-Source: AGHT+IHUGyjutXBudJ5eZriX3i6Nu0z4uH1vktgCUsqoA+7aDK+PpccHi+xJweaWUAzeBH2jvi/gGg== X-Received: by 2002:a05:6808:3206:b0:406:59f3:7392 with SMTP id 5614622812f47-40679636713mr8146869b6e.12.1748937661392; Tue, 03 Jun 2025 01:01:01 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcQ3PYs6bkYgMUrRfQczH7Gm1VEzO7UuGU/uVJz8wAJzw== Received: by 2002:a4a:b20d:0:b0:60b:e31f:50c9 with SMTP id 006d021491bc7-60be5489c81ls1796125eaf.1.-pod-prod-03-us; Tue, 03 Jun 2025 01:00:58 -0700 (PDT) X-Received: by 2002:a05:6808:6f89:b0:408:ed52:c62f with SMTP id 5614622812f47-408ed52c6f5mr48366b6e.2.1748937658108; Tue, 03 Jun 2025 01:00:58 -0700 (PDT) Received: by 2002:a05:6402:31b5:b0:604:a019:6e81 with SMTP id 4fb4d7f45d1cf-6056d45fc8emsa12; Mon, 2 Jun 2025 21:19:31 -0700 (PDT) X-Received: by 2002:a05:6402:350e:b0:601:bcc5:a50 with SMTP id 4fb4d7f45d1cf-6056dd35774mr14815710a12.8.1748924369043; Mon, 02 Jun 2025 21:19:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1748924369; cv=none; d=google.com; s=arc-20240605; b=EJ+D43lgPFk3AooyS9eZL6UwHwA2XAIbccvcmlBAhmhVkOR7OD95N4JxCaxKKpoMAy QhmdP/FIGLRW78OMzqVYOASVO7T2vHeUQciOfSnnPE2qdsFaBPW1ukcedoqAUr+LIqNS Z8NOwX279IFvHExCfkkn30yn4EVrCvKthkAHnl7y0qju+vKLtbaf7vKnTFgFoGC20a4a CH5hmfLqyOiwgaisUEaxqgJYxv1eJUXcyPadTtrbouz4zhXTd8+8l6Xbc6pr99yXDaoW aR7Iw7ot8rHfSRmMpg76p4axZez8oTt8ufIY79gEu5wi/VxsaNrgU/X+MXmNeVLADZ5D bzTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=3h44jcBi5fY2eKlV70grKHpDhkIPO9bcFW2oqnz5gVg=; fh=HPA68ncp94B6BejhD2JPlI/1BWvELD7xBdD10WX68Vw=; b=XFDZsGaeIvaHpQA42QGkrzft71ulc/+UY4nTHb72Vp9iAfnViTmDisCsA/02ew0Fxt dAjNTMO5lHqudDRYbnZQNEa7fL+espr7iDP2l3bAvCGgR/0gP84MndbeTgHSsmVDJaBx /NTWiZoF2kMSr26gY1b9n7VOQX+gITjyDKTVw46dWOjm3tXktQUxmRKcXNs4VoBHfdCI kcrDVnGSJlmgisabkEJjPw39wekKPrWA8ghhBX9z06te5OEkImoG0ukYTUzd81oNt6v3 ZVZG6QId/nM/QtXJPYsqA5TTx3L1QaixnWruq16HaopiqSYZuVbfAkNQqskQNmYC2Xg0 o0rA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=gVOtXOE4; spf=pass (google.com: domain of lwandersleb@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=lwandersleb@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com. [2a00:1450:4864:20::132]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-605c0d9e70esi240013a12.4.2025.06.02.21.19.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 21:19:29 -0700 (PDT) Received-SPF: pass (google.com: domain of lwandersleb@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) client-ip=2a00:1450:4864:20::132; Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-54afb5fcebaso6586857e87.3 for ; Mon, 02 Jun 2025 21:19:29 -0700 (PDT) X-Gm-Gg: ASbGnct3VbAW/gP9tUf3ZgUMBcZxuLybNn8D65z0MJU26AdoHRF36BUzNbFg/9Tdp0J EUsaxo/tuCe+o7rd6tLX59ygOkEIk2NczjA0+qiDJ0E7s1e6g+Sdu2LGWrTC9s78AWku5YyUyeO gvXL6ICIQTKQUpVL1E85Brub+eTjmPC/Cd+4wntL7RzfxBij44T/rzHNWV/aOpX4+6Phw= X-Received: by 2002:a05:6512:1318:b0:553:3332:b652 with SMTP id 2adb3069b0e04-5533b8fcdf3mr4428600e87.23.1748924367920; Mon, 02 Jun 2025 21:19:27 -0700 (PDT) MIME-Version: 1.0 References: <2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a@gmail.com> In-Reply-To: From: Leo Wandersleb Date: Tue, 3 Jun 2025 06:19:16 +0200 X-Gm-Features: AX0GCFvQNCdjCC78n2ohrOvzjVyHhwF2AuVcwVBe9-jO4Lnj35bpNtCa3R8xd5g Message-ID: Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill) To: Nagaev Boris Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000b066e30636a32f5c" X-Original-Sender: LWandersleb@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=gVOtXOE4; spf=pass (google.com: domain of lwandersleb@gmail.com designates 2a00:1450:4864:20::132 as permitted sender) smtp.mailfrom=lwandersleb@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --000000000000b066e30636a32f5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nagaev, yes, you are right. The poison pill variant would be a hard fork and ultimately require post quantum address types but it would allow to prepare for it even now as you could at the cost of one hash protect all exposed public keys.against slower brute force attacks as in Tadge's proposal. With QC further advancement to quick and cheap attacks, Tadge's soft fork could work with these commitments even protecting now exposed public keys if the soft fork would require the commitments for those to be old - pre soft fork for example. But those worried more about confiscations than about a massively disruptive quantum gold rush might prefer the hard fork poison pill variant as it would allow protecting exposed keys somewhat. On Tue, 3 Jun 2025, 01:12 Nagaev Boris, wrote: > Hi Leo, > > Thanks for sharing your proposal, a very interesting approach! I have > a few questions and comments: > > > Users create and sign transactions moving their funds to quantum-safe > addresses > > 1. **No consensus changes needed now** - Users can start protecting > themselves > > immediately > > How would users prepare transactions moving funds to quantum-safe > addresses now, before such address types exist? We would need to know > the structure of a quantum-safe address to create the transaction. > Either an existing address type would need to support some form of > quantum protection already (e.g., WOTS implemented via BitVM), or we > would still need a softfork to introduce a new address type. > > Additionally, a future softfork (or possibly a hardfork, see below) > would still be required to enforce the new spending rules. > > > - If attacked, the victim can reveal the commitment to execute the > recovery > > transaction > > Wouldn't such a recovery transaction require a hardfork? As far as I > understand, it wouldn't be valid under current consensus rules. > Enabling it would require relaxing existing rules, which would imply a > hardfork. > > Best, > Boris > > On Mon, Jun 2, 2025 at 6:12=E2=80=AFPM Leo Wandersleb > wrote: > > > > Hi all, > > > > I'd like to propose a variant of the commit/reveal schemes being > discussed for > > quantum resistance, but with a different goal and timeline. This builds > on ideas > > from the recent thread "Post-Quantum commit / reveal Fawkescoin variant > as a > > soft fork" but targets a different use case. > > > > ## The Problem > > > > Current discussions focus on emergency reactive measures - what to do > *after* > > quantum computers arrive. But this leaves users in a difficult position= : > > > > 1. They can't prove ownership of their coins without revealing pubkeys > (and thus > > becoming vulnerable) > > 2. Moving coins to quantum-safe addresses early reveals which addresses > are > > active vs. abandoned > > 3. There's no way to prepare for migration without exposing yourself > > > > ## Pre-emptive Commit/Reveal > > > > What if users could commit *today* to future migration transactions, > without > > revealing which UTXOs they control? > > > > The idea is simple: > > - Users create and sign transactions moving their funds to quantum-safe > addresses > > - They compute a Merkle tree of all these transactions > > - They publish only the root hash (e.g., in an OP_RETURN) > > - This can be done today, with no consensus changes > > > > If/when quantum computers become a threat: > > - We soft fork to require at least n confirmations on quantum vulnerabl= e > > transactions > > - Transactions work as always but can't be spent for n blocks > > - If attacked, the victim can reveal the commitment to execute the > recovery > > transaction > > > > ## Key Advantages > > > > 1. **No consensus changes needed now** - Users can start protecting > themselves > > immediately > > 2. **Privacy preserved** - The commitment reveals nothing about which > UTXOs you own > > 3. **Efficient** - One hash can commit to migrations for all your UTXOs > or even > > the UTXOs of several users > > 4. **Flexible** - Works whether or not a quantum computer ever actually > appears > > > > ## Differences from Tadge's Proposal > > > > While Tadge's proposal solves post-quantum spending where any pubkey > reveal is > > dangerous, this proposal is about preparation: > > > > - **Timing**: Pre-quantum (can start now) vs. post-quantum (activates > after QC > > appears) > > - **Scope**: Migration to quantum-safe addresses for all address types > in the > > worst case vs. general spending of hashed pubkeys > > > > Both use the same cryptographic primitive (commit/reveal) but for > different > > phases of the quantum transition. > > > > This approach lets users protect their funds without waiting for > consensus > > changes or revealing their holdings. It's a "poison pill" against quant= um > > attackers - they might steal coins, but pre-committed owners can reclai= m > them. > > > > Would love to hear thoughts on this approach. > > > > Leo Wandersleb > > > > -- > > 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+unsubscribe@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/2c3b7e1c-95dd-4773-a88f-f2cd= b37acf4a%40gmail.com > . > > > > -- > 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/= CA%2B_eyec5LLsAMrVuzGFOKRd1-1Msf8Bc0Aew%3Df02%3DpJi19FLNw%40mail.gmail.com. --000000000000b066e30636a32f5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nagaev,

y= es, you are right. The poison pill variant would be a hard fork and ultimat= ely require post quantum address types but it would allow to prepare for it= even now as you could at the cost of one hash protect all exposed public k= eys.against slower brute force attacks as in Tadge's proposal.

With QC further advancement to q= uick and cheap attacks, Tadge's soft fork could work with these commitm= ents even protecting now exposed public keys if the soft fork would require= the commitments for those to be old - pre soft fork for example. But those= worried more about confiscations than about a massively disruptive quantum= gold rush might prefer the hard fork poison pill variant as it would allow= protecting exposed keys somewhat.

On Tue, 3 Jun= 2025, 01:12 Nagaev Boris, <bnagaev= @gmail.com> wrote:
Hi Leo,<= br>
Thanks for sharing your proposal, a very interesting approach! I have
a few questions and comments:

> Users create and sign transactions moving their funds to quantum-safe = addresses
> 1. **No consensus changes needed now** - Users can start protecting th= emselves
> immediately

How would users prepare transactions moving funds to quantum-safe
addresses now, before such address types exist? We would need to know
the structure of a quantum-safe address to create the transaction.
Either an existing address type would need to support some form of
quantum protection already (e.g., WOTS implemented via BitVM), or we
would still need a softfork to introduce a new address type.

Additionally, a future softfork (or possibly a hardfork, see below)
would still be required to enforce the new spending rules.

> - If attacked, the victim can reveal the commitment to execute the rec= overy
> transaction

Wouldn't such a recovery transaction require a hardfork? As far as I understand, it wouldn't be valid under current consensus rules.
Enabling it would require relaxing existing rules, which would imply a
hardfork.

Best,
Boris

On Mon, Jun 2, 2025 at 6:12=E2=80=AFPM Leo Wandersleb <lwandersleb@gm= ail.com> wrote:
>
> Hi all,
>
> I'd like to propose a variant of the commit/reveal schemes being d= iscussed for
> quantum resistance, but with a different goal and timeline. This build= s on ideas
> from the recent thread "Post-Quantum commit / reveal Fawkescoin v= ariant as a
> soft fork" but targets a different use case.
>
> ## The Problem
>
> Current discussions focus on emergency reactive measures - what to do = *after*
> quantum computers arrive. But this leaves users in a difficult positio= n:
>
> 1. They can't prove ownership of their coins without revealing pub= keys (and thus
> becoming vulnerable)
> 2. Moving coins to quantum-safe addresses early reveals which addresse= s are
> active vs. abandoned
> 3. There's no way to prepare for migration without exposing yourse= lf
>
> ## Pre-emptive Commit/Reveal
>
> What if users could commit *today* to future migration transactions, w= ithout
> revealing which UTXOs they control?
>
> The idea is simple:
> - Users create and sign transactions moving their funds to quantum-saf= e addresses
> - They compute a Merkle tree of all these transactions
> - They publish only the root hash (e.g., in an OP_RETURN)
> - This can be done today, with no consensus changes
>
> If/when quantum computers become a threat:
> - We soft fork to require at least n confirmations on quantum vulnerab= le
> transactions
> - Transactions work as always but can't be spent for n blocks
> - If attacked, the victim can reveal the commitment to execute the rec= overy
> transaction
>
> ## Key Advantages
>
> 1. **No consensus changes needed now** - Users can start protecting th= emselves
> immediately
> 2. **Privacy preserved** - The commitment reveals nothing about which = UTXOs you own
> 3. **Efficient** - One hash can commit to migrations for all your UTXO= s or even
> the UTXOs of several users
> 4. **Flexible** - Works whether or not a quantum computer ever actuall= y appears
>
> ## Differences from Tadge's Proposal
>
> While Tadge's proposal solves post-quantum spending where any pubk= ey reveal is
> dangerous, this proposal is about preparation:
>
> - **Timing**: Pre-quantum (can start now) vs. post-quantum (activates = after QC
> appears)
> - **Scope**: Migration to quantum-safe addresses for all address types= in the
> worst case vs. general spending of hashed pubkeys
>
> Both use the same cryptographic primitive (commit/reveal) but for diff= erent
> phases of the quantum transition.
>
> This approach lets users protect their funds without waiting for conse= nsus
> changes or revealing their holdings. It's a "poison pill"= ; against quantum
> attackers - they might steal coins, but pre-committed owners can recla= im them.
>
> Would love to hear thoughts on this approach.
>
> Leo Wandersleb
>
> --
> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send= an email to bitcoindev+unsubscribe@googlegroups.com= .
> To view this discussion visit https://groups.google.com/d/msgid/bi= tcoindev/2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a%40gmail.com.



--
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.co= m/d/msgid/bitcoindev/CA%2B_eyec5LLsAMrVuzGFOKRd1-1Msf8Bc0Aew%3Df02%3DpJi19F= LNw%40mail.gmail.com.
--000000000000b066e30636a32f5c--