path: root/7c/206ff86f5c4189a974cdcd15070ae0372e62bd

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 <bitcoindev+bncBD2IRYOX4AFRBOWX7LAQMGQEEGQ5Q6A@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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> <CAFC_Vt7z5Vj=r90J8RoH3sC5592BO4G9U3L9gdcX+D3DruC1PQ@mail.gmail.com>
In-Reply-To: <CAFC_Vt7z5Vj=r90J8RoH3sC5592BO4G9U3L9gdcX+D3DruC1PQ@mail.gmail.com>
From: Leo Wandersleb <lwandersleb@gmail.com>
Date: Tue, 3 Jun 2025 06:19:16 +0200
X-Gm-Features: AX0GCFvQNCdjCC78n2ohrOvzjVyHhwF2AuVcwVBe9-jO4Lnj35bpNtCa3R8xd5g
Message-ID: <CA+_eyec5LLsAMrVuzGFOKRd1-1Msf8Bc0Aew=f02=pJi19FLNw@mail.gmail.com>
Subject: Re: [bitcoindev] Pre-emptive commit/reveal for quantum-safe migration (poison-pill)
To: Nagaev Boris <bnagaev@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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, <bnagaev@gmail.com> 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 <lwandersleb@gmail.=
com>
> 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

<div dir=3D"auto">Hi Nagaev,<div dir=3D"auto"><br></div><div dir=3D"auto">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&#39;s proposal.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">With QC further advancement to q=
uick and cheap attacks, Tadge&#39;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.</div></div><br><div class=3D"gmail_quote=
 gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 3 Jun=
 2025, 01:12 Nagaev Boris, &lt;<a href=3D"mailto:bnagaev@gmail.com">bnagaev=
@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Leo,<=
br>
<br>
Thanks for sharing your proposal, a very interesting approach! I have<br>
a few questions and comments:<br>
<br>
&gt; Users create and sign transactions moving their funds to quantum-safe =
addresses<br>
&gt; 1. **No consensus changes needed now** - Users can start protecting th=
emselves<br>
&gt; immediately<br>
<br>
How would users prepare transactions moving funds to quantum-safe<br>
addresses now, before such address types exist? We would need to know<br>
the structure of a quantum-safe address to create the transaction.<br>
Either an existing address type would need to support some form of<br>
quantum protection already (e.g., WOTS implemented via BitVM), or we<br>
would still need a softfork to introduce a new address type.<br>
<br>
Additionally, a future softfork (or possibly a hardfork, see below)<br>
would still be required to enforce the new spending rules.<br>
<br>
&gt; - If attacked, the victim can reveal the commitment to execute the rec=
overy<br>
&gt; transaction<br>
<br>
Wouldn&#39;t such a recovery transaction require a hardfork? As far as I<br=
>
understand, it wouldn&#39;t be valid under current consensus rules.<br>
Enabling it would require relaxing existing rules, which would imply a<br>
hardfork.<br>
<br>
Best,<br>
Boris<br>
<br>
On Mon, Jun 2, 2025 at 6:12=E2=80=AFPM Leo Wandersleb &lt;<a href=3D"mailto=
:lwandersleb@gmail.com" target=3D"_blank" rel=3D"noreferrer">lwandersleb@gm=
ail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi all,<br>
&gt;<br>
&gt; I&#39;d like to propose a variant of the commit/reveal schemes being d=
iscussed for<br>
&gt; quantum resistance, but with a different goal and timeline. This build=
s on ideas<br>
&gt; from the recent thread &quot;Post-Quantum commit / reveal Fawkescoin v=
ariant as a<br>
&gt; soft fork&quot; but targets a different use case.<br>
&gt;<br>
&gt; ## The Problem<br>
&gt;<br>
&gt; Current discussions focus on emergency reactive measures - what to do =
*after*<br>
&gt; quantum computers arrive. But this leaves users in a difficult positio=
n:<br>
&gt;<br>
&gt; 1. They can&#39;t prove ownership of their coins without revealing pub=
keys (and thus<br>
&gt; becoming vulnerable)<br>
&gt; 2. Moving coins to quantum-safe addresses early reveals which addresse=
s are<br>
&gt; active vs. abandoned<br>
&gt; 3. There&#39;s no way to prepare for migration without exposing yourse=
lf<br>
&gt;<br>
&gt; ## Pre-emptive Commit/Reveal<br>
&gt;<br>
&gt; What if users could commit *today* to future migration transactions, w=
ithout<br>
&gt; revealing which UTXOs they control?<br>
&gt;<br>
&gt; The idea is simple:<br>
&gt; - Users create and sign transactions moving their funds to quantum-saf=
e addresses<br>
&gt; - They compute a Merkle tree of all these transactions<br>
&gt; - They publish only the root hash (e.g., in an OP_RETURN)<br>
&gt; - This can be done today, with no consensus changes<br>
&gt;<br>
&gt; If/when quantum computers become a threat:<br>
&gt; - We soft fork to require at least n confirmations on quantum vulnerab=
le<br>
&gt; transactions<br>
&gt; - Transactions work as always but can&#39;t be spent for n blocks<br>
&gt; - If attacked, the victim can reveal the commitment to execute the rec=
overy<br>
&gt; transaction<br>
&gt;<br>
&gt; ## Key Advantages<br>
&gt;<br>
&gt; 1. **No consensus changes needed now** - Users can start protecting th=
emselves<br>
&gt; immediately<br>
&gt; 2. **Privacy preserved** - The commitment reveals nothing about which =
UTXOs you own<br>
&gt; 3. **Efficient** - One hash can commit to migrations for all your UTXO=
s or even<br>
&gt; the UTXOs of several users<br>
&gt; 4. **Flexible** - Works whether or not a quantum computer ever actuall=
y appears<br>
&gt;<br>
&gt; ## Differences from Tadge&#39;s Proposal<br>
&gt;<br>
&gt; While Tadge&#39;s proposal solves post-quantum spending where any pubk=
ey reveal is<br>
&gt; dangerous, this proposal is about preparation:<br>
&gt;<br>
&gt; - **Timing**: Pre-quantum (can start now) vs. post-quantum (activates =
after QC<br>
&gt; appears)<br>
&gt; - **Scope**: Migration to quantum-safe addresses for all address types=
 in the<br>
&gt; worst case vs. general spending of hashed pubkeys<br>
&gt;<br>
&gt; Both use the same cryptographic primitive (commit/reveal) but for diff=
erent<br>
&gt; phases of the quantum transition.<br>
&gt;<br>
&gt; This approach lets users protect their funds without waiting for conse=
nsus<br>
&gt; changes or revealing their holdings. It&#39;s a &quot;poison pill&quot=
; against quantum<br>
&gt; attackers - they might steal coins, but pre-committed owners can recla=
im them.<br>
&gt;<br>
&gt; Would love to hear thoughts on this approach.<br>
&gt;<br>
&gt; Leo Wandersleb<br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" t=
arget=3D"_blank" rel=3D"noreferrer">bitcoindev+unsubscribe@googlegroups.com=
</a>.<br>
&gt; To view this discussion visit <a href=3D"https://groups.google.com/d/m=
sgid/bitcoindev/2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a%40gmail.com" rel=3D"no=
referrer noreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bi=
tcoindev/2c3b7e1c-95dd-4773-a88f-f2cdb37acf4a%40gmail.com</a>.<br>
<br>
<br>
<br>
-- <br>
Best regards,<br>
Boris Nagaev<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CA%2B_eyec5LLsAMrVuzGFOKRd1-1Msf8Bc0Aew%3Df02%3DpJi19FLNw%40mail=
.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.co=
m/d/msgid/bitcoindev/CA%2B_eyec5LLsAMrVuzGFOKRd1-1Msf8Bc0Aew%3Df02%3DpJi19F=
LNw%40mail.gmail.com</a>.<br />

--000000000000b066e30636a32f5c--