path: root/84/1ebb75ad43aa4edcc5de291ea5265cfd277505

Delivery-date: Mon, 17 Mar 2025 06:37:08 -0700
Received: from mail-yb1-f191.google.com ([209.85.219.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+bncBDZPZFXW2IMRB6WK4C7AMGQE7HSIPXY@googlegroups.com>)
	id 1tuAeR-0003s9-Jk
	for bitcoindev@gnusha.org; Mon, 17 Mar 2025 06:37:08 -0700
Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e639763e43dsf5986463276.0
        for <bitcoindev@gnusha.org>; Mon, 17 Mar 2025 06:37:07 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1742218622; cv=pass;
        d=google.com; s=arc-20240605;
        b=KyZW5X3wsnkCd5QsVxXCgFJ97Bvf4Xw4cU0NpSpCWw308cyH8OpH8ZdMHIZXaaaXsu
         rG2SpX39o0fuK8weKIxXt1hymY9QYZ4rwy8H3s2QKBEIsoLUpWTv2f/m0RvgRsJLR/Yn
         i8NfFoO5vof8hLj40BM3v9zJhWE104+QxLx5RwBsiytsivFpPpg8od3YG0cM+FaELINw
         2SX/EcxQvWlKR8SRzHItWxZgFdjZXElEQf7D1XOt8M8xEM64DPnc4ob0Cnf6ZGUhdaL5
         h1RqtQXg5MtkCClNZKYblovzNU1cnWgP2vrLNjznPM5vUi6FO1bAqA3u1KOJppyCGVyt
         P3/w==
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=14Br5llbkZ0O918uzVynKQB8x+GkNEcugu71l4szNoM=;
        fh=+OcHUEy2DVdd7UxKaxFcGMN7Jvlu/XG7+GQh4daHSHo=;
        b=KY4Wmv2yhsWDmK9TMxqUT3iv67y3AOIot/rVoJI15SujBx3C8ou4NvgVhayUdA19gQ
         9QT4PIjU+jMQHwf2X0Acc4dVQ32KtFslQ/FYfSZ3ZC8EBp7uhHl2aGk2AWZ3kpXHDatQ
         5exTECGC2/qhYFSl3y5bjxqFsKRr39mesCfrlT4n5XH2bcN91/knnyPgM6x/TXOKsccI
         E1EWEd7O2NA4ibx5lpjWG1ZgLNoUu97u6om3y4o17sh4aK/pS2mQvB/ywgu4Yd3gTvOu
         cTl3363LVPLVBnDumkSj+6YfDVLn1M9a5UbNYN7dEyfxl5JINTEjZvDz59iMvoFp5H2O
         LnUw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=LUOjk998;
       spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::934 as permitted sender) smtp.mailfrom=martin.habovstiak@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=1742218622; x=1742823422; 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=14Br5llbkZ0O918uzVynKQB8x+GkNEcugu71l4szNoM=;
        b=FZeYjA/pwRAmZ7AV40Z6oexj5z9LMdQLqSk3QRXeGf74TYHtE2lS7L/lqMfOLycHY/
         G4D9PdL0SCC9oZ4W7DGA5rI0IlIqY6iFpwE37Xr4BLp892at7TKjZmv3NtFcvyuhBBVp
         Bee82oCe9eSSxiK764AqVFfNlooLT0JER739VHWAwO/n3GfoyiXN1eehh0EQgzXU7kuZ
         wG3XITDu0ziMqxQmOOkYbdtkUkFjVsIykAhmbye1rMI0A+e1LekXxb+ppQnbgoB+pu6i
         5DZ/uET3SVpYkxeP6CnmRMdG+B7Bi1pQGok/9Vrdteuo0jIWbI/zqOPtqU+hSae2gp25
         UopQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1742218622; x=1742823422; 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=14Br5llbkZ0O918uzVynKQB8x+GkNEcugu71l4szNoM=;
        b=HwSUDb2xMSe7s9ibV62FxgNUJhuCkXDrU++iaxHwbRP4oz9h5hYuAkokZ/k2WItpFs
         MRfk7qWpAbaSuGA0YuXSdRoZNtP+tdc0uzfo/kj+wYzaK1tnUVLnWeOd1K/wC5PhJOk5
         BorcG/4VjKzQoWAz35zGd/xWXfnXIH8KwPh2K0sRh8pp7tR64rSBwlNzDsX37FQF1sYY
         f0Bz2dnZwY/1RY9Uf3U277VBgkfQxl7uKvRp3787nUhDfT5pIyK9tRmUV1xPCJHRUHf3
         EdQyMv/Le6F539KDzFUoK2O6SwyX4742mO+6DTaVYcOL9IcFO5562Kb37q3MNxkQEsga
         8rSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1742218622; x=1742823422;
        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=14Br5llbkZ0O918uzVynKQB8x+GkNEcugu71l4szNoM=;
        b=EcdPwTi0sGmdY87uzf6I3E3ckAb3QZ24tgiISVtEzmKLxbPYSlkyaB/VVQDa4mgMyR
         Qa5ui/iJ+3kDZeyMEhfSPWocnOdz+ywSww6YTiCLP0s+lydj7ZBcIB2lD78cGOXGO58S
         yFf2JuansydFiYX6H/LC2KYGeZhHVARBixxcKSd0/tXoMMMo6F3qNGgztspO72wLY0EI
         r1ZclPEfcGfeXRtOpv6ttqgssOTyql36NkB5G6ZkDUHFErXWRzv+gtNlqUNE0FxwB4vg
         dY3WcC6Lkgp9K1ugmKUCJv+2+SQ014G9v2FMhvD3+cfr+lcrdgTosRQP5u/oZmio+TWZ
         2xCw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXGbHRVUUdoiGe0apPYGddRrO/RQBK49q/JOsBOVzTWKfyqPouXu8yibAaqPyNRgghNXDTMa/b5OGNd@gnusha.org
X-Gm-Message-State: AOJu0YzsOBStjF++zzURTJ35WV3nmMXZ+uFpj+B9VSkTuN8Ck5b+5O30
	uGYlLvNqhaRzzj4O0Hg99HZqvnsbX7Rko0UJpPeTsGqgdkNkgcvF
X-Google-Smtp-Source: AGHT+IHbNLwz7j0kgIakgwnZ7FGpwJqxMtnQLefPKbBbERgXyktO9t+YOahlSWlhciyhv+onxuCPNA==
X-Received: by 2002:a05:6902:250b:b0:e60:ad8f:365d with SMTP id 3f1490d57ef6-e63f64d451dmr14670429276.4.1742218621860;
        Mon, 17 Mar 2025 06:37:01 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAKFIDzLZLnjT1Y3TQT+3eCMQk31E2XGNjGQKM14SZ+KxQ==
Received: by 2002:a25:7c1:0:b0:e5d:c536:1cba with SMTP id 3f1490d57ef6-e63dc2b4454ls554018276.1.-pod-prod-02-us;
 Mon, 17 Mar 2025 06:36:58 -0700 (PDT)
X-Received: by 2002:a05:690c:6706:b0:6fb:8461:e828 with SMTP id 00721157ae682-6ff4606f710mr159482477b3.30.1742218618268;
        Mon, 17 Mar 2025 06:36:58 -0700 (PDT)
Received: by 2002:a05:690c:9a89:b0:6ef:590d:3213 with SMTP id 00721157ae682-6ff4514f72dms7b3;
        Mon, 17 Mar 2025 04:07:22 -0700 (PDT)
X-Received: by 2002:a05:690c:6309:b0:6fb:9822:bbd7 with SMTP id 00721157ae682-6ff45f456cfmr165000697b3.15.1742209641459;
        Mon, 17 Mar 2025 04:07:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1742209641; cv=none;
        d=google.com; s=arc-20240605;
        b=JiieXjhvhTzz+JtZys39nDdb1SRfHr0cAdyWkqgKM+6HAkC5OqxWu2TARQzfGpMsgA
         O3WysFjiOo5R1dGMycJbpKUVEnFPoLpuC1vgw27ZLemMPSxSjQuTOxGlYtTSgbiPrDga
         kjZKw6tKNG9hhRXiWYL1X7uZVeDLfqhWHfg1o9NsvRGVnG3nGcM6dnxUEkPokp/ochUt
         yznm7cXqc66ZfPG06DNGveZG9cz/hBAGyLh72YbSYrH28+y9CiMuRERdfRkhHwftGjl+
         kwGZFRChCVu4X3zutXBdINKp4v8ujbC3fnXxusOWMAi9BQNtM3+aaPwpGN1UJcASlRHG
         fLGQ==
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=GVSX1H1RcBmRpKyRY3OPLRq7NqhNqS54POhl5FSDCQc=;
        fh=aUZ7bSjBZKWdoOP5d1LfAhATqHpcKrUsP9dphkUVJGg=;
        b=SzuwtcI0B/N8PphXpGsKdNvTLEcrBbJF+sCm9UF8F1TxxUNVhz6D2ld/ASZbOVssPK
         V1ncup2xrreTXxQs2lPt7ogjO/cjyMG53mGoDTbqh5SX3CORN57e9bsHfu/wgRAc3TEQ
         BP4lbYF5fftfswcTSnIcgnBFZm5IcuAI6NAeKS7YuIQE4ZFEMBQc3j4jeVrphbEjxD3K
         BegwrRnEc3xJTGO7zJFKp795k/wVUc/ZF/j/DC52vZEWKQKAYjZRaRPpYLKYhX4HWw6a
         uxTXa0v48fEMpIDlGM70odNEvfbC3fT8zRH5Dy5V19j3KrlEiqj4+UKGNRM4anMQdbpy
         zkDg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=LUOjk998;
       spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::934 as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com. [2607:f8b0:4864:20::934])
        by gmr-mx.google.com with ESMTPS id 00721157ae682-6ff49d483d2si4544787b3.4.2025.03.17.04.07.21
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 17 Mar 2025 04:07:21 -0700 (PDT)
Received-SPF: pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::934 as permitted sender) client-ip=2607:f8b0:4864:20::934;
Received: by mail-ua1-x934.google.com with SMTP id a1e0cc1a2514c-86d2fba8647so3955230241.0
        for <bitcoindev@googlegroups.com>; Mon, 17 Mar 2025 04:07:21 -0700 (PDT)
X-Gm-Gg: ASbGncue1PAmrD8AxsT8F9seuVr6gsYLx1eOAk9EgbyCQbTBzX83+Uv7cS6j0e7Onk/
	TJ1vnvwbik/AN09+O4NxcM6t4H5RoxK7330VuM+Wg6lnfl2x08UmCzrxmqS77EfwbPQ+S2Jq3lR
	qM+gqs+TvPZGWFNop4DnvyYqaiOA==
X-Received: by 2002:a05:6102:c05:b0:4bb:c8e5:aa6d with SMTP id
 ada2fe7eead31-4c3831f6925mr7490381137.17.1742209640964; Mon, 17 Mar 2025
 04:07:20 -0700 (PDT)
MIME-Version: 1.0
References: <CALkkCJY=dv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ@mail.gmail.com>
 <CAH5Bsr3Yx1n22svy7QCTkT_BdzxLUqSmaR6Ji+v7Zf4Pph9S7w@mail.gmail.com>
In-Reply-To: <CAH5Bsr3Yx1n22svy7QCTkT_BdzxLUqSmaR6Ji+v7Zf4Pph9S7w@mail.gmail.com>
From: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= <martin.habovstiak@gmail.com>
Date: Mon, 17 Mar 2025 12:07:11 +0100
X-Gm-Features: AQ5f1Jp-lswKgGbEG8mS3IYgrMozk_TqLOwOvv6eTQ387B2d22TyKhlqsknairE
Message-ID: <CALkkCJZ3TBEfRYBHVv_NON18mqbsQixgUEtgGThau4D=W6gdGg@mail.gmail.com>
Subject: Re: [bitcoindev] Hashed keys are actually fully quantum secure
To: Lloyd Fournier <lloyd.fourn@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000c62a91063087ca53"
X-Original-Sender: martin.habovstiak@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=LUOjk998;       spf=pass
 (google.com: domain of martin.habovstiak@gmail.com designates
 2607:f8b0:4864:20::934 as permitted sender) smtp.mailfrom=martin.habovstiak@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 (/)

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

Oh, great point that while the hashing in Taproot disallows spending when
null tweak is used, it's still usable to produce a proof similar to what I
suggested. Also very interesting point about address reuse being "fine"
with taproot.

I believe the QR signature scheme in tapleaf was already suggested but that
has the problem that the scheme needs to be specified in advance. IIUC it's
not currently clear which even is reasonable. My idea gives us more time to
figure that out.

However, I do not think that Taproot is generally safer than p2*pkh.
Comparing to millions lost coins is not valid, since those at worst
decrease the price of bitcoin but economically wouldn't set it to literal
zero, thus the value of one's coins just decreases, while getting stolen
from means the value of one's coins goes to literal zero.

The difference wrt safety thus relies on how well one is able to avoid
address reuse. Some people can avoid it completely, some can't.

The social aspect is indeed messy.

D=C5=88a po 17. 3. 2025, 11:44 Lloyd Fournier <lloyd.fourn@gmail.com> nap=
=C3=ADsal(a):

> 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 spen=
d
> 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 peopl=
e
> 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 spendin=
g
> 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 t=
o
> 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 shou=
ld
> be done *before* a secp256k1 DLOG QC can be built but *after* we know tha=
t
> 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 nex=
t.
> 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@gmail.com> wrote:
>
>> Hello list,
>>
>> this is somewhat related to Jameson's recent post but different enough t=
o
>> 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
>> of hashed keys unless done through the following scheme:
>> 0. we assume we have *some* QR signing deployed, it can be done even
>> 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
>> spendable output also commits to a signature of QR public key. This prov=
es
>> 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 Q=
R
>> 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-pub=
s
>> 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
>> tomorrow 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 dangerou=
s
>> 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 Group=
s
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-=
byGOjME3Jt2DRr20yZqMmdJUnQ%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/=
CALkkCJZ3TBEfRYBHVv_NON18mqbsQixgUEtgGThau4D%3DW6gdGg%40mail.gmail.com.

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

<div dir=3D"auto">Oh, great point that while the hashing in Taproot disallo=
ws spending when null tweak is used, it&#39;s still usable to produce a pro=
of similar to what I suggested. Also very interesting point about address r=
euse being &quot;fine&quot; with taproot.<div dir=3D"auto"><br></div><div d=
ir=3D"auto">I believe the QR signature scheme in tapleaf was already sugges=
ted but that has the problem that the scheme needs to be specified in advan=
ce. IIUC it&#39;s not currently clear which even is reasonable. My idea giv=
es us more time to figure that out.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">However, I do not think that Taproot is generally safer than p2=
*pkh. Comparing to millions lost coins is not valid, since those at worst d=
ecrease the price of bitcoin but economically wouldn&#39;t set it to litera=
l zero, thus the value of one&#39;s coins just decreases, while getting sto=
len from means the value of one&#39;s coins goes to literal zero.</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">The difference wrt safety thus re=
lies on how well one is able to avoid address reuse. Some people can avoid =
it completely, some can&#39;t.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">The social aspect is indeed messy.</div></div><br><div class=3D"gmai=
l_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">D=C5=
=88a po 17. 3. 2025, 11:44 Lloyd Fournier &lt;<a href=3D"mailto:lloyd.fourn=
@gmail.com">lloyd.fourn@gmail.com</a>&gt; nap=C3=ADsal(a):<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">This seems like a=
 very clever idea. It allows us to mostly ignore the QC question until a th=
reat actually materializes and then soft fork to disallow bare public key s=
pending with minimal actions needed to be taken by users. Nice work!<br><br=
>A couple of important points:<br>- Taproot keys are also &quot;hashed keys=
&quot; 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 i=
nternal key to produce the commitment signature.<br>- Taproot keys are actu=
ally better hashed keys since you don&#39;t have to worry about whether you=
&#39;ve revealed your public key on-chain in the past e.g. via address re-u=
se if you use external key spends (since this doesn&#39;t reveal your inter=
nal key).<br><br>If this approach gains acceptance I think the main immedia=
te action users can take is to move to a taproot wallet. I predict trying t=
o advise people to move to p2pkh addresses or that p2pkh addresses are &quo=
t;fine&quot; 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.<br>Also an attractive approach is to e=
mbed 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 straightfo=
rward if taproot is normalized first.<br>I understand that people might fee=
l &quot;less protected&quot; on a taproot address because they might get sn=
iped by the QC attacker before the freezing fork has been activated but I d=
on&#39;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 t=
aken.<br><br>So outside of cryptography, the difficult task is to come to a=
 social consensus mechanism about when to trigger the freezing soft fork. I=
t should be done *before* a secp256k1 DLOG QC can be built but *after* we k=
now that one can be built. Right now it is certainly not clear that one *ca=
n* be built ever and we won&#39;t have any indication this decade and maybe=
 the next. It may be a matter of debate whether we&#39;ve reached that poin=
t in 10 years (it certainly isn&#39;t now) and you can imagine malicious ac=
tors trying to subvert the process either to hold it back or to push it for=
ward.<br><br>LL</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Mon, 17 Mar 2025 at 05:31, Martin Habov=C5=A1tiak &lt;<a=
 href=3D"mailto:martin.habovstiak@gmail.com" target=3D"_blank" rel=3D"noref=
errer">martin.habovstiak@gmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(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 warrant a separate topic.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">As you have probably heard many time=
s and even think yourself, &quot;hashed keys are not actually secure, becau=
se a quantum attacker can just snatch them from mempool&quot;. However this=
 is not strictly true.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I=
t is possible to implement fully secure recovery if we forbid spending of h=
ashed keys unless done through the following scheme:</div><div dir=3D"auto"=
>0. we assume we have *some* QR signing deployed, it can be done even after=
 QC becomes viable (though not without economic cost)</div><div dir=3D"auto=
">1. the user obtains a small amount of bitcoin sufficient to pay for fees =
via external means, held on a QR script</div><div dir=3D"auto">2. the user =
creates a transaction that, aside from having a usual spendable output also=
 commits to a signature of QR public key. This proves that the user knew th=
e private key even though the public key wasn&#39;t revealed yet.</div><div=
 dir=3D"auto">3. after sufficient number of blocks, the user spends both th=
e old and QR output in a single transaction. Spending requires revealing th=
e 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 w=
ould have to revert the chain to steal which is assumed impossible.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">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 getti=
ng marked as &quot;dirty&quot; by some agencies, which can theoretically re=
nder them unspendable. And non-x-pubs generally do not leak alone (no reaso=
n to reveal them without spending).</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">I think that the mere possibility of this scheme has two import=
ant implications:</div><div dir=3D"auto">* the need to have &quot;a QR sche=
me&quot; ready now in case of a QC coming tomorrow is much smaller than pre=
viously thought. Yes, doing it too late has the effect of temporarily freez=
ing coins which is costly and we don&#39;t want that but it&#39;s not nearl=
y as bad as theft</div><div dir=3D"auto">* freezing of *these* coins would =
be both immoral and extremely dangerous for reputation of Bitcoin (no comme=
nts on freezing coins with revealed pubkeys, I haven&#39;t made my mind yet=
)</div><div dir=3D"auto"><br></div><div dir=3D"auto">If the time comes I&#3=
9;d be happy to run a soft fork that implements this sanely.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Cheers</div><div dir=3D"auto"><br></d=
iv><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" rel=3D"noreferrer">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" rel=3D=
"noreferrer">https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_=
HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com</a>.<br>
</blockquote></div>
</div>
</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/CALkkCJZ3TBEfRYBHVv_NON18mqbsQixgUEtgGThau4D%3DW6gdGg%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CALkkCJZ3TBEfRYBHVv_NON18mqbsQixgUEtgGThau4D%3DW6gdGg%40ma=
il.gmail.com</a>.<br />

--000000000000c62a91063087ca53--