* [bitcoindev] PQC - What is our Goal, Even?
@ 2026-04-15 16:37 Matt Corallo
2026-04-15 18:08 ` Erik Aronesty
0 siblings, 1 reply; 13+ messages in thread
From: Matt Corallo @ 2026-04-15 16:37 UTC (permalink / raw)
To: bitcoindev
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.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/05E6D06B-1F72-48F6-B4F3-0225675BCC1F%40mattcorallo.com.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-15 16:37 [bitcoindev] PQC - What is our Goal, Even? Matt Corallo
@ 2026-04-15 18:08 ` Erik Aronesty
2026-04-16 11:17 ` Matt Corallo
0 siblings, 1 reply; 13+ messages in thread
From: Erik Aronesty @ 2026-04-15 18:08 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5296 bytes --]
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> 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.
> To view this discussion visit
> 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.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJowKgLKkSrzKGZAe2sSgCafjKx_U%2BoWz%2B-FxSb%2BAtppAayQXA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6406 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-15 18:08 ` Erik Aronesty
@ 2026-04-16 11:17 ` Matt Corallo
2026-04-16 16:28 ` Erik Aronesty
2026-04-16 17:34 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 2 replies; 13+ messages in thread
From: Matt Corallo @ 2026-04-16 11:17 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Development Mailing List
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
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
1 sibling, 1 reply; 13+ messages in thread
From: Erik Aronesty @ 2026-04-16 16:28 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7356 bytes --]
> you missed Olaoluwa's posts
No, I didn't miss them. They're irrelevant. The base-case assumption is
that the quantum assumption isn't attempting to forge a signature based on
a public key. It has the private key.
In which case there is no proof that can help.
On Thu, Apr 16, 2026 at 4:17 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/CAJowKgJ8vNpkm-aQHpeMvfW4QOVF3k7APzFMt72y%3DYYzhF_BbA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9788 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-16 16:28 ` Erik Aronesty
@ 2026-04-16 16:31 ` Erik Aronesty
0 siblings, 0 replies; 13+ messages in thread
From: Erik Aronesty @ 2026-04-16 16:31 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7731 bytes --]
The assumption Olaoluwa made is that there was a seed derivation at all.
Most of the exposed early coins don't have this.
On Thu, Apr 16, 2026 at 9:28 AM Erik Aronesty <erik@q32.com> wrote:
> > you missed Olaoluwa's posts
>
> No, I didn't miss them. They're irrelevant. The base-case assumption is
> that the quantum assumption isn't attempting to forge a signature based on
> a public key. It has the private key.
>
> In which case there is no proof that can help.
>
> On Thu, Apr 16, 2026 at 4:17 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/CAJowKgJUzfNXi8JLoN9oqVHjX%2BgQqPZypMgQbnW5mpgZ4HhHmA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 10341 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-16 11:17 ` Matt Corallo
2026-04-16 16:28 ` Erik Aronesty
@ 2026-04-16 17:34 ` 'conduition' via Bitcoin Development Mailing List
2026-04-17 20:44 ` Matt Corallo
1 sibling, 1 reply; 13+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-04-16 17:34 UTC (permalink / raw)
To: Matt Corallo; +Cc: Erik Aronesty, Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-16 17:34 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-04-17 20:44 ` Matt Corallo
2026-04-17 21:28 ` Ethan Heilman
0 siblings, 1 reply; 13+ messages in thread
From: Matt Corallo @ 2026-04-17 20:44 UTC (permalink / raw)
To: conduition; +Cc: Erik Aronesty, Bitcoin Development Mailing List
On 4/16/26 1:34 PM, conduition wrote:
> 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".
Sure, there are limitations of the goal as I stated, but your suggested alternative here isn't
actually a concreate goal. "optimal, flexible, and long-term-secure" isn't something we can optimize
for :)
> 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].
I think I maybe under-stated my concern over the no-address-reuse requirement for P2MR. We've been
trying to convince wallets to not reuse addresses for 15+ years and have not only had no success,
popular wallets have been actively migrating the opposite direction instead. In the face of address
reuse, P2MR has zero advantages over P2TRv2.
> 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.
Sure but no new key scheme is going to be an "npm install whatever" - it requires a rewrite of a
bunch of key derivation and backup schemes. P2MR is also asking them to overhaul a UX decision they
made with lots of user feedback on top of that.
> 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?
Fair, true point.
> 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.
No, its far from just about fees. Its also about maintaining the goals that we had going into
taproot. And a bit that P2MR doesn't accomplish anything unless much of the ecosystem changes their
processes substantially.
--
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/600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.com.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-17 20:44 ` Matt Corallo
@ 2026-04-17 21:28 ` Ethan Heilman
2026-04-18 0:37 ` Matt Corallo
0 siblings, 1 reply; 13+ messages in thread
From: Ethan Heilman @ 2026-04-17 21:28 UTC (permalink / raw)
To: Matt Corallo; +Cc: conduition, Erik Aronesty, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 8312 bytes --]
> We've been trying to convince wallets to not reuse addresses for 15+
years and have not only had no success, popular wallets have been actively
migrating the opposite direction instead.
There is a huge difference between, we would prefer you don't reuse
addresses because privacy loss although privacy is hard to maintain anyways
and if you reuse addresses in this context a CRQC may steal your user's
funds.
Wallets are likely to be more responsive here than in the past because the
stakes are much higher.
> In the face of address reuse, P2MR has zero advantages over P2TRv2.
It's not binary. If say 1% of coins in P2MR have address reuse because
those users preferred to use insecure wallets, you still protected 99% of
the other P2MR coins.
I am NOT suggesting or proposing this, but one could require that any P2MR
output whose EC pubkey has been leaked on-chain due to address reuse can
only be spent through the quantum safe leaf. If the community decides this
is wallets advertising PQ functionality aren't actually PQ safe because
this allow address reuse then one could solve the address reuse problem in
this manner.
All told, it seems better to communicate to wallets and users that wallets
which allow EC address reuse aren't PQ safe. If a wallet doesn't want to
provide PQ safety why would they put in the engineering effort to support
P2MR and PQ sigs.
On Fri, Apr 17, 2026, 17:02 Matt Corallo <lf-lists@mattcorallo.com> wrote:
>
>
> On 4/16/26 1:34 PM, conduition wrote:
> > 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".
>
> Sure, there are limitations of the goal as I stated, but your suggested
> alternative here isn't
> actually a concreate goal. "optimal, flexible, and long-term-secure" isn't
> something we can optimize
> for :)
>
> > 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].
>
> I think I maybe under-stated my concern over the no-address-reuse
> requirement for P2MR. We've been
> trying to convince wallets to not reuse addresses for 15+ years and have
> not only had no success,
> popular wallets have been actively migrating the opposite direction
> instead. In the face of address
> reuse, P2MR has zero advantages over P2TRv2.
>
> > 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.
>
> Sure but no new key scheme is going to be an "npm install whatever" - it
> requires a rewrite of a
> bunch of key derivation and backup schemes. P2MR is also asking them to
> overhaul a UX decision they
> made with lots of user feedback on top of that.
>
> > 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?
>
> Fair, true point.
>
> > 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.
>
> No, its far from just about fees. Its also about maintaining the goals
> that we had going into
> taproot. And a bit that P2MR doesn't accomplish anything unless much of
> the ecosystem changes their
> processes substantially.
>
> --
> 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/600f95eb-04e8-470d-b6df-cf725e48d1b5%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/CAEM%3Dy%2BWi1ERpSCEFadYS4esGSPauM%2BvoNkSSjZzqeUijWESyFg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9859 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-17 21:28 ` Ethan Heilman
@ 2026-04-18 0:37 ` Matt Corallo
2026-04-18 15:44 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 1 reply; 13+ messages in thread
From: Matt Corallo @ 2026-04-18 0:37 UTC (permalink / raw)
To: Ethan Heilman; +Cc: conduition, Erik Aronesty, bitcoindev
[-- Attachment #1: Type: text/html, Size: 11537 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-18 0:37 ` Matt Corallo
@ 2026-04-18 15:44 ` 'conduition' via Bitcoin Development Mailing List
2026-04-18 16:34 ` Erik Aronesty
2026-04-19 0:29 ` Matt Corallo
0 siblings, 2 replies; 13+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-04-18 15:44 UTC (permalink / raw)
To: Matt Corallo; +Cc: Ethan Heilman, Erik Aronesty, bitcoindev
[-- Attachment #1.1.1: Type: text/plain, Size: 15438 bytes --]
> I think I maybe under-stated my concern over the no-address-reuse requirement for P2MR. We've been trying to convince wallets to not reuse addresses for 15+ years and have not only had no success, popular wallets have been actively migrating the opposite direction instead. In the face of address reuse, P2MR has zero advantages over P2TRv2.
I think we agree that merely spec-ing out P2MR as "not safe to reuse" in a BIP will be insufficient to prevent all address reuse. We also agree that reused P2MR and P2TRv2 share the same security profile, with or without a future EC restriction (which can be applied to either output type).
But we seem to disagree in our conclusions. You believe that because of this overlap in security profiles, that we therefore ought to prefer P2TRv2 - presumably because of its short-term efficiency. I think that's a huge leap of logic. The overall security profile of P2TRv2 and P2MR are wildly different and you are only taking a subset of P2MR's profile into account.
To reach your conclusion that P2TRv2 is preferable, you'd need to assume that the vast majority users who migrate to P2MR will reuse addresses - vast enough of a majority that the short-term efficiency savings of P2TRv2 key-spending outweighs the safety of the (presumed) tiny minority of users who actually use P2MR properly.
We have historical evidence this assumption won't hold. Take a look at Project Eleven's bitcoin risk list metrics dashboard. The volume of bitcoin exposed today due to address reuse is only a minority fraction of the overall supply - about 5 million BTC at present. Still significant, but not an overwhelming majority by any means. We have no reason to expect everyone will suddenly start reusing addresses consistently with P2MR, at least not any more than they already do.
If anything, address-reuse will reduce, and not just because we ask them to. If you look at the highest-value addresses at fault of address-reuse today, they are mostly corporate cold wallets: binance, robinhood, bitfinex, tether, etc, and these make up a significant chunk of those 5 million exposed coins. We can reasonably expect those players to use P2MR properly out of self-interest - These coins will be the lowest-hanging fruit targets if they fail to do so.
So yes, even after taking address reuse into account, P2MR is more secure than P2TRv2, and personally I think the safety delta between them is wide enough to excuse the minor handicap in P2MR's pre-quantum efficiency.
> P2MR is also asking them to overhaul a UX decision they made with lots of user feedback on top of that.
That's fair, it would be a difficult challenge to some low-effort wallets not to receive coins to vulnerable addresses. But this argument implies EC spending on P2MR isn't restricted in time - otherwise there is nothing to exploit when addresses are reused, and so address reuse wouldn't matter. Under this same implication, P2TRv2 fares even worse. Concretely:
- If EC spending is restricted, then both P2MR and P2TRv2 have exactly the same security profile and address reuse does not matter.
- If EC spending isn't restricted, then both address formats are vulnerable when reused, and P2TRv2 exposure is worse because even those who don't reuse addresses are vulnerable.
In other words, P2MR is the Nash equilibrium of a prisoner's dilemma square [^1].
- P2MR: addresses with hidden EC spend paths are safe
- P2TRv2: everyone is vulnerable
- P2MR with EC restriction: everyone is safe
- P2TRv2 with EC restriction: everyone is safe
Whether EC restriction happens or not, you always get the same or better security by choosing P2MR. EC restriction is the only step which can secure reused addresses of either P2MR or P2TRv2 [^2].
Thus, if you firmly believe that many wallets will reuse addresses and want to mitigate the vulnerability that follows, then the choice between output types should not weigh on your mind. Your goal should be to push everyone to commit to an EC-restricting soft fork later (maybe have a look at BIP361 and contribute to that). The details of what output type is deployed don't factor in. Again: the only difference between P2MR and P2TRv2 there is that P2TRv2 needs a future soft fork to restrict EC spending, while with P2MR this is optional, but still desirable (since some wallets will mistakenly reuse addresses either way).
regards,
conduition
[^1]: You can expand that prisoner's dilemma square into a cube by asking whether a CRQC will be invented or not, and P2MR is still a strictly better choice even if no CRQC appears - with or without EC restriction - because of its better script-path efficiency.
[^2]: For those rare few wallets who are: (1) willing to upgrade, (2) NOT willing to use fresh addresses, and (3) NOT willing to depend on future activation of an EC restriction, then these wallets can choose to use hybrid address formats which use ECC and hash-based sigs in the same locking script. This allows them to reuse addresses at the cost of efficiency. With a stateful signature (e.g. XMSS/SHRINCS), they'd be adding a few hundred bytes to their witnesses, and they'd be able to reuse the address thousands to millions of times. I could picture corporate cold-wallets using this technique, but maybe not retail wallets.
On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo <lf-lists@mattcorallo.com> wrote:
>
>
>
> > On Apr 17, 2026, at 18:04, Ethan Heilman <eth3rs@gmail.com> wrote:
>
> >
> > > We've been trying to convince wallets to not reuse addresses for 15+ years and have not only had no success, popular wallets have been actively migrating the opposite direction instead.
> >
> > There is a huge difference between, we would prefer you don't reuse addresses because privacy loss although privacy is hard to maintain anyways and if you reuse addresses in this context a CRQC may steal your user's funds.
> >
> > Wallets are likely to be more responsive here than in the past because the stakes are much higher.
>
>
> More, maybe. But I think you’re drastically underestimating to what extent address reuse is baked into many flows.
>
> For example most funds or very large holders have a pre-defined list of addresses that they’re allowed to send to (basically exchange accounts to sell), and have processes in place to ensure everyone cross validates that the address is on the list.
>
> Yes, it’s possible to redo these, but people won’t, they’ll just presume that they can move the funds again before a CRQC. And many of them can, of course - the large funds probably would be about to move in a few days or weeks - but I’m quite confident it’ll get normalized pretty quickly…
>
>
> > > In the face of address reuse, P2MR has zero advantages over P2TRv2.
> >
> > It's not binary. If say 1% of coins in P2MR have address reuse because those users preferred to use insecure wallets, you still protected 99% of the other P2MR coins.
>
>
> Yes but we’re still back to square one - there’s still wallets relying on a disable-EC soft fork before a CRQC.
>
>
> > I am NOT suggesting or proposing this, but one could require that any P2MR output whose EC pubkey has been leaked on-chain due to address reuse can only be spent through the quantum safe leaf. If the community decides this is wallets advertising PQ functionality aren't actually PQ safe because this allow address reuse then one could solve the address reuse problem in this manner.
>
>
> Yes, i mean I think P2MR would be way more exciting if we had an efficient way to enforce addresses as single use directly in consensus. I’m not, however, aware of one.
>
>
> > All told, it seems better to communicate to wallets and users that wallets which allow EC address reuse aren't PQ safe. If a wallet doesn't want to provide PQ safety why would they put in the engineering effort to support P2MR and PQ sigs.
>
>
> Because there will be marketing for “PQ safe” and no one (but us) will actually care about the distinction or bugs :).
>
> Matt
>
>
> > On Fri, Apr 17, 2026, 17:02 Matt Corallo <lf-lists@mattcorallo.com> wrote:
> >
> > >
> > >
> > > On 4/16/26 1:34 PM, conduition wrote:
> > > > 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".
> > >
> > > Sure, there are limitations of the goal as I stated, but your suggested alternative here isn't
> > > actually a concreate goal. "optimal, flexible, and long-term-secure" isn't something we can optimize
> > > for :)
> > >
> > > > 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].
> > >
> > > I think I maybe under-stated my concern over the no-address-reuse requirement for P2MR. We've been
> > > trying to convince wallets to not reuse addresses for 15+ years and have not only had no success,
> > > popular wallets have been actively migrating the opposite direction instead. In the face of address
> > > reuse, P2MR has zero advantages over P2TRv2.
> > >
> > > > 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.
> > >
> > > Sure but no new key scheme is going to be an "npm install whatever" - it requires a rewrite of a
> > > bunch of key derivation and backup schemes. P2MR is also asking them to overhaul a UX decision they
> > > made with lots of user feedback on top of that.
> > >
> > > > 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?
> > >
> > > Fair, true point.
> > >
> > > > 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.
> > >
> > > No, its far from just about fees. Its also about maintaining the goals that we had going into
> > > taproot. And a bit that P2MR doesn't accomplish anything unless much of the ecosystem changes their
> > > processes substantially.
> > >
> > > --
> > > 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/600f95eb-04e8-470d-b6df-cf725e48d1b5%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/sMhLbmV30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgPDvxe_2lzDqHJsz9bsSInuaqZ5SSstrFJsE%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 21894 bytes --]
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-18 15:44 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-04-18 16:34 ` Erik Aronesty
2026-04-19 0:29 ` Matt Corallo
1 sibling, 0 replies; 13+ messages in thread
From: Erik Aronesty @ 2026-04-18 16:34 UTC (permalink / raw)
To: conduition; +Cc: Matt Corallo, Ethan Heilman, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 16009 bytes --]
P2MR is superior in another way. If quantum never happens (a very real
possibility), P2MR is genuinely broadly useful and more secure in other
ways.
In other words, it wouldn't have been a waste of everyone's time.
On Sat, Apr 18, 2026 at 8:44 AM conduition <conduition@proton.me> wrote:
> I think I maybe under-stated my concern over the no-address-reuse
> requirement for P2MR. We've been trying to convince wallets to not reuse
> addresses for 15+ years and have not only had no success, popular wallets
> have been actively migrating the opposite direction instead. In the face of
> address reuse, P2MR has zero advantages over P2TRv2.
>
>
> I think we agree that merely spec-ing out P2MR as "not safe to reuse" in a
> BIP will be insufficient to prevent all address reuse. We also agree that
> *reused *P2MR and P2TRv2 share the same security profile, with or without
> a future EC restriction (which can be applied to either output type).
>
> But we seem to disagree in our conclusions. You believe that because of
> this overlap in security profiles, that we therefore ought to prefer P2TRv2
> - presumably because of its short-term efficiency. I think that's a huge
> leap of logic. The overall security profile of P2TRv2 and P2MR are wildly
> different and you are only taking a subset of P2MR's profile into account.
>
> To reach your conclusion that P2TRv2 is preferable, you'd need to assume
> that the vast majority users who migrate to P2MR will reuse addresses -
> vast enough of a majority that the short-term efficiency savings of P2TRv2
> key-spending outweighs the safety of the (presumed) tiny minority of users
> who actually use P2MR properly.
>
> We have historical evidence this assumption won't hold. Take a look at Project
> Eleven's bitcoin risk list metrics dashboard
> <https://www.projecteleven.com/bitcoin-risq-list/metrics>. The volume of
> bitcoin exposed today due to address reuse is only a minority fraction of
> the overall supply - about 5 million BTC at present. Still significant, but
> not an overwhelming majority by any means. We have no reason to expect
> everyone will suddenly start reusing addresses consistently with P2MR, at
> least not any more than they already do.
>
> If anything, address-reuse will reduce, and not just because we ask them
> to. If you look at the highest-value addresses at fault of address-reuse
> today, they are mostly corporate cold wallets: binance, robinhood,
> bitfinex, tether, etc, and these make up a significant chunk of those 5
> million exposed coins. We can reasonably expect those players to use P2MR
> properly out of self-interest - These coins will be the lowest-hanging
> fruit targets if they fail to do so.
>
> So yes, even after taking address reuse into account, P2MR is more secure
> than P2TRv2, and personally I think the safety delta between them is wide
> enough to excuse the minor handicap in P2MR's pre-quantum efficiency.
>
> P2MR is also asking them to overhaul a UX decision they made with lots of
> user feedback on top of that.
>
>
> That's fair, it would be a difficult challenge to some low-effort wallets
> not to receive coins to vulnerable addresses. But this argument implies EC
> spending on P2MR isn't restricted in time - otherwise there is nothing to
> exploit when addresses are reused, and so address reuse wouldn't matter.
> Under this same implication, P2TRv2 fares even worse. Concretely:
>
>
> - If EC spending is restricted, then both P2MR and P2TRv2 have exactly
> the same security profile and address reuse does not matter.
>
>
> - If EC spending isn't restricted, then both address formats are
> vulnerable when reused, and P2TRv2 exposure is worse because even those who
> *don't* reuse addresses are vulnerable.
>
>
> In other words, P2MR is the Nash equilibrium of a prisoner's dilemma
> square [^1].
>
>
> - P2MR: addresses with hidden EC spend paths are safe
> - P2TRv2: everyone is vulnerable
> - P2MR with EC restriction: everyone is safe
> - P2TRv2 with EC restriction: everyone is safe
>
>
> Whether EC restriction happens or not, you always get the same or better
> security by choosing P2MR. EC restriction is the only step which can secure
> reused addresses of either P2MR or P2TRv2 [^2].
>
> Thus, if you firmly believe that many wallets will reuse addresses and
> want to mitigate the vulnerability that follows, then the choice between
> output types should not weigh on your mind. Your goal should be to push
> everyone to commit to an EC-restricting soft fork later (maybe have a look
> at BIP361 and contribute to that). The details of what output type is
> deployed don't factor in. Again: the only difference between P2MR and
> P2TRv2 there is that P2TRv2 *needs a future soft fork to restrict EC
> spending*, while with P2MR this is optional, but still desirable (since
> some wallets will mistakenly reuse addresses either way).
>
> regards,
> conduition
>
> [^1]: You can expand that prisoner's dilemma square into a cube by asking
> whether a CRQC will be invented or not, and P2MR is still a strictly better
> choice even if no CRQC appears - with or without EC restriction - because
> of its better script-path efficiency.
>
> [^2]: For those rare few wallets who are: (1) willing to upgrade, (2) NOT
> willing to use fresh addresses, and (3) NOT willing to depend on future
> activation of an EC restriction, then these wallets can choose to use
> hybrid address formats which use ECC and hash-based sigs in the same
> locking script. This allows them to reuse addresses at the cost of
> efficiency. With a stateful signature (e.g. XMSS/SHRINCS), they'd be adding
> a few hundred bytes to their witnesses, and they'd be able to reuse the
> address thousands to millions of times. I could picture corporate
> cold-wallets using this technique, but maybe not retail wallets.
> On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo <
> lf-lists@mattcorallo.com> wrote:
>
>
>
> On Apr 17, 2026, at 18:04, Ethan Heilman <eth3rs@gmail.com> wrote:
>
>
>
> > We've been trying to convince wallets to not reuse addresses for 15+
> years and have not only had no success, popular wallets have been actively
> migrating the opposite direction instead.
>
> There is a huge difference between, we would prefer you don't reuse
> addresses because privacy loss although privacy is hard to maintain anyways
> and if you reuse addresses in this context a CRQC may steal your user's
> funds.
>
> Wallets are likely to be more responsive here than in the past because the
> stakes are much higher.
>
>
> More, maybe. But I think you’re drastically underestimating to what extent
> address reuse is baked into many flows.
>
> For example most funds or very large holders have a pre-defined list of
> addresses that they’re allowed to send to (basically exchange accounts to
> sell), and have processes in place to ensure everyone cross validates that
> the address is on the list.
>
> Yes, it’s possible to redo these, but people won’t, they’ll just presume
> that they can move the funds again before a CRQC. And many of them can, of
> course - the large funds probably would be about to move in a few days or
> weeks - but I’m quite confident it’ll get normalized pretty quickly…
>
> > In the face of address reuse, P2MR has zero advantages over P2TRv2.
>
> It's not binary. If say 1% of coins in P2MR have address reuse because
> those users preferred to use insecure wallets, you still protected 99% of
> the other P2MR coins.
>
>
> Yes but we’re still back to square one - there’s still wallets relying on
> a disable-EC soft fork before a CRQC.
>
> I am NOT suggesting or proposing this, but one could require that any P2MR
> output whose EC pubkey has been leaked on-chain due to address reuse can
> only be spent through the quantum safe leaf. If the community decides this
> is wallets advertising PQ functionality aren't actually PQ safe because
> this allow address reuse then one could solve the address reuse problem in
> this manner.
>
>
> Yes, i mean I think P2MR would be way more exciting if we had an efficient
> way to enforce addresses as single use directly in consensus. I’m not,
> however, aware of one.
>
> All told, it seems better to communicate to wallets and users that wallets
> which allow EC address reuse aren't PQ safe. If a wallet doesn't want to
> provide PQ safety why would they put in the engineering effort to support
> P2MR and PQ sigs.
>
>
> Because there will be marketing for “PQ safe” and no one (but us) will
> actually care about the distinction or bugs :).
>
> Matt
>
> On Fri, Apr 17, 2026, 17:02 Matt Corallo <lf-lists@mattcorallo.com> wrote:
>
>>
>>
>> On 4/16/26 1:34 PM, conduition wrote:
>> > 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".
>>
>> Sure, there are limitations of the goal as I stated, but your suggested
>> alternative here isn't
>> actually a concreate goal. "optimal, flexible, and long-term-secure"
>> isn't something we can optimize
>> for :)
>>
>> > 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].
>>
>> I think I maybe under-stated my concern over the no-address-reuse
>> requirement for P2MR. We've been
>> trying to convince wallets to not reuse addresses for 15+ years and have
>> not only had no success,
>> popular wallets have been actively migrating the opposite direction
>> instead. In the face of address
>> reuse, P2MR has zero advantages over P2TRv2.
>>
>> > 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.
>>
>> Sure but no new key scheme is going to be an "npm install whatever" - it
>> requires a rewrite of a
>> bunch of key derivation and backup schemes. P2MR is also asking them to
>> overhaul a UX decision they
>> made with lots of user feedback on top of that.
>>
>> > 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?
>>
>> Fair, true point.
>>
>> > 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.
>>
>> No, its far from just about fees. Its also about maintaining the goals
>> that we had going into
>> taproot. And a bit that P2MR doesn't accomplish anything unless much of
>> the ecosystem changes their
>> processes substantially.
>>
>> --
>> 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/600f95eb-04e8-470d-b6df-cf725e48d1b5%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/CAJowKgJnVpdZfEcMmE69LpnGTPYk%3DJsKEK9e%2B39-O8QafPf1kQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 20881 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bitcoindev] PQC - What is our Goal, Even?
2026-04-18 15:44 ` 'conduition' via Bitcoin Development Mailing List
2026-04-18 16:34 ` Erik Aronesty
@ 2026-04-19 0:29 ` Matt Corallo
1 sibling, 0 replies; 13+ messages in thread
From: Matt Corallo @ 2026-04-19 0:29 UTC (permalink / raw)
To: conduition; +Cc: Ethan Heilman, bitcoindev
On 4/18/26 11:44 AM, conduition wrote:
> I think I maybe under-stated my concern over the no-address-reuse requirement for P2MR. We've
> been trying to convince wallets to not reuse addresses for 15+ years and have not only had no
> success, popular wallets have been actively migrating the opposite direction instead. In the
> face of address reuse, P2MR has zero advantages over P2TRv2.
>
>
> I think we agree that merely spec-ing out P2MR as "not safe to reuse" in a BIP will be insufficient
> to prevent all address reuse. We also agree that /reused /P2MR and P2TRv2 share the same security
> profile, with or without a future EC restriction (which can be applied to either output type).
>
> But we seem to disagree in our conclusions. You believe that because of this overlap in security
> profiles, that we therefore ought to prefer P2TRv2 - presumably because of its short-term
> efficiency. I think that's a huge leap of logic. The overall security profile of P2TRv2 and P2MR are
> wildly different and you are only taking a subset of P2MR's profile into account.
>
> To reach your conclusion that P2TRv2 is preferable, you'd need to assume that the vast majority
> users who migrate to P2MR will reuse addresses - vast enough of a majority that the short-term
> efficiency savings of P2TRv2 key-spending outweighs the safety of the (presumed) tiny minority of
> users who actually use P2MR properly.
>
> We have historical evidence this assumption won't hold. Take a look at Project Eleven's bitcoin risk
> list metrics dashboard <https://www.projecteleven.com/bitcoin-risq-list/metrics>. The volume of
> bitcoin exposed today due to address reuse is only a minority fraction of the overall supply - about
> 5 million BTC at present. Still significant, but not an overwhelming majority by any means. We have
> no reason to expect everyone will suddenly start reusing addresses consistently with P2MR, at least
> not any more than they already do.
>
> If anything, address-reuse will reduce, and not just because we ask them to. If you look at the
> highest-value addresses at fault of address-reuse today, they are mostly corporate cold wallets:
> binance, robinhood, bitfinex, tether, etc, and these make up a significant chunk of those 5 million
> exposed coins. We can reasonably expect those players to use P2MR properly out of self-interest -
> These coins will be the lowest-hanging fruit targets if they fail to do so.
>
> So yes, even after taking address reuse into account, P2MR is more secure than P2TRv2, and
> personally I think the safety delta between them is wide enough to excuse the minor handicap in
> P2MR's pre-quantum efficiency.
I think the gap between our views is that I don't buy that the "percentage harm reduction" outcome
is all that interesting. Sure, there's some % where it certainly is, but its probably in the 99+%
range, not in the 75-90% range. I think maybe the biggest gap is I just don't find any "solution"
that results in 10-20% of bitcoin (*especially* active bitcoin people hold keys to that made some
progress in migrating but maybe screwed up address reuse) being stolen as at all interesting. If we
manage to get 90% of active coins secured and then 10-20% of active wallets get some of their funds
stolen, have we actually accomplished something grand, or is Bitcoin's reputation so shot that we
might as well pack it up and go work on some new fresh chain that is PQC from day one? I'm fairly
confident the answer is the second, not just in that "we"'ve failed, but that the market will see it
the same way.
Sure, in any solution set here there is going to be coins lost, but if someone did the work to
migrate, having a high % chance of screwing it up isn't an interesting scenario to consider -
bitcoin is simply dead in that case.
> P2MR is also asking them to overhaul a UX decision they made with lots of user feedback on top
> of that.
>
>
> That's fair, it would be a difficult challenge to some low-effort wallets not to receive coins to
> vulnerable addresses. But this argument implies EC spending on P2MR isn't restricted in time -
> otherwise there is nothing to exploit when addresses are reused, and so address reuse wouldn't
> matter. Under this same implication, P2TRv2 fares even worse. Concretely:
>
> * If EC spending is restricted, then both P2MR and P2TRv2 have exactly the same security profile
> and address reuse does not matter.
>
> * If EC spending isn't restricted, then both address formats are vulnerable when reused, and
> P2TRv2 exposure is worse because even those who /don't/ reuse addresses are vulnerable.>
> In other words, P2MR is the Nash equilibrium of a prisoner's dilemma square [^1].
>
> * P2MR: addresses with hidden EC spend paths are safe
> * P2TRv2: everyone is vulnerable
> * P2MR with EC restriction: everyone is safe
> * P2TRv2 with EC restriction: everyone is safe
>
>
> Whether EC restriction happens or not, you always get the same or better security by choosing P2MR.
> EC restriction is the only step which can secure reused addresses of either P2MR or P2TRv2 [^2].
Right, see above. Who cares if NN% of people used P2MR, accidentally had some address reuse, and now
their coins are stolen? Bitcoin is over. Great, some exchanges managed to protect their coins and
probably some long-term holders, but a ton didn't, due to no direct fault of their own. What in the
hell is the point of bitcoin if so many lost coins without fault?
> Thus, if you firmly believe that many wallets will reuse addresses and want to mitigate the
> vulnerability that follows, then the choice between output types should not weigh on your mind. Your
> goal should be to push everyone to commit to an EC-restricting soft fork later (maybe have a look at
> BIP361 and contribute to that). The details of what output type is deployed don't factor in. Again:
> the only difference between P2MR and P2TRv2 there is that P2TRv2 /needs a future soft fork to
> restrict EC spending/, while with P2MR this is optional, but still desirable (since some wallets
> will mistakenly reuse addresses either way).
The selection of output types matters for other reasons, certainly the only consideration is not who
will select which output type.
Matt
--
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/2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886%40mattcorallo.com.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [bitcoindev] PQC - What is our Goal, Even?
@ 2026-04-15 16:37 Matt Corallo
0 siblings, 0 replies; 13+ messages in thread
From: Matt Corallo @ 2026-04-15 16:37 UTC (permalink / raw)
To: bitcoindev
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.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CF7A554D-EE6F-4E6B-A670-1D6F72170539%40mattcorallo.com.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2026-04-19 1:51 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-04-15 16:37 [bitcoindev] PQC - What is our Goal, Even? 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
2026-04-17 20:44 ` Matt Corallo
2026-04-17 21:28 ` Ethan Heilman
2026-04-18 0:37 ` Matt Corallo
2026-04-18 15:44 ` 'conduition' via Bitcoin Development Mailing List
2026-04-18 16:34 ` Erik Aronesty
2026-04-19 0:29 ` Matt Corallo
-- strict thread matches above, loose matches on Subject: below --
2026-04-15 16:37 Matt Corallo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox