PQC - What is our Goal, Even?

[Matt Corallo]

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.

[Matt Corallo]

[Erik Aronesty]

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. 

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/05E6D06B-1F72-48F6-B4F3-0225675BCC1F%40mattcorallo.com.

[Matt Corallo]

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

> bitcoindev+...@googlegroups.com <mailto:bitcoindev%2Bunsu...@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+...@googlegroups.com <mailto:bitcoindev+...@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>.

[Erik Aronesty]

>   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.

[Erik Aronesty]

The assumption  Olaoluwa made is that there was a seed derivation at all.  Most of the exposed early coins don't have this.

[conduition]

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

> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c495b375-ebf5-4d9d-a9f6-a9d9922fd3dc%40mattcorallo.com.
>