From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Erik Aronesty <erik@q32.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] PQC - What is our Goal, Even?
Date: Thu, 16 Apr 2026 17:34:32 +0000 [thread overview]
Message-ID: <dV07voa7X-341HghubWLcbTo4Pju0s0SfO4a1sRsC6VC_mJIOJIACq5INXizBC-Xg_8tcpBYRj-0LGDc9KTfs9OIhFWVoNvRwYdVwYLUk2o=@proton.me> (raw)
In-Reply-To: <c495b375-ebf5-4d9d-a9f6-a9d9922fd3dc@mattcorallo.com>
[-- Attachment #1.1: Type: text/plain, Size: 12636 bytes --]
Hi List,
> Fundamentally, it seems to me the most reasonable goal is that we should be seeking to increase the number of coins which are reasonably likely to be secured by the time a CRQC exists. Put another way, we should be seeking to minimize the chance that the Bitcoin community feels the need to fork to burn coins by reducing the number of coins which can be stolen to the minimum number [1].
I think that's a reasonable goal which we all share, but is not the only goal. Real-life isn't about min-maxing a single metric of success.
For instance, imagine we deploy P2TRv2, and we get EVERYONE to migrate to it before a CRQC appears. We maxed out our stated success metric. But we might not disable P2TRv2 key-spending in a timely manner. If the future community fails to deploy at the right time, a CRQC can steal at least as much bitcoin as they could've before the migration, if not more. We maxed out our success metric but still failed, so that metric must not be our only goal.
That's why we should achieve your stated goal only as a consequence of a more general but less easily-quantifiable goal: to design an optimal, flexible, and long-term-secure PQ migration path. If we standardize this and make code available to help, migration will come as a natural consequence, as will other desirable goals like "not letting a CRQC screw us all over", and "enabling long-term cryptographic agility".
If we can agree on that, then any further disagreement will be due to a difference of opinion as to what is "optimal" or "flexible", and the correct trade-offs to make on security. We all weigh different properties with different values.
For instance, I put more weight on conclusive security of P2MR, whereas Matt puts more weight on fee-efficiency and "privacy" of P2TRv2 [^1].
There are also differences of faith. Matt puts more faith in the future community to activate follow-up soft forks. I put more faith in wallet developers following standards and in users proactively migrating to PQ-safe wallets.
Based on Matt's previous emails, I think we both share the same LACK of faith that a majority of the UTXO set will migrate in time, and we also share the goal of mitigating that.
> This naturally means focusing on the wallets which are the *least likely* to migrate or otherwise get themselves in a safe spot. Focusing on those who are the most likely to migrate does almost nothing to move the needle on the total number of coins protected, nor, thus, on the probability of a future Bitcoin community feeling the need to burn coins.
Also agreed.
I didn't find any public statements from your cited examples about quantum security posture. Since it seems important to understand the wallets' stances in this dilemma, I posted a tweet tagging 8 major multi-chain wallets [2] including the 3 wallets you cited as examples. I'm curious what they'll say.
Having worked with such wallets before, my expectation is that they'll follow whatever is standardized, as long as it gives them more market share and as long as they can "npm install whatever" to implement it. I'm not trivializing here - These devs are just spread much thinner than those building single-chain wallets.
The harder question to answer is whether the major wallets make the PQ output type the default for receiving Bitcoin. Big software companies are typically very concerned about bugs in new code paths, and they weigh this risk against the benefits of any new feature. When deploying new features as default, they often do so using A/B testing and incremental rollout techniques. So the earlier question shouldn't be binary. It becomes: How quickly will major wallets roll out PQ outputs as default?
Rollout pace will depend on the personal views of the wallets' corporate executives and technical advisors. They will weigh the risk of introducing new, riskier, less-efficient code paths against the risk of a CRQC appearing in the near future. We and other users can try to lobby them, but ultimately each wallet's decision makers must eventually convince themselves the CRQC risk is greater. Some will move too slowly, and many will likely regret their choices one way or another.
I believe we cannot effectively optimize away a problem like this by tempting decision-makers with slightly lower fees, since that's not all they are worried about. I believe we especially should not try to do so at the expense of conclusive PQ security and long-term optimization.
I think the crux of the P2TRv2 vs P2MR disagreement here is that Matt believes P2TRv2 will induce wallets to roll out default PQ outputs meaningfully faster than P2MR would, and that this trumps arguments about post-quantum security or efficiency.
Whereas in my opinion, all we can do is build the best PQ standards we can, and encourage wallets to migrate once they're worried enough by the CRQC risks and ready to accept some mild trade-offs. That "best PQ standard" is, long-term, P2MR.
> There is no possible ZKP that can fix this.
There are several techniques which can.
regards,
conduition
[^1]: I still have yet to hear a decent argument as to why P2TRv2 is meaningfully more private than P2MR.
[2]: https://x.com/conduition_io/status/2044804746687525012
On Thursday, April 16th, 2026 at 5:44 AM, Matt Corallo <lf-lists@mattcorallo.com> wrote:
> Hi Erik,
>
> It appears you missed Olaoluwa's posts on this very list where he did exactly the thing you claim is
> impossible - build a ZKP which allows someone to prove that they had the private key to a
> transaction in a way that no quantum computer can forge!
>
> Matt
>
> On 4/15/26 2:08 PM, Erik Aronesty wrote:
> > Yes I agree, Matt. People are definitely talking past each other. To me "safe coin maximization at
> > the expense of decentralization and proof" seems like the completely wrong goal in almost every way.
> >
> > I would like you to bear in mind that there is no reasonable way to a certain that someone is the
> > owner of a coin unless they show proof of that private key. I think we all can agree there.
> >
> > And that with the theoretical magical quantum computers compromising private keys they will be no
> > distinction between a coin holder and an attack. There is no possible ZKP that can fix this.
> >
> > I think the fundamental thing we need to do is provide sovereign and active users the ability to
> > protect their personal coins. Opting into this protection will occur as the interested users
> > determine that it needs to occur. This is the only sure way to prevent a premature optimization for
> > a computing paradigm that may never exist
> >
> > Maximizing sovereignty Is the entire purpose of a decentralized and peer-to-peer protocol.
> >
> > Having decentralization and sovereignty be a secondary goal is like ignoring freedom of speech and
> > then pretending to be a democracy.
> >
> >
> >
> >
> >
> > On Wed, Apr 15, 2026, 9:52 AM Matt Corallo <lf-lists@mattcorallo.com <mailto:lf-
> > lists@mattcorallo.com>> wrote:
> >
> > Its become obvious in recent discussions that a large part of the PQC discussion has people
> > coming at it from very different fundamental goals, and as a result the conversations often talk
> > past each other without making real progress. So instead of doing that more I'd like to write
> > down what I think the actual, short-term goal *is*, what it it is not.
> >
> > Fundamentally, it seems to me the most reasonable goal is that we should be seeking to increase
> > the number of coins which are reasonably likely to be secured by the time a CRQC exists. Put
> > another way, we should be seeking to minimize the chance that the Bitcoin community feels the
> > need to fork to burn coins by reducing the number of coins which can be stolen to the minimum
> > number [1].
> >
> > This naturally means focusing on the wallets which are the *least likely* to migrate or
> > otherwise get themselves in a safe spot. Focusing on those who are the most likely to migrate
> > does almost nothing to move the needle on the total number of coins protected, nor, thus, on the
> > probability of a future Bitcoin community feeling the need to burn coins. Sadly, this probably
> > means the "top wallets" that are generally terrible at adopting Bitcoin standards. Wallets which
> > are the top listing on app stores like (currently in the top few in my app store): Bitcoin.com,
> > Trust Wallet, Coinbase Wallet, Blockchain.com, etc. These wallets generally use a single static
> > address (because anything else confuses their users and they get additional support tickets for
> > it!) and put very little time into Bitcoin, focusing instead on other tokens and integrations.
> >
> > A few non-goals:
> >
> > * To ensure that advanced setups have the absolute best in post-quantum security. I don't see
> > how this moves the needle on the above goal, and in fact in many cases detracts from the above
> > goal. Of course if we can accomplish this without detracting from the top-line goal above, great.
> >
> > * To ensure we have the best possible design for the signature scheme bitcoin will be using in a
> > world where a CRQC exists and we've gotten past the mess. We'll almost certainly know a lot more
> > about the security of various schemes and have more options for how to approach the problem by
> > the point we're dealing with the mess of a CRQC being imminent, so it seems like a fools errand
> > to try to predict what we should build for this. But even if we know no more then than we do
> > today, likely ending up with hash-based signatures as the scheme everyone uses, we'll almost
> > certainly be having conversations about additional witness discounts or increased block sizes to
> > compensate for the sudden increase in transaction sizes. Maybe we would decide against such an
> > increase, but there's no question such a conversation would happen and it would be premature to
> > have it today.
> >
> > Matt
> >
> > [1] Of course I believe that the lost coin pool is large enough that the Bitcoin community will,
> > almost without question, fork to disable insecure spend paths and burn some coins in the
> > process, but reducing the number of coins burned to the absolute minimum is of course best for
> > everyone.
> >
> > --
> > 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 <mailto:bitcoindev%2Bunsubscribe@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/05E6D06B-1F72-48F6-
> > B4F3-0225675BCC1F%40mattcorallo.com <https://groups.google.com/d/msgid/
> > bitcoindev/05E6D06B-1F72-48F6-B4F3-0225675BCC1F%40mattcorallo.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
> > bitcoindev+unsubscribe@googlegroups.com <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/
> > CAJowKgLKkSrzKGZAe2sSgCafjKx_U%2BoWz%2B-FxSb%2BAtppAayQXA%40mail.gmail.com <https://
> > groups.google.com/d/msgid/bitcoindev/CAJowKgLKkSrzKGZAe2sSgCafjKx_U%2BoWz%2B-
> > FxSb%2BAtppAayQXA%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/c495b375-ebf5-4d9d-a9f6-a9d9922fd3dc%40mattcorallo.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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/dV07voa7X-341HghubWLcbTo4Pju0s0SfO4a1sRsC6VC_mJIOJIACq5INXizBC-Xg_8tcpBYRj-0LGDc9KTfs9OIhFWVoNvRwYdVwYLUk2o%3D%40proton.me.
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
next prev parent reply other threads:[~2026-04-16 18:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 16:37 Matt Corallo
2026-04-15 18:08 ` Erik Aronesty
2026-04-16 11:17 ` Matt Corallo
2026-04-16 16:28 ` Erik Aronesty
2026-04-16 16:31 ` Erik Aronesty
2026-04-16 17:34 ` 'conduition' via Bitcoin Development Mailing List [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-04-15 16:37 Matt Corallo
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='dV07voa7X-341HghubWLcbTo4Pju0s0SfO4a1sRsC6VC_mJIOJIACq5INXizBC-Xg_8tcpBYRj-0LGDc9KTfs9OIhFWVoNvRwYdVwYLUk2o=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=erik@q32.com \
--cc=lf-lists@mattcorallo.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