diff options
| author | Lloyd Fournier <lloyd.fourn@gmail.com> | 2025-03-17 21:44:23 +1100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-03-17 06:36:27 -0700 |
| commit | 22428e897f6a5f9ccce76e86ec910460b28cd565 (patch) | |
| tree | dd0f0e097b6a70621eb1de8b72be52cc0b663e79 | |
| parent | 41d499ca29495562496daf92b5eb1749e6202d80 (diff) | |
| download | pi-bitcoindev-22428e897f6a5f9ccce76e86ec910460b28cd565.tar.gz pi-bitcoindev-22428e897f6a5f9ccce76e86ec910460b28cd565.zip | |
Re: [bitcoindev] Hashed keys are actually fully quantum secure
| -rw-r--r-- | a2/a9878dd4c63b520dc4f15cd51e51d31d323071 | 400 |
1 files changed, 400 insertions, 0 deletions
diff --git a/a2/a9878dd4c63b520dc4f15cd51e51d31d323071 b/a2/a9878dd4c63b520dc4f15cd51e51d31d323071 new file mode 100644 index 000000000..e685c695c --- /dev/null +++ b/a2/a9878dd4c63b520dc4f15cd51e51d31d323071 @@ -0,0 +1,400 @@ +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 "hashed keys" 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't have to worry about whether you'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'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 "fine" 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 "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'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't have any indication this decade and maybe the next. It may be a m= +atter of debate whether we've reached that point in 10 years (it certai= +nly isn'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 <<a href=3D"mailto:martin.ha= +bovstiak@gmail.com" target=3D"_blank">martin.habovstiak@gmail.com</a>> 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'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, "hashed ke= +ys are not actually secure, because a quantum attacker can just snatch them= + from mempool". 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'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 "dirty" 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 "a QR scheme" 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'= +t want that but it'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't made my mind yet)</div><div dir=3D"auto"><br></div><div d= +ir=3D"auto">If the time comes I'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" 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&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" 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-- + |