From: Jason Resch <jasonresch@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal
Date: Wed, 20 May 2026 10:20:10 -0400 [thread overview]
Message-ID: <CA+BCJUjN9=prte7_Gfj_j8=2zSPfUQVQDm04aatyT7UAZp5i3A@mail.gmail.com> (raw)
In-Reply-To: <VYtAQB0c0TAb_GQlnazB1OE9rtZDe8FsrAOg5YU7R6rZ8Etho2eg5gVJ0kxnwt9Qpln0FxTU3BJsuwKFqjZOEz15HrF5UwoAxY-G8iIyXxU=@wuille.net>
[-- Attachment #1: Type: text/plain, Size: 9298 bytes --]
On Wed, May 20, 2026, 9:02 AM Pieter Wuille <bitcoin-dev@wuille.net> wrote:
> Hi Jason,
>
> See my comments below.
>
> On Tuesday, May 19th, 2026 at 11:27 PM, Jason Resch <jasonresch@gmail.com>
> wrote:
>
>
> On Tue, May 19, 2026 at 3:31 PM Pieter Wuille <bitcoin-dev@wuille.net>
> wrote:
>
>> Hi Jason,
>>
>> I think that in technical terms, this is how many people already think
>> about PQC adoption. Most proposals (including P2MR and P2TRv2) are built on
>> the script merkle tree construction introduced in Taproot. By having
>> multiple leaves in the tree, with distinct PQC (or EC) keys/opcodes in
>> each, it is possible to have multiple schemes in parallel.
>>
>
> Thank you for pointing out these alternatives to me. Is it correct that
> the script Merkle tree would have the additional overhead of: script
> opcodes, the script itself, the control block, and 32 bytes for each step
> in the Merkle path?
>
> In the proposal I shared, the only overhead (beyond the public key(s) +
> signature(s) inherent to both) would be only a few bytes of metadata for
> algorithm specification (which seems necessary in any multi-algorithm
> implementation). So while the script tree offers more general flexibility,
> it may be overkill compared to a more basic built-in support for
> multi-algorithm signatures.
>
>
> I do not believe that is correct. As I understand it, your proposal
> requires revealing *all* public keys (across all schemes) at spend time,
> because the hash in the address commits to their concatenation. Merkle
> script tree based solutions only require revealing the actually signed-with
> public key type, plus a logarithmic number of 32-byte Merkle steps for the
> other public key types. The other costs are either marginal or common
> between approaches. In Merkle script trees approaches, only one script is
> revealed, and (in the single-user setting which you seem to be talked
> about) consists of just a public key + an opcode. The 64-byte control block
> is unique to Taproot, but orthogonal; P2MR does not have it for example. It
> allows for one specific public key to be spent with extremely cheaply, at
> the cost of making everything else more expensive.
>
> I believe that If there is at least one alternative key type in the
> construction that's larger than 32 bytes, or at least 2 alternative keys,
> Merkle tree based approaches will have a strictly lower on-chain footprint
> at spend time.
>
Ahh, I think I understand now. If one used multiple algorithms in their
original commitment, then at spend time they can choose to reveal only one
public key and signature for an algorithm known to be secure at that point
in time. That is very elegant.
> But today, end-users have no control over what algorithms to rely on. So
> long as all provided options are considered secure enough to pass NIST
> certification, why not allow some users to choose to use longer keys, or
> multiple algorithms in combination, should they want to take that extra
> step for themselves?
>
>
> There is no problem supporting multiple algorithms as long as everyone
> trusts all of them - and that is what will likely need to happen in
> practice. But coming to agreement on what that is, is part of the problem,
> and not all users might be willing to just trust NIST here to make that
> decision for everyone. Allowing users to choose individually between
> different "trusted" algorithms has only a marginal benefit: everyone
> already relies on none of these algorithms being broken for the currency to
> retain value. Picking a "stronger" algorithm for your own coins means
> you're optimizing for a scenario where other algorithms are broken, there
> is mass chaos due to theft and likely forks, but somehow your own coins
> make it through to the other side in a wasteland. It's certainly reasonable
> to expect that some individual users would make this choice if available,
> but systemically, as protocol designers, it does not seem like an
> interesting thing to focus on.
>
> Again, I'm not arguing against the practical reality of Bitcoin likely
> needing to adopt multiple algorithms if migration to a PQC world is needed.
> I am arguing against user flexibility itself being something to optimize
> for.
>
I am beginning to come around on this, because I had not considered how
much more trust already exists for hash-based signatures. If hashes break,
then the whole concept of block chains breaks. So hash-based signatures
seem to add the least additional security assumptions. All the other
signature schemes require additional assumptions about the hardnesses of
certain mathematical problems.
> If the reasoning is: "one of those algorithms might break", that very same
> reason (in my mind) justifies not having Bitcoin depend on any single
> algorithm (or algorithm family).
>
>
> The enormous difference is that Bitcoin users *already* opted into
> trusting that algorithm by using Bitcoin in the first place. Adding more
> algorithms means expanding the set of trusted algorithms, possibly against
> those users' wishes. The threat of CRQCs may make us all reevaluate our
> trust in secp256k1's security, which is why we're having this discussion.
>
That's true and I now understand your point. More algorithms means less
total trust in them all working out. Whereas moving to just one signature
scheme that had even more trust than ECDSA could make Bitcoin even more
trusted.
>
> What are the thoughts here on SQIsign 2.0
> <https://sqisign.org/spec/sqisign-20250205.pdf>? My understanding is that
> it is 30X faster than the original SQISign, and this version is now being
> evaluated by NIST. Its public key is only 2X ECDSA, and its signature is
> only 2.3X, while its verification time is 5.1 million ops (approximately
> 1.5 ms on a 3.4 GHz CPU). If there were only one PQC signature algorithm to
> choose, this one seems to have good trade offs (but it is still so new that
> I wouldn't feel comfortable trusting it alone and there not being any
> alternative to switch to).
>
>
> I'm really not qualified to comment on this.
>
> I don't think much thought has ever been given to the problem before.
> ECDSA was the obvious choice in 2008. But newer, more efficient, and more
> secure algorithms have since become available (e.g. Ed25519). I attribute
> the lack of change more to inertia than to a lack of consensus on Ed25519's
> security.
>
>
> I strongly disagree with this. The security difference between ed25519 and
> secp256k1 ECDSA is marginal. They are both based on hardness of the ECDLP
> problem. The secp256k1 curve has some unusual structure that may make it
> weaker than generic curves, though this is a theoretical concern right now.
> On the other hand, the ed25519 curve is slightly smaller, which should net
> it around 1.2 bits less security (also marginal). In theory, ECDSA may have
> weaknesses over Schnorr (which ed25519 and bip340 are instances of) in
> addition to their respective ECDLP hardness, but this is very theoretical.
>
> But even ignoring the security distinction between the two, needing to
> trust both is worse than just trusting one, which IMO means there was never
> a justification for adding ed25519.
>
That's a good point. I can agree then there never was sufficient reason to
change the protocol to add support for it.
And migrating fully to ed25519 (removing secp256k1 from the trust equation)
> would have come at a cost that isn't justified by the distinction between
> them. It is only due to the CRQC threat that we are now in a position that
> forces bearing that cost.
>
> I agree. If we do nothing and continue using ECDA, then CRQCs will destroy
> trust in Bitcoin, so we must add support for PQC. Given that, we can bet
> the farm on a single PQC algorithm, or we can hedge by supporting multiple
> PQC algorithms. I don't envy the decision you and the other Bitcoin
> developers must make, I only hope that I can help make your decision easier
> by sharing my perspective.
>
>
> This is not a decision that is up to developers, but up to the entire
> ecosystem. Certainly some people's opinion carry more weight than others,
> but software developers can only release software, not force people to use
> it. By participating in this discussion, you too are part of the reasoning
> that will ultimately guide the ecosystem towards the choice it makes.
> Please don't say it's up to some specific group of people to decide. If
> that were the case, Bitcoin has long failed already.
>
I appreciate that. Thank you for taking the time to educate me on this
topic. I feel Bitcoin's future remains bright given all the thought the
community is directing towards this problem.
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/CA%2BBCJUjN9%3Dprte7_Gfj_j8%3D2zSPfUQVQDm04aatyT7UAZp5i3A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 12667 bytes --]
prev parent reply other threads:[~2026-05-20 14:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 18:11 [bitcoindev] A "Quantum-Agile" Bitcoin address proposal Jason Resch
2026-05-19 19:31 ` Pieter Wuille
2026-05-20 3:10 ` Jason Resch
2026-05-20 13:02 ` Pieter Wuille
2026-05-20 14:20 ` Jason Resch [this message]
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='CA+BCJUjN9=prte7_Gfj_j8=2zSPfUQVQDm04aatyT7UAZp5i3A@mail.gmail.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