Subject: Re: [bitcoindev] Hashed keys are actually fully quantum secure

From: "'conduition' via Bitcoin Development Mailing List" <[email-masked]>
Date: Sun, 25 May 2025 18:22:47 +0000

Hey friends,

Even if we can require a pre-quantum output to be paired with
a QR output when spending in this way, and even if the QR output
must be at least X blocks old... What prevents an attacker from
just pre-minting a whole bunch of QR outputs, aging them for a while,
and then lying in wait to steal?

A well-prepared QC attacker's QR outputs may even be significantly
older than an honest user's QR outputs. An aged QR output committing
to a QR signature proves nothing about the ownership of an unrelated
pre-quantum UTXO.

The QR output must prove historical ownership of the vulnerable
EC key-hashed output. To fix this, we must change this line in OP:

> 2. the user creates a transaction that, aside from having a usual
> spendable output also commits to a signature of QR public key.

This transaction must be fully protected by QR signing. It must
commit to, but not reveal, the EC public key, while also proving
ownership. I would correct this description to:

> 2. the user creates a transaction with at least one QR input which,
> aside from having a usual spendable output also commits to
> *a signature from the legacy EC pubkey.*

This TX might have an OP_RETURN output or an inscription which embeds 

SHA256(ec_signature).  Or, like taproot, the QR output script might
itself contain a hidden commitment to that hash. 

A few blocks after this transaction is mined, the honest user can
spend the QR and legacy UTXOs together, opening the EC signature
commitment. Validating nodes would have to check the QR output is
old enough, but also check that it committed to the correct
pubkey+signature.

A QC attacker shouldn't be able to break this unless the legacy EC
pubkey has already been revealed prior to the commitment TX.
Only the authentic user could've pre-committed to that signature.
If we assume the QC attacker can't roll-back the chain more than
X blocks, they can't go back and insert an EC sig commitment
retroactively.

I suspect this might've been Martin's intent, judging from the way he
was writing?

regards,
conduition

On Sunday, March 23rd, 2025 at 8:24 PM, Lloyd Fournier <[email-masked]> wrote:

> On Tue, 18 Mar 2025 at 00:48, 'Antoine Poinsot' via Bitcoin Development Mailing List <[email-masked]> wrote:
> 

> > I suppose you could in theory have, in addition to making spending old outputs invalid on their own, a rule which dictates they may only be spent along with a QR output at least X blocks old. This would give the honest user a headstart in this race, but meh.
> 

> Yes this is how I read the OP "after sufficient number of blocks". I think this is a really nice idea. The head start can be arbitrarily large so that the attacker simply cannot compete. It's probably not too difficult to design some honest RBF mechanism either such that you can bump the fee with a new QR signature if it's taking too long.
> 

> LL

> > On Sunday, March 16th, 2025 at 2:25 PM, Martin Habovštiak <[email-masked]> 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 [email-masked].
> > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com.
> > 

> > --
> > 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 [email-masked].
> > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/XHIL8Z4i4hji8LhbJ0AiKQ4eago2evXwjTGUOqqyAye_2nM3QicDpHo6KkcznBAHPUrIWSLj_GuiTQ_97KPjxcOrG8pE0rgcXucK2-4txKE%3D%40protonmail.com.
> 

> --
> 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 [email-masked].
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAH5Bsr0muoF27besnoQh32vL-keujeR%2Bd-_JurE0%2ByXY5gPKQg%40mail.gmail.com.

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Rgj4DeSKQkdEWMRTmqYYLas84WIDyRftEKqmwlw0C9-ur4Tx9_d6g7SzTU_WBspYbezLDTMpgIFXon1_cpFSjgYOMtHlQJNS_utF2dZQ4ig%3D%40proton.me.