path: root/a2/a9878dd4c63b520dc4f15cd51e51d31d323071

Delivery-date: Mon, 17 Mar 2025 06:36:28 -0700
Received: from mail-qt1-f191.google.com ([209.85.160.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+bncBDLIXVE5ZYCBBUWK4C7AMGQEZV6HV5I@googlegroups.com>)
	id 1tuAdm-0003qf-PK
	for bitcoindev@gnusha.org; Mon, 17 Mar 2025 06:36:27 -0700
Received: by mail-qt1-f191.google.com with SMTP id d75a77b69052e-4768a1420b6sf87858761cf.1
        for <bitcoindev@gnusha.org>; Mon, 17 Mar 2025 06:36:26 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1742218581; cv=pass;
        d=google.com; s=arc-20240605;
        b=IKqCvj57IYmVQKFcZx/8DvHV8Xlx1xhweDIJK8IyKo6mPB16NMjkE16CzdshkJjw3b
         0Ig+PRvPcwvVxf/pySQEK9msEqhabmYgowbAM+aBCtMWFBfdPKuAqjIEJS6bArwD4W5S
         DGKHrALmHNYFdWYGKiAMS1P3k7/aT4rZRUrBxF9op7H7VtbK1bIUEDevSrExPsEoaWQu
         X9goX5GUAx9XaS9CG+eonh63clFyBDJ9eWRryPFkydV5+xcWf7bB0mio0TycltTDgdpi
         ERwQK9ABz+0kv5GSJ5vBaRt1ya2D6ZrMp4HM7mXHvJR5jXmcPdw2TsjB2sVyCvGaN2lL
         8JVw==
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=jbFjELVLbheeYIpRn89LhWZyZ5lxMzvYIDd6N0Imp4M=;
        fh=q017AccRgfRhSiKN1rqak5JrtbVjAvZWHkC9R59qzRY=;
        b=XBKYqzECiYCG5cU3aFr6guGYjiRkfTnH4zjP0F/Tp+e/9HbsxKYr26lQigvGcWlFUp
         AH5dRW4Z0n5LqPrP0yTW+dadvD6ccGScrDetsxMzTtew3ftjaT6qSHUm/OCMnz6jTeoi
         5VwN8AizANFxWiBDhAt6Sfc62whQ5sZdVtupaNoMxlAJHBeeYT18sJlsBqGc8NmJKBav
         pNqMaakChMu95W1Cw0+Ju5TlwfFmgGrKKxVeweZ2RBkHUNo5KDF1dcOid5hAGtmuYU5w
         HG1epqbEfnn3oUZPaqk0aBJpJPk8cuzRtJ428TrW5pZahCS6x0+ZX+ZWDxAd29m4/Q/S
         oXBg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=I8HE24Ir;
       spf=pass (google.com: domain of lloyd.fourn@gmail.com designates 2607:f8b0:4864:20::836 as permitted sender) smtp.mailfrom=lloyd.fourn@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=1742218581; x=1742823381; 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=jbFjELVLbheeYIpRn89LhWZyZ5lxMzvYIDd6N0Imp4M=;
        b=TcuiFp6HYBpPmdZFUmyEK9RUWFIOYV41/h1PmJs/hEtRxXGAbYBE5uaZbQMhxW8et/
         I90lFVQKFde+cybrlY7nmbrVWfbJR/aNGcGZWErqf5wlE8h3Ylb6G7W/nvqc75v/cLiI
         9g/1/OYJ2NsI6c/8fPTf6mN7lF+3Ets39cUpv3qA1nN4rQ9NZvzizrMxTl1K8G/DyRXU
         D5Uxi0r7JwbmhwzBu06t8YrpgseyGFdP26KTjh5zwwbxnqQYkoAeZBSdGghPnHrP+zNM
         qvjndjaKna6qj+F1xsOlhln57TzsnOBiTIyjwjymvMhOgYRxVjSm/cDyZoJ0uPDIxypz
         uVSQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1742218581; x=1742823381; 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=jbFjELVLbheeYIpRn89LhWZyZ5lxMzvYIDd6N0Imp4M=;
        b=AQBod9KXLjGqa2eDSXHIaLLnYocvSP89IPE3fLGijXl+FC6nonc9Y+FummEsGziM3x
         FyBxoY1+TBYhjpsLDu4yzbEBNhjmmKmFVDwIMQGFSvSwOi6SYaECtHoTaPdPhVLI0gay
         xAWNrrHQd/CXf7sSIPX4bCow0LId+/Q516A1bh0Hgy6LzfmTl5FSuSRum5I/3+YWRJwR
         nJnqn99fpf1bplG6dcDlFLfzFpR5MG8r0P1Uxo15JZANGS59zZ8joAC8hxOy830/nHR3
         qTiuPTyfStuCBxK8aum9pz/qdE1NmP4+/nc1J0g8okuhfGbTQEUZo4i1ylgYk+PYXK07
         pL3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1742218581; x=1742823381;
        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=jbFjELVLbheeYIpRn89LhWZyZ5lxMzvYIDd6N0Imp4M=;
        b=XnSLBMnvE1akLaFnt5mCRLv+5SbH2IgW+XSwCkAIxNIX9xPdYqDNUCSi6+qi195fEd
         aPr0Ggv8UeStNCU32Ik0Lb1lFrT6/vEhW8lOI1ZQgQQzqP4D7OyBx+Tl8gZU/807bwLy
         /K1+KM17zBNiQCbwclGh9rQzfDlDFw3ZNJTqWMHyrCqkvKagFNcQniumlv0grk1iSb58
         ZkN8YZf1OcX8DW5Yqq9LsneDZMon9PlsIQ3mkIsSdnS5x8b2wSRLaE2H5Y1tdV/6XRSw
         zxRme4T3LiqSBqoZxkvsUSXvhM99agQR3WuQyOlHPch5pEa/D7IFf69Jk9FOgrq2Njbg
         CB0w==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWrrsNMAtvTdeBfM8/JaA/L35+IPtDb+rxkYyg7DWHDwR+12wAMCyDJKxjPjkuwd4amFJ/DNM8GbNDv@gnusha.org
X-Gm-Message-State: AOJu0YwJe7M7uSdGW72PTm135+yrH3VpOEGBqCkK7hEfs9tlm1Dfwj0S
	qysceD0Oz2Na3Uxr0sC+yXSWmPfK/gP4q8pTMgJ68j+X1b//NRnT
X-Google-Smtp-Source: AGHT+IE/5yLUdAZWYVvpc9gJn5KAxhVKE+t5L35kAjdXbeXMc5oF0IXIIfVVCC0iywc+nFAU35gtZQ==
X-Received: by 2002:a05:622a:341:b0:476:8a5f:8cfb with SMTP id d75a77b69052e-476c81c33b3mr167038541cf.38.1742218580768;
        Mon, 17 Mar 2025 06:36:20 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAK2N7p390LL90eTG55D/M4RmcmkMIwPgEZgIl9jmlY58Q==
Received: by 2002:a05:622a:1dce:b0:476:98d5:b6a4 with SMTP id
 d75a77b69052e-476b7db0a9els99369481cf.1.-pod-prod-03-us; Mon, 17 Mar 2025
 06:36:18 -0700 (PDT)
X-Received: by 2002:a05:620a:468d:b0:7c5:562d:cd01 with SMTP id af79cd13be357-7c57c77826cmr1487375885a.16.1742218577896;
        Mon, 17 Mar 2025 06:36:17 -0700 (PDT)
Received: by 2002:a05:620a:530e:b0:7c5:495f:5415 with SMTP id af79cd13be357-7c57bd9074bms85a;
        Mon, 17 Mar 2025 03:44:53 -0700 (PDT)
X-Received: by 2002:a05:6214:ca9:b0:6e8:ffb6:2f90 with SMTP id 6a1803df08f44-6eaeaa1d1f9mr151918716d6.11.1742208291806;
        Mon, 17 Mar 2025 03:44:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1742208291; cv=none;
        d=google.com; s=arc-20240605;
        b=HkPbXPP9MmyiYnKAIbsl4SAjTxtWJ4yRnJkwFb4obtWiop/6dFERUJJZ4XIA2Q9bVI
         x3//iJHkWLFQgKSrTZpDoBzM/rm60hps5Ct210hqdsEdBW/GIo/njYqfMfOdTkmH17CC
         gfXOp8iqjOcPmMInZT9WsXuTIfT/P2OEaogNJcnO73J5enl0AS+7tm/55UjFUVB3+ld1
         xdH/5dlO0w2K/VN0j2ZFGxj3u0nCUkuyMCUBL3/24keEzwdwSPy4YLhRvXX/6HkQ7jGk
         txxcrAAUqROdU2xNXgRqi6wEUWfdGdq/FNcD2BaO1g9kC262A4juI4GkQyo3tmlpej8K
         BUzA==
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=SmWpWypn8D3ZOILuwUHjDIcByn0sEiKcwwm+ZdXCYe0=;
        fh=FHPCOD3vptmuEQg9drujpZ488lCS6X5YsZgbHrlMbXI=;
        b=XkJm84VqJehTA/G1pLL06MPpxs5ecAM3IW5vijBSzAjDJfJvDT+rytA7OQFJe1LQJl
         +ycasfMoaz0W5r/8kxZ2uf0DKqOjuu8Vm/8tIbhYwyCbytKJzHpRHvTG/mQz4V2TEQ+v
         SL9RKuqFigsq9I5q0VmMy0hEDhysR/lRHxu/lV9av+5gTewOupwti0ylYJqqKOQ+3dFG
         Ff5wOAacg2cQ4paFNE4vi4mbXXDVXuOX5OezL56mPrJB6/j5RciChtLhgf/6lNQRhbgH
         a/k4UXQIRaC/vHkJeatLxOxGjKr/FYY2XkB7qW2mJjHLdPnzGoeqnNUnTR8X5UhkoFIb
         Umng==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=I8HE24Ir;
       spf=pass (google.com: domain of lloyd.fourn@gmail.com designates 2607:f8b0:4864:20::836 as permitted sender) smtp.mailfrom=lloyd.fourn@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com. [2607:f8b0:4864:20::836])
        by gmr-mx.google.com with ESMTPS id 6a1803df08f44-6eade206cdfsi4016416d6.8.2025.03.17.03.44.51
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 17 Mar 2025 03:44:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of lloyd.fourn@gmail.com designates 2607:f8b0:4864:20::836 as permitted sender) client-ip=2607:f8b0:4864:20::836;
Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-47684d4effbso4711781cf.1
        for <bitcoindev@googlegroups.com>; Mon, 17 Mar 2025 03:44:51 -0700 (PDT)
X-Gm-Gg: ASbGncsOc7TtVttju2GMdkbwusOPNCAy89LW95fdqTpTzvorIwE9nD+e+BdTtRBYbWD
	SvMMdtuj5J6jDQ4aI6LiSEWZwQQZgau1M6jGdEVYRfn2cwT4ghkZN5EGCujMzEp54s6S565q58I
	/iD04wXMs8imXibz3vd3JtVz5EnA==
X-Received: by 2002:ac8:58c1:0:b0:471:fe93:4b5f with SMTP id
 d75a77b69052e-476c81b622emr65465401cf.13.1742208291380; Mon, 17 Mar 2025
 03:44:51 -0700 (PDT)
MIME-Version: 1.0
References: <CALkkCJY=dv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ@mail.gmail.com>
In-Reply-To: <CALkkCJY=dv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Mon, 17 Mar 2025 21:44:23 +1100
X-Gm-Features: AQ5f1Jr9emqfLkcqYPA_mXpaLYvZqZ6oGB6pD-cxcq0sAfGC-I6mDURMPew771A
Message-ID: <CAH5Bsr3Yx1n22svy7QCTkT_BdzxLUqSmaR6Ji+v7Zf4Pph9S7w@mail.gmail.com>
Subject: Re: [bitcoindev] Hashed keys are actually fully quantum secure
To: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000005523640630877aec"
X-Original-Sender: lloyd.fourn@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=I8HE24Ir;       spf=pass
 (google.com: domain of lloyd.fourn@gmail.com designates 2607:f8b0:4864:20::836
 as permitted sender) smtp.mailfrom=lloyd.fourn@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 (/)

--0000000000005523640630877aec
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This seems like a very clever idea. It allows us to mostly ignore the QC
question until a threat actually materializes and then soft fork to
disallow bare public key spending with minimal actions needed to be taken
by users. Nice work!

A couple of important points:
- Taproot keys are also "hashed keys" since the internal key is technically
hashed to produce the external. If you disallow key path spend you can
apply the same rule by using the internal key to produce the commitment
signature.
- Taproot keys are actually better hashed keys since you don't have to
worry about whether you've revealed your public key on-chain in the past
e.g. via address re-use if you use external key spends (since this doesn't
reveal your internal key).

If this approach gains acceptance I think the main immediate action users
can take is to move to a taproot wallet. I predict trying to advise people
to move to p2pkh addresses or that p2pkh addresses are "fine" will create
confusion since there are huge numbers of coins in p2pkh addresses whose
public key has already been revealed and people may do address reuse
without knowing it.
Also an attractive approach is to embed the QR signature scheme in a
tapleaf before activating it so that most coins already have a QR spending
path ready to go. This is more straightforward if taproot is normalized
first.
I understand that people might feel "less protected" on a taproot address
because they might get sniped by the QC attacker before the freezing fork
has been activated but I don't think this is a serious concern relative to
the millions of coins available with known public keys. We have to freeze
it before they can be taken.

So outside of cryptography, the difficult task is to come to a social
consensus mechanism about when to trigger the freezing soft fork. It should
be done *before* a secp256k1 DLOG QC can be built but *after* we know that
one can be built. Right now it is certainly not clear that one *can* be
built ever and we won't have any indication this decade and maybe the next.
It may be a matter of debate whether we've reached that point in 10 years
(it certainly isn't now) and you can imagine malicious actors trying to
subvert the process either to hold it back or to push it forward.

LL

On Mon, 17 Mar 2025 at 05:31, Martin Habov=C5=A1tiak <martin.habovstiak@gma=
il.com>
wrote:

> Hello list,
>
> this is somewhat related to Jameson's recent post but different enough to
> warrant a separate topic.
>
> As you have probably heard many times and even think yourself, "hashed
> keys are not actually secure, because a quantum attacker can just snatch
> them from mempool". However this is not strictly true.
>
> It is possible to implement fully secure recovery if we forbid spending o=
f
> hashed keys unless done through the following scheme:
> 0. we assume we have *some* QR signing deployed, it can be done even afte=
r
> 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
> spendable output also commits to a signature of QR public key. This prove=
s
> that the user knew the private key even though the public key wasn't
> revealed yet.
> 3. after sufficient number of blocks, the user spends both the old and QR
> output in a single transaction. Spending requires revealing the
> previously-committed sigature. Spending the old output alone is invalid.
>
> This way, the attacker would have to revert the chain to steal which is
> assumed impossible.
>
> The only weakness I see is that (x)pubs would effectively become private
> 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
> agencies, which can theoretically render them unspendable. And non-x-pubs
> generally 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 tomorro=
w
> 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 th=
at
> but it's not nearly as bad as theft
> * freezing of *these* coins would be both immoral and extremely dangerous
> for reputation of Bitcoin (no comments on freezing coins with revealed
> pubkeys, I haven't made my mind yet)
>
> If the time comes I'd be happy to run a soft fork that implements this
> 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, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-b=
yGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-=
byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter>
> .
>

--=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/=
CAH5Bsr3Yx1n22svy7QCTkT_BdzxLUqSmaR6Ji%2Bv7Zf4Pph9S7w%40mail.gmail.com.

--0000000000005523640630877aec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">This seems like a very clever idea. It al=
lows us to mostly ignore the QC question until a threat actually materializ=
es and then soft fork to disallow bare public key spending with minimal act=
ions needed to be taken by users. Nice work!<br><br>A couple of important p=
oints:<br>- Taproot keys are also &quot;hashed keys&quot; since the interna=
l key is technically hashed to produce the external. If you disallow key pa=
th spend you can apply the same rule by using the internal key to produce t=
he commitment signature.<br>- Taproot keys are actually better hashed keys =
since you don&#39;t have to worry about whether you&#39;ve revealed your pu=
blic key on-chain in the past e.g. via address re-use if you use external k=
ey spends (since this doesn&#39;t reveal your internal key).<br><br>If this=
 approach gains acceptance I think the main immediate action users can take=
 is to move to a taproot wallet. I predict trying to advise people to move =
to p2pkh addresses or that p2pkh addresses are &quot;fine&quot; will create=
 confusion since there are huge numbers of coins in p2pkh addresses whose p=
ublic key has already been revealed and people may do address reuse without=
 knowing it.<br>Also an attractive approach is to embed the QR signature sc=
heme in a tapleaf before activating it so that most coins already have a QR=
 spending path ready to go. This is more straightforward if taproot is norm=
alized first.<br>I understand that people might feel &quot;less protected&q=
uot; on a taproot address because they might get sniped by the QC attacker =
before the freezing fork has been activated but I don&#39;t think this is a=
 serious concern relative to the millions of coins available with known pub=
lic keys. We have to freeze it before they can be taken.<br><br>So outside =
of cryptography, the difficult task is to come to a social consensus mechan=
ism about when to trigger the freezing soft fork. It should be done *before=
* a secp256k1 DLOG QC can be built but *after* we know that one can be buil=
t. Right now it is certainly not clear that one *can* be built ever and we =
won&#39;t have any indication this decade and maybe the next. It may be a m=
atter of debate whether we&#39;ve reached that point in 10 years (it certai=
nly isn&#39;t now) and you can imagine malicious actors trying to subvert t=
he process either to hold it back or to push it forward.<br><br>LL</div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 1=
7 Mar 2025 at 05:31, Martin Habov=C5=A1tiak &lt;<a href=3D"mailto:martin.ha=
bovstiak@gmail.com" target=3D"_blank">martin.habovstiak@gmail.com</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"auto">Hello list,<div dir=3D"auto"><br></div><div dir=3D"auto">this is =
somewhat related to Jameson&#39;s recent post but different enough to warra=
nt a separate topic.</div><div dir=3D"auto"><br></div><div dir=3D"auto">As =
you have probably heard many times and even think yourself, &quot;hashed ke=
ys are not actually secure, because a quantum attacker can just snatch them=
 from mempool&quot;. However this is not strictly true.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">It is possible to implement fully secure re=
covery if we forbid spending of hashed keys unless done through the followi=
ng scheme:</div><div dir=3D"auto">0. we assume we have *some* QR signing de=
ployed, it can be done even after QC becomes viable (though not without eco=
nomic cost)</div><div dir=3D"auto">1. the user obtains a small amount of bi=
tcoin sufficient to pay for fees via external means, held on a QR script</d=
iv><div dir=3D"auto">2. the user creates a transaction that, aside from hav=
ing a usual spendable output also commits to a signature of QR public key. =
This proves that the user knew the private key even though the public key w=
asn&#39;t revealed yet.</div><div dir=3D"auto">3. after sufficient number o=
f blocks, the user spends both the old and QR output in a single transactio=
n. Spending requires revealing the previously-committed sigature. Spending =
the old output alone is invalid.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">This way, the attacker would have to revert the chain to steal wh=
ich is assumed impossible.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">The only weakness I see is that (x)pubs would effectively become private=
 keys. However they already kinda are - one needs to protect xpubs for priv=
acy and to avoid the risk of getting marked as &quot;dirty&quot; by some ag=
encies, which can theoretically render them unspendable. And non-x-pubs gen=
erally do not leak alone (no reason to reveal them without spending).</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">I think that the mere possibi=
lity of this scheme has two important implications:</div><div dir=3D"auto">=
* the need to have &quot;a QR scheme&quot; ready now in case of a QC coming=
 tomorrow is much smaller than previously thought. Yes, doing it too late h=
as the effect of temporarily freezing coins which is costly and we don&#39;=
t want that but it&#39;s not nearly as bad as theft</div><div dir=3D"auto">=
* freezing of *these* coins would be both immoral and extremely dangerous f=
or reputation of Bitcoin (no comments on freezing coins with revealed pubke=
ys, I haven&#39;t made my mind yet)</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">If the time comes I&#39;d be happy to run a soft fork that impl=
ements this sanely.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Chee=
rs</div><div dir=3D"auto"><br></div><div dir=3D"auto">Martin</div></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" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gma=
il.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https:=
//groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-byGOjME3J=
t2DRr20yZqMmdJUnQ%40mail.gmail.com</a>.<br>
</blockquote></div>
</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/CAH5Bsr3Yx1n22svy7QCTkT_BdzxLUqSmaR6Ji%2Bv7Zf4Pph9S7w%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAH5Bsr3Yx1n22svy7QCTkT_BdzxLUqSmaR6Ji%2Bv7Zf4Pph9S7w%40ma=
il.gmail.com</a>.<br />

--0000000000005523640630877aec--