Delivery-date: Mon, 17 Mar 2025 06:37:08 -0700
Sender: bitcoindev@googlegroups.com
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;
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
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--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=
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--