path: root/e3/937b2ea62d70758826b78c45815bb9e83f5d4e

Delivery-date: Mon, 26 May 2025 08:43:03 -0700
Received: from mail-oi1-f189.google.com ([209.85.167.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCYMD7OS6ECBB64X2LAQMGQECTFYU2Q@googlegroups.com>)
	id 1uJZyf-0004s9-NG
	for bitcoindev@gnusha.org; Mon, 26 May 2025 08:43:02 -0700
Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-3fab1478893sf661403b6e.2
        for <bitcoindev@gnusha.org>; Mon, 26 May 2025 08:43:01 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1748274176; cv=pass;
        d=google.com; s=arc-20240605;
        b=TtA3xD/m6Eklxa0FKWM//YRC8m86HtLXrxMcu2ewNaZHtW+mPO9TlcDKiVWx7x4PC4
         s6UudFj//XtB9PGWiHTMJrKaMwF8l8wPA9qaqSg5IvUl5dh0odKO9smf2m/DpL0OhFDD
         oGKmvmEx69agTSUN+KBYYkeVq0FN3PU1ylvLTtJRgSml4Z7uiTqgMumXaWj1Z39YngnT
         kEFj0dzUOgE7xY64Dd3WWd7MVNQIXBHlzm9XOxymGWWVaxRW+aFVnUlBwS+6QVLu4/a1
         yWJkH0OzgAtsTcjIxDnDienfrhDLzMsMlPIRteI/2n4FydHSOS7OKDUyBO/wRh3dlxQv
         3K9w==
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:content-transfer-encoding:cc:to
         :subject:message-id:date:from:in-reply-to:references:mime-version
         :sender:dkim-signature:dkim-signature;
        bh=cr+a8x0WUHAIXdR1vTsGPM9GR2x9VDS9y3UZy7Uy0Ps=;
        fh=uIVMyfViGpisHGW3JlPHBwGErnozPsXrzP34T6GxdoE=;
        b=RXBJ5gNJsIMzcF2H6Ls0HrfLI+9KbbCRN1MhnqRVCDC1t/0WhRJi56SMKXGTYCenGO
         EyMqxrPUBxzsJRVD7/1si2WaqD/k7+6NVOp15IRqkfwbEQDjji1cevQAUU8BDpMXSCVE
         kVTcSWz/NN1lFmYP01FdTBbEtLJ+j8ArZAVx+G9d9qQ558pAMlCPzqbjWYHUlmsvJCYb
         wJiui3hiyj7uFbytLGxUr4FnhUBrWT+Iy0bn69wOoHIRSDrMrcmutgDj707Cz49xJGYL
         fw7h9mwV7AurAj5mN6AcvBr8+uvOHLbyog16q+gUEv9aGMdS5qBsxfKDdFWO3zEhS9n1
         kUbw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=TbCE32DE;
       spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) smtp.mailfrom=bnagaev@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=1748274176; x=1748878976; 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:content-transfer-encoding:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=cr+a8x0WUHAIXdR1vTsGPM9GR2x9VDS9y3UZy7Uy0Ps=;
        b=KEcBnj4MY2ORJeQoczmfxD8R0DkGXCSWLBh2GEWTQoyBhCgqryOQK5YcVJMDzaqnX4
         m2fj+7ES+FxZg6tPnB8m34H5MLKp1ckZA+yz+GC0DXOkPuY3wOfrtZ+dNrgjAirI+75q
         ov1D5CzfNEIGmxW4qGXfPThbISFgblPVen8YL5hLGotc7tMugUNsJaVkEp9wRhtII76e
         2Q+dkU6Ofl69ZHNFRRrtvNEgvwpNjY4VCWVEDar4suVAIc0Tj2TcsBKTz+ghaKfzvtHG
         xRRNhvjJTyJuEI2l78o8Uh9MOtQiaqNHJF5FvPAAji9TGUGsE85umhKbIs3EUAN5DM5/
         67RA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748274176; x=1748878976; 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:content-transfer-encoding:cc:to:subject
         :message-id:date:from:in-reply-to:references:mime-version:from:to:cc
         :subject:date:message-id:reply-to;
        bh=cr+a8x0WUHAIXdR1vTsGPM9GR2x9VDS9y3UZy7Uy0Ps=;
        b=ePpl773s3GSBUtZEyHYrYdgmhvgIrV84Q+LFaaELB+KNw0oIJXiozGBEbdXq9U86cx
         ZGFO4FjQj11flPEPu7bVpvayNEqh+AzyHg/9+heMZRNp1mTxlO8cJL7B/BNonoQAMvUN
         Dybr9pFyUK/JgwkmuvzjFD0Kh1HQppZIcxMOfNvp9oOEMq1ryolVuAoX0APUYPQoHH/Y
         6i8wRHwFhRrUags1YCVeTHHKeChJDMpxlrTXe/yT0Qt0IEQHsvb0Em9jki9SO41AqiJY
         fwvzAQhsoIorzCu1bdthIb0mLlP1UMMU86AHwqttHIaUj8lQFO4grkhdkiBF6wIEmSOP
         r5VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748274176; x=1748878976;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:content-transfer-encoding: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=cr+a8x0WUHAIXdR1vTsGPM9GR2x9VDS9y3UZy7Uy0Ps=;
        b=gGyVnVozVtrlnphADo3hI2r5lU/xarl6ypjKzOBue45KgBGH+vyXSD2IAJRkcgzhu5
         2TDHgs6Bi6NcJiIWa666e0q309mqH4brtF+h1KwBlMKUMtDVsCsdHNkr2v97NRu/ewXv
         /0NeJfCjPvxdkikuGQl73/E3szdlATv4C7YgQy8iOW+SPVpLzVIos4TtinRJ2hTZ2EOv
         8iGphgS2hlP838l4WgXc2U70SMf3hMKkWwMrYgFpUCFdPbjLD4FpyeZ20ohs6V9F4F8G
         e0yd2cvFpTdWY3BvY1/1iuonKS9uKP7caSnNRlg/lS6+hjx2F2WQraizIgR6HKcJuvZL
         iz/Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWgDLCxa9BRpj2tsxeyEICfiJBzwRqjzJF3e7QMslTVfy4+OHBOvleMJ+lQ6gdFijwgpDtuaXX8D+cT@gnusha.org
X-Gm-Message-State: AOJu0YzY0HBKT7hF93QfRtlGdZn0K/iAY2SATJD/RkU9uKyFNfJk9g61
	iAQuvOmgFb7WUUDW1lcJo56Lxpsz0MxUbe297tQ4zggO5KiZPTnSRsF1
X-Google-Smtp-Source: AGHT+IFMDX/+kfzjFK/k7634/k0onZuCnDKtOX3wGd7ILQ6wxOKZ3s1wZDJDUPMEVtLCaF6t/bQbmw==
X-Received: by 2002:a05:6808:6905:b0:3f8:eee4:7140 with SMTP id 5614622812f47-40646802306mr5393561b6e.22.1748274175525;
        Mon, 26 May 2025 08:42:55 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFgM4UAjQVGGzfvamkZNyPSg/meDIzMC4S+zLr6ZVUdLw==
Received: by 2002:a4a:d687:0:b0:608:3ac1:de02 with SMTP id 006d021491bc7-60b9f74f7b0ls449264eaf.1.-pod-prod-06-us;
 Mon, 26 May 2025 08:42:51 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCWFfr9w4X/huEB1Ial8D5zIZyfJj8kA42mYNKfSu2yXJ0m2K/tXXDtPc9d+pgAaIgVq6cXlfXSKdvKb@googlegroups.com
X-Received: by 2002:a05:6808:1b85:b0:402:ebf9:b770 with SMTP id 5614622812f47-40646855c6dmr4692592b6e.28.1748274171700;
        Mon, 26 May 2025 08:42:51 -0700 (PDT)
Received: by 2002:a05:6808:6389:b0:3fa:da36:efcd with SMTP id 5614622812f47-404da18c90emsb6e;
        Mon, 26 May 2025 03:03:42 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCU7DWf55j07cn6EnkYXRyWl7nBnLsuvi5nn/7l4bKZqCl5IjCCD/HtTuszSmmGeZabXgH1zklNRkEfR@googlegroups.com
X-Received: by 2002:a17:90b:1b51:b0:2ee:db1a:2e3c with SMTP id 98e67ed59e1d1-3110f1138aamr11658607a91.1.1748253821508;
        Mon, 26 May 2025 03:03:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1748253821; cv=none;
        d=google.com; s=arc-20240605;
        b=DPvdsoU9TEaVSgun3MvctQoyeaBCKOEGlNgcIg/PLjkUB0vDnxpRqS4t1DWClnzst1
         u7V1Bullip5BX+shehkAUGsZfLEWw10hVDazEirSsgeIT8axnZAgqnvnZXLhmg0rYmn5
         M8VelG1mce2HalLhQHp901u5kpo8DWLefxMjhx7T3+sJQbB8Jg7rNCix1Hm5YWk2Qkhr
         C9B+cYCLGEYMBbgBeRRCs1o72zdOigihhEvBEBRFD4HWa8uRzoZHdg7ARMekGe8tb5QP
         kdjxlHaQxJIjT3Rhp/GrejC+ZeDUbnzlqPawPb403xKW4EUUP7hvka7ll/Wsu5NRT1zA
         +gCw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:dkim-signature;
        bh=lZAfKMs8QvZdD+TMhlz8U0WsV+DMmSQ4oZfmPqF3AmY=;
        fh=bHvF8VrC1w2D+D15IamEYC8SFcm7h7zwWRe5kLIrPPY=;
        b=TWweB4swhkRwUwdEkQvOTmw8dclZX09IcA7XBaEdoU7uVXcWQCUjYlqIJ4jEAzJX4Q
         f1GKg6+ohEIE+A0KPhcAqyuZNaVJPEO1utjkKj4Aq3ncGmm21xFjkbzrJXeo3V52+Rcq
         vfje1ajGxyFYOJqPlK2TcTHdFlLcmM3KftP9ocM/3e2WfvqT0yctNm2yejtyQYwdlRf9
         QNs2j2GnqSe1wtWOuvltD/PRP83zxxITZpj1HSfaj+wHFpipQqYaW315TSxCCc5NKFLb
         qe3G2ej8aJoppr+1M78X6UsIV76xdbNiVHnjoJ0JZRnkDvRdhSvB1Uq71AV3E8yCpBXz
         3jNA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=TbCE32DE;
       spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) smtp.mailfrom=bnagaev@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com. [2607:f8b0:4864:20::102c])
        by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-30f364b09acsi127200a91.3.2025.05.26.03.03.41
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 26 May 2025 03:03:41 -0700 (PDT)
Received-SPF: pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) client-ip=2607:f8b0:4864:20::102c;
Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-310e1f4627aso1937154a91.2
        for <bitcoindev@googlegroups.com>; Mon, 26 May 2025 03:03:41 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCUkJ7n5hvztXMuZLxZ+1aCAdZNZy0OtXlUyi3R62ML6XqYlfLfG4LPnEX2kQzsNMXzC5RZXxN8UnKQA@googlegroups.com
X-Gm-Gg: ASbGncsn8PT298UDg8z2NGG7iJoa8LbiSCQmaimhmyICKKqUha1OuKTBAWC8/GLe5L2
	EZSIwxHDFbo0zxsoFg79WT5bAJXcbLqaPXml8358m7bRu3SYU3A9CgSEn7JirPzoIrcutnzzIOj
	sTt8csSPmASYFayGrR/CSbrmfmXSIXlQs=
X-Received: by 2002:a17:90a:d44d:b0:305:2d68:8d57 with SMTP id
 98e67ed59e1d1-3110f1129cemr13034721a91.5.1748253820928; Mon, 26 May 2025
 03:03:40 -0700 (PDT)
MIME-Version: 1.0
References: <CALkkCJY=dv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ@mail.gmail.com>
 <XHIL8Z4i4hji8LhbJ0AiKQ4eago2evXwjTGUOqqyAye_2nM3QicDpHo6KkcznBAHPUrIWSLj_GuiTQ_97KPjxcOrG8pE0rgcXucK2-4txKE=@protonmail.com>
 <CAH5Bsr0muoF27besnoQh32vL-keujeR+d-_JurE0+yXY5gPKQg@mail.gmail.com> <Rgj4DeSKQkdEWMRTmqYYLas84WIDyRftEKqmwlw0C9-ur4Tx9_d6g7SzTU_WBspYbezLDTMpgIFXon1_cpFSjgYOMtHlQJNS_utF2dZQ4ig=@proton.me>
In-Reply-To: <Rgj4DeSKQkdEWMRTmqYYLas84WIDyRftEKqmwlw0C9-ur4Tx9_d6g7SzTU_WBspYbezLDTMpgIFXon1_cpFSjgYOMtHlQJNS_utF2dZQ4ig=@proton.me>
From: Nagaev Boris <bnagaev@gmail.com>
Date: Mon, 26 May 2025 07:03:01 -0300
X-Gm-Features: AX0GCFtOE37MLnkXcEKW66KFOBsa7SntaNwjwd6at-Ky8PHvbT1YjySZfa66EaY
Message-ID: <CAFC_Vt4wjLV_iAHYDMcAJYP=PRo=jNWQzmrUfJUK2_GXTiPnjA@mail.gmail.com>
Subject: Re: [bitcoindev] Hashed keys are actually fully quantum secure
To: conduition <conduition@proton.me>
Cc: Lloyd Fournier <lloyd.fourn@gmail.com>, Antoine Poinsot <darosior@protonmail.com>, 
	=?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Original-Sender: bnagaev@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=TbCE32DE;       spf=pass
 (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::102c
 as permitted sender) smtp.mailfrom=bnagaev@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 (/)

Hey Conduition,

Isn't this a bit of a chicken-and-egg issue? The EC signature signs
the second transaction, which depends on the QR output's txid, which
in turn depends on the precommitted EC signature. One way to break
this circular dependency is to use the SIGHASH ANYONECANPAY modifier
to exclude the QR output from the EC signature scope. Or an
inscription can be used to commit to the EC signature without
affecting the txid of the first transaction.

That said, I've been thinking about an alternative approach that might
also be more convenient in practice.

What if we commit to the SHA256 of the EC public key instead of the EC
signature? If this hash is included in a QR output at least X blocks
in advance, it offers the same security under the assumption that a
quantum attacker can recover the private key from the public key.

However, there's a problem: an attacker can observe the creation of QR
outputs and create their own outputs committing to the same
SHA256(pubkey) in advance. To prevent this, the commitment to the EC
pubkey hash must be hidden from observers. One way to achieve this is
by embedding SHA256(pubkey) in a Taproot leaf. Since Taproot leaves
are not visible on-chain until revealed, the attacker can't learn
which pubkeys are being committed to. Once the commitment is revealed
at spend time, it's too late for the attacker to make a QR output and
wait out the delay. Multiple EC inputs of a transaction can reuse the
same QR input of the transaction.

The pubkey (and its SHA256 hash) is only revealed when spending an EC
output. A new consensus rule would require that such a spend be
accompanied by a QR output, with a tapleaf committing to the SHA256 of
the same EC pubkey, created at least X blocks earlier and spent in the
same transaction. An attacker seeing the EC pubkey in the mempool
would have to create their own QR output committing to the same hash,
mine it, wait X blocks, and then attempt an RBF =E2=80=94 but by then, the
legitimate transaction would likely be confirmed.

From a usability standpoint, this seems cleaner: the user can
precommit to the SHA256 of the EC pubkey in advance and decide how to
spend it later. For example, if you're managing multiple EC UTXOs
(say, 10), you can commit to all of them in a single transaction
creating QR outputs, and handle second-stage spends later as needed.
This is not only simpler but also more efficient. You can also create
a single QR output with many tapleaves committing to SHA256 hashes of
multiple EC pubkeys, and spend all the EC coins plus one QR coin in a
single transaction.

In the original scheme, if the user has multiple EC UTXOs on the same
legacy EC address, they would need to create a separate QR output for
each one and spend all EC+QR pairs together in a single transaction.
With this alternative, a single QR output committing to the pubkey
hash can authorize the spend of multiple EC UTXOs in one transaction.
That significantly reduces the number of QR outputs required when
consolidating funds from a single EC key. Note that such coins must be
spent all together in both schemes, because spending a subset reveals
the EC pubkey, making the remaining coins vulnerable.

Would be curious to hear if others have considered this route or see
potential pitfalls.

Best,
Boris


On Sun, May 25, 2025 at 3:38=E2=80=AFPM 'conduition' via Bitcoin Developmen=
t
Mailing List <bitcoindev@googlegroups.com> wrote:
>
> Hey friends,
>
> Even if we can require a pre-quantum output to be paired with
> a QR output when spending in this way, and even if the QR output
> must be at least X blocks old... What prevents an attacker from
> just pre-minting a whole bunch of QR outputs, aging them for a while,
> and then lying in wait to steal?
>
> A well-prepared QC attacker's QR outputs may even be significantly
> older than an honest user's QR outputs. An aged QR output committing
> to a QR signature proves nothing about the ownership of an unrelated
> pre-quantum UTXO.
>
> The QR output must prove historical ownership of the vulnerable
> EC key-hashed output. To fix this, we must change this line in OP:
>
> > 2. the user creates a transaction that, aside from having a usual
> > spendable output also commits to a signature of QR public key.
>
> This transaction must be fully protected by QR signing. It must
> commit to, but not reveal, the EC public key, while also proving
> ownership. I would correct this description to:
>
> > 2. the user creates a transaction with at least one QR input which,
> > aside from having a usual spendable output also commits to
> > *a signature from the legacy EC pubkey.*
>
> This TX might have an OP_RETURN output or an inscription which embeds
>
> SHA256(ec_signature).  Or, like taproot, the QR output script might
> itself contain a hidden commitment to that hash.
>
> A few blocks after this transaction is mined, the honest user can
> spend the QR and legacy UTXOs together, opening the EC signature
> commitment. Validating nodes would have to check the QR output is
> old enough, but also check that it committed to the correct
> pubkey+signature.
>
> A QC attacker shouldn't be able to break this unless the legacy EC
> pubkey has already been revealed prior to the commitment TX.
> Only the authentic user could've pre-committed to that signature.
> If we assume the QC attacker can't roll-back the chain more than
> X blocks, they can't go back and insert an EC sig commitment
> retroactively.
>
> I suspect this might've been Martin's intent, judging from the way he
> was writing?
>
> regards,
> conduition
>
>
> On Sunday, March 23rd, 2025 at 8:24 PM, Lloyd Fournier <lloyd.fourn@gmail=
.com> wrote:
>
> >
>
> >
>
> > On Tue, 18 Mar 2025 at 00:48, 'Antoine Poinsot' via Bitcoin Development=
 Mailing List <bitcoindev@googlegroups.com> wrote:
> >
>
> >
>
> > > I suppose you could in theory have, in addition to making spending ol=
d outputs invalid on their own, a rule which dictates they may only be spen=
t along with a QR output at least X blocks old. This would give the honest =
user a headstart in this race, but meh.
> >
>
> >
>
> > Yes this is how I read the OP "after sufficient number of blocks". I th=
ink this is a really nice idea. The head start can be arbitrarily large so =
that the attacker simply cannot compete. It's probably not too difficult to=
 design some honest RBF mechanism either such that you can bump the fee wit=
h a new QR signature if it's taking too long.
> >
>
> > LL
> >
>
> >
>
> > > On Sunday, March 16th, 2025 at 2:25 PM, Martin Habov=C5=A1tiak <marti=
n.habovstiak@gmail.com> wrote:
> > >
>
> > > > Hello list,
> > > > this is somewhat related to Jameson's recent post but different eno=
ugh to warrant a separate topic.
> > > >
>
> > > > As you have probably heard many times and even think yourself, "has=
hed keys are not actually secure, because a quantum attacker can just snatc=
h them from mempool". However this is not strictly true.
> > > >
>
> > > > It is possible to implement fully secure recovery if we forbid spen=
ding of hashed keys unless done through the following scheme:
> > > > 0. we assume we have *some* QR signing deployed, it can be done eve=
n after QC becomes viable (though not without economic cost)
> > > > 1. the user obtains a small amount of bitcoin sufficient to pay for=
 fees via external means, held on a QR script
> > > > 2. the user creates a transaction that, aside from having a usual s=
pendable output also commits to a signature of QR public key. This proves t=
hat the user knew the private key even though the public key wasn't reveale=
d yet.
> > > > 3. after sufficient number of blocks, the user spends both the old =
and QR output in a single transaction. Spending requires revealing the prev=
iously-committed sigature. Spending the old output alone is invalid.
> > > >
>
> > > > This way, the attacker would have to revert the chain to steal whic=
h is assumed impossible.
> > > >
>
> > > > The only weakness I see is that (x)pubs would effectively become pr=
ivate keys. However they already kinda are - one needs to protect xpubs for=
 privacy and to avoid the risk of getting marked as "dirty" by some agencie=
s, which can theoretically render them unspendable. And non-x-pubs generall=
y do not leak alone (no reason to reveal them without spending).
> > > >
>
> > > > I think that the mere possibility of this scheme has two important =
implications:
> > > > * the need to have "a QR scheme" ready now in case of a QC coming t=
omorrow is much smaller than previously thought. Yes, doing it too late has=
 the effect of temporarily freezing coins which is costly and we don't want=
 that but it's not nearly as bad as theft
> > > > * freezing of *these* coins would be both immoral and extremely dan=
gerous for reputation of Bitcoin (no comments on freezing coins with reveal=
ed pubkeys, I haven't made my mind yet)
> > > >
>
> > > > If the time comes I'd be happy to run a soft fork that implements t=
his sanely.
> > > >
>
> > > > Cheers
> > > >
>
> > > > Martin
> > > >
>
> > > > --
> > > > 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, s=
end an email to bitcoindev+unsubscribe@googlegroups.com.
> > > > To view this discussion visit https://groups.google.com/d/msgid/bit=
coindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.=
com.
> > >
>
> > > --
> > > You received this message because you are subscribed to the Google Gr=
oups "Bitcoin Development Mailing List" group.
> > > To unsubscribe from this group and stop receiving emails from it, sen=
d an email to bitcoindev+unsubscribe@googlegroups.com.
> > > To view this discussion visit https://groups.google.com/d/msgid/bitco=
indev/XHIL8Z4i4hji8LhbJ0AiKQ4eago2evXwjTGUOqqyAye_2nM3QicDpHo6KkcznBAHPUrIW=
SLj_GuiTQ_97KPjxcOrG8pE0rgcXucK2-4txKE%3D%40protonmail.com.
> >
>
> > --
> > You received this message because you are subscribed to the Google Grou=
ps "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/bitcoin=
dev/CAH5Bsr0muoF27besnoQh32vL-keujeR%2Bd-_JurE0%2ByXY5gPKQg%40mail.gmail.co=
m.
>
> --
> 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/bitcoinde=
v/Rgj4DeSKQkdEWMRTmqYYLas84WIDyRftEKqmwlw0C9-ur4Tx9_d6g7SzTU_WBspYbezLDTMpg=
IFXon1_cpFSjgYOMtHlQJNS_utF2dZQ4ig%3D%40proton.me.



--=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/=
CAFC_Vt4wjLV_iAHYDMcAJYP%3DPRo%3DjNWQzmrUfJUK2_GXTiPnjA%40mail.gmail.com.