From: Lloyd Fournier <lloyd.fourn@gmail•com>
To: "Martin Habovštiak" <martin.habovstiak@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Hashed keys are actually fully quantum secure
Date: Mon, 17 Mar 2025 21:44:23 +1100 [thread overview]
Message-ID: <CAH5Bsr3Yx1n22svy7QCTkT_BdzxLUqSmaR6Ji+v7Zf4Pph9S7w@mail.gmail.com> (raw)
In-Reply-To: <CALkkCJY=dv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5695 bytes --]
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štiak <martin.habovstiak@gmail•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 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 proves
> 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 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 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-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAH5Bsr3Yx1n22svy7QCTkT_BdzxLUqSmaR6Ji%2Bv7Zf4Pph9S7w%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6942 bytes --]
next prev parent reply other threads:[~2025-03-17 13:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-16 18:25 Martin Habovštiak
2025-03-16 18:50 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-16 19:03 ` Agustin Cruz
2025-03-16 20:52 ` Martin Habovštiak
2025-03-17 10:44 ` Lloyd Fournier [this message]
2025-03-17 11:07 ` Martin Habovštiak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH5Bsr3Yx1n22svy7QCTkT_BdzxLUqSmaR6Ji+v7Zf4Pph9S7w@mail.gmail.com \
--to=lloyd.fourn@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=martin.habovstiak@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox