From: "Martin Habovštiak" <martin.habovstiak@gmail•com>
To: Agustin Cruz <agustin.cruz@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Hashed keys are actually fully quantum secure
Date: Sun, 16 Mar 2025 21:52:47 +0100 [thread overview]
Message-ID: <CALkkCJZ6cT=9kq+=mSmkgFY+6x3zxTwo196crOOxTkFWq8w3vw@mail.gmail.com> (raw)
In-Reply-To: <CAJDmzYw-Z2nB3BvSnuCT2OF+ahd-kbVrYauM_cZgmDytPYVfpA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6183 bytes --]
Antoine, "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."
yes, this is what I meant but also the QR output must contain the
commitment. This rule makes it not "a race". The attacker cannot make the
commitment before knowing the private key and cannot reverse deep chain.
Augustin, you understand it correctly. Sadly, the dilemma is only mitigated
for hashed keys, not revealed ones.
1. we would presumably bump segwit version, so we can do whatever we like.
I assume it'd be something similar to today's Annex but there are likely
more ways to do it with their pros and cons. I don't think these details
matter much today. But it's certainly possible.
2. of course, soft fork would be required but it will be anyway to deploy a
QR signing algo. And I don't think anything saving coins from certain loss
will be contentious. :)
The changes would need to identify inputs using secp256k1 verification and
look up the commitments in the other inputs. Also they'd need to check how
deep the spent inputs are.
Dňa ne 16. 3. 2025, 20:03 Agustin Cruz <agustin.cruz@gmail•com> napísal(a):
> Hi Martin,
>
> Your approach of using a committed QR signature to “anchor” the spending
> of hashed keys is intriguing. If I understand correctly, the idea is:
> - A user commits to a QR signature in a first transaction (Tx1), proving
> ownership of the QR private key without exposing vulnerable data.
> - Later, they spend both the old P2PKH output and the QR output together
> (Tx2), revealing the QR signature, with rules ensuring the old output can’t
> be spent independently.
> - This forces an attacker to either forge a QR signature (infeasible with
> a quantum-resistant scheme) or rewind the chain past Tx1’s confirmation
> (infeasible with sufficient depth).
>
> This seems to provide a solid defense against quantum theft, assuming the
> QR scheme holds up and the blockchain remains secure. I also like how it
> mitigates the “theft vs. freeze” dilemma. Temporary freezing is indeed less
> catastrophic than permanent loss, and avoiding reputational damage is
> crucial.
>
> To better understand how this would work, I have two questions:
>
> 1. How would the QR signature commitment be encoded and verified in the
> script?. Would this require new opcodes or script functionality to check
> the commitment when spending?
>
> 2. How would you enforce that the old P2PKH output can only be spent with
> the QR output? Would this need a soft fork, and if so, what consensus
> changes would be required?
>
> Regards,
> Agustín
>
> El dom, 16 de mar de 2025, 3:31 p. m., Martin Habovštiak <
> martin.habovstiak@gmail•com> escribió:
>
>> 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/CALkkCJZ6cT%3D9kq%2B%3DmSmkgFY%2B6x3zxTwo196crOOxTkFWq8w3vw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7903 bytes --]
next prev parent reply other threads:[~2025-03-17 13:37 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 [this message]
2025-03-17 10:44 ` Lloyd Fournier
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='CALkkCJZ6cT=9kq+=mSmkgFY+6x3zxTwo196crOOxTkFWq8w3vw@mail.gmail.com' \
--to=martin.habovstiak@gmail$(echo .)com \
--cc=agustin.cruz@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.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