From: Jason Resch <jasonresch@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal
Date: Tue, 19 May 2026 11:11:14 -0700 (PDT) [thread overview]
Message-ID: <8d22c782-6da1-46f3-aa12-f686d5e1746dn@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2891 bytes --]
Dear Bitcoin Developers,
I've been thinking about the threat of quantum computers to ECDSA, and I
had an idea that I consider to be valuable and worth sharing with the
broader community.
The essential idea is that rather than attempt to choose any one
post-quantum-secure algorithm as a replacement, instead, bitcoin ought to
support a set of various algorithms, and let end-users decide which one
algorithm or combination of algorithms, best fits with their use-case,
security requirements, and trust for different algorithms. In short:
- A wallet chooses one or more public keys from one or more approved
signature algorithms.
- This ordered public-key bundle is serialized canonically and hashed to
form the address.
- Senders do not need to know which algorithm or algorithms are behind
the address.
- At spend time, the spender reveals the public-key bundle and provides
one valid signature for each key in the bundle.
- Users who want higher assurance can use heterogeneous algorithm
families, while users with lower-value or high-frequency wallets can choose
cheaper single-algorithm profiles.
This agile approach, inspired by TLS, SSH, and IPSec (all of which support
multiple suites of different algorithms) has many advantages:
1. It defers the decision of which algorithm to use and trust to the
future, when there will be more information available. Bitcoin developers
can't predict what future algorithm breaks might happen, and enabling users
to decide absolves Bitcoin developers of having to try to predict the
future.
2. It enables rapid migration to other algorithms, should any future
cryptographic break or even suspicious of possible future breaks, occur in
the future, without having to wait for a new consensus for a change to the
Bitcoin software and protocol.
3. End users can choose security levels that correspond to their
security needs and spending habits. Have a cold-wallet securing millions of
bitcoin which you spend from once per decade? Use several PSQ algorithm
families with large key sizes, and pay higher transaction fees for those
rare occasions you move funds. Have a small spending wallet you use to make
online purchases? Use the smallest key size possible to save on transaction
fees.
I have put together a white paper that offers some further detail on how
this could work: https://zenodo.org/records/20292912 and welcome any
comments/feedback.
Jason
--
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/8d22c782-6da1-46f3-aa12-f686d5e1746dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3241 bytes --]
next reply other threads:[~2026-05-19 18:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 18:11 Jason Resch [this message]
2026-05-19 19:31 ` [bitcoindev] A "Quantum-Agile" Bitcoin address proposal Pieter Wuille
2026-05-20 3:10 ` Jason Resch
2026-05-20 13:02 ` Pieter Wuille
2026-05-20 14:20 ` Jason Resch
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=8d22c782-6da1-46f3-aa12-f686d5e1746dn@googlegroups.com \
--to=jasonresch@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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