J. Lopp's Post-Quantum Migration BIP

[Pmalek]

Yes but my concern  is how to make something like this user friendly enough that even the non technical holders will be able to use. if it requires manual scripting or complex multi step processes, I think uptake might just too low to matter.

We will all have to get used to it and accept it for what it is because the alternative isn't great. Bitcoin itself required a certain technical know-how the first time we got in contact with the system. People will create tutorials and guides that those with less technical knowledge can follow. Videos will come out to explain the processes. Creating the best possible solution is the priority. User friendliness and ease of use is of secondary importance.

[Satofan44]

I think this would be a non viable options. The throughput of bitcoin blockchain would be severely impacted, and migrating all the possible UTXO  would be impossible.
It’s nice to see theoretical improvement on every proposal, but we need something more.

We definitely need something more, but then again, this was never meant to be the final solution. It's just a theoretical scenario and a possible option for those who would want to take matters in their own hands if a necessary protocol change isn't adopted in a future where and if quantum threats become a reality. It's on the experts to research and debate how feasible this scheme is for Bitcoin.

All these intermediary solutions are great, they show that research is being done and all kinds of options are being explored. This is the kind of approach that we need, and not panicking or "community involvement". One would not want to fly on airplane that was built by the "community", would they? As you can also see, a similar thing was done with this proposal in the quotes by d5000 below. The stateful version of it, while technically doable, is very impractical but it was an intermediary step until they figured out and published a stateless version. It is important to publish ideas because some other researchers may not be aware that certain avenues of methods are even possibilities as solution, and as such they could be missing out on key things that could help them solve their own ideas.

I read a bit more and there is actually a problem with the SHRINCS proposal that would make it unpractical to use for Bitcoin: It is a "stateful" method.
Each time you sign a transaction, the "state" of the cryptosystem changes. The private key doesn't consist of a single number but of a tree of numbers. In each signature, other leaves of the tree are used.

The big problem is: If you use one of the leaves twice by accident, this can give an attacker enough information to get the whole key "tree" and then they can steal your coins. So this must be avoided at all cost.

This means that each time you sign a transaction you need to update all your backups with the "state" of the key tree. Effectively this would make it very unpractical to use on more than a single device, and saving the key isn't as simple as simply storing a seed phrase because you need the state too.

Thus Blockstream Research im March came up with an updated proposal called SHRIMPS which doesn't have that problem. It has smaller signatures than SPHINCS+ but much larger than the original SHRINCS (about 2500 bytes) which again would severely restrict the blockchain.

Regarding verification speed, some short info from Google confirms that the "stateless" SPHINCS+ is the most expensive and validation costs almost 20x more than for the "stateful" SHRINCS. SHRIMPS is on a middle ground (about 7x less validation

Yes but my concern  is how to make something like this user friendly enough that even the non technical holders will be able to use. if it requires manual scripting or complex multi step processes, I think uptake might just too low to matter.

You are worrying to far ahead. The method that was posted may not be the "final" solution to this quantum situation, and as such putting large efforts into making it extremely user friendly could end up being a mistake. Let's not rush towards latter steps before we figure out the basics.

[Wind_FURY]

Monero Research Labs posted a proposal for an upgrade in X. I know it's for Monero, but because the topic is discussing about probable solutions against the Quantum Threat, I'm posting this here and I'm curious what opinions gmax and achow might have.

New draft from tevador on post-quantum Jamtis addressing for Monero (PQ forward secrecy + more): "the new format allows for post-quantum forward secret  transactions that can't be decrypted even if the address is publicly  known and the elliptic curve discrete logarithm (ECDLP) is broken."
Feedback welcome!
Tevador: "Incomplete, but probably enough for some feedback."

https://x.com/moneroresearchl/status/2043517631043338531

Github link from the post, https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832

[Pmalek]

Monero Research Labs posted a proposal for an upgrade in X. I know it's for Monero, but because the topic is discussing about probable solutions against the Quantum Threat, I'm posting this here and I'm curious what opinions gmax and achow might have.

I am neither gmax or achow, nor do I posses their technical knowledge but using my limited technical know-how, this seems like a proposal to strengthen the privacy of Monero transactions in a future, post-quantum world. It's supposed to protect the privacy of senders ad receivers, plus the amounts and outputs moving between them. I guess Jamtis introduces a new, post quantum encryption model that's tailored specifically to Monero and not Bitcoin.

I will let others judge whether or not Jamtis or a Jamtis v2 can be modelled for the Bitcoin blockchain.

[Wind_FURY]

Monero Research Labs posted a proposal for an upgrade in X. I know it's for Monero, but because the topic is discussing about probable solutions against the Quantum Threat, I'm posting this here and I'm curious what opinions gmax and achow might have.

I am neither gmax or achow, nor do I posses their technical knowledge but using my limited technical know-how, this seems like a proposal to strengthen the privacy of Monero transactions in a future, post-quantum world. It's supposed to protect the privacy of senders ad receivers, plus the amounts and outputs moving between them. I guess Jamtis introduces a new, post quantum encryption model that's tailored specifically to Monero and not Bitcoin.

I will let others judge whether or not Jamtis or a Jamtis v2 can be modelled for the Bitcoin blockchain.

It's obviously to get their network ready for the Quantum Threat, but what I want to learn is if their solution would actually work as planned.

Our fellow plebs might have some "strong ideas", but how could we really know if they're truly qualified to make such affirmations. I'm waiting for gmax and achow if they want to post their opinions/ideas.

[Pmalek]

I'm waiting for gmax and achow if they want to post their opinions/ideas.

Somehow I doubt they will. The discussion in this thread has been ongoing for more than half a year and in that time neither of them have posted even once. Will they start now...? doubtful. We can see some of their thoughts from other topics, quoted here by other forum members, but no posts from them directly.

[Wind_FURY]

I'm waiting for gmax and achow if they want to post their opinions/ideas.

Somehow I doubt they will. The discussion in this thread has been ongoing for more than half a year and in that time neither of them have posted even once. Will they start now...? doubtful. We can see some of their thoughts from other topics, quoted here by other forum members, but no posts from them directly.

OK.

One of my Bitcoin friends said that some of the developers at BlockStream have started talking to Justin Drake of the Ethereum Foundation about the Quantum Threat. It's probably mere informal talks though.

Both blockchains will have their own challenges. For Bitcoin it's mostly political. For Ethereum, it's technically more complicated because there are layers of updates needed to do.

[tromp]

probable solutions against the Quantum Threat

tevador's proposal is not a solution against the Quantum Threat, which would require post-quantum soundness:

1.3 Non-goals
An explicit non-goal of Jamtis is post-quantum soundness. This includes preventing a quantum-enabled adversary from:

opening Pedersen commitments to arbitrary monetary values
forging spend authorization proofs and linking tags
forging membership proofs
Past and present Monero transactions are safe from soundness-breaking quantum attacks, assuming no cryptographically relevant quantum computers exist at this moment. Both Carrot and Jamtis support a migration protocol that will be used in a future fully post-quantum upgrade.

[Satofan44]

The freeze at all costs people have backed down as they have failed to gain any significant support. Now Lopp is back with a much more reasonable proposal, but even this can be debated and will probably be met with a lot of resistance: https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki.

Abstract

This proposal follows the implementation of any post-quantum (PQ) output type and introduces a pre-announced sunset of legacy ECDSA/Schnorr signatures. It turns quantum security into a private incentive: fail to upgrade and you will encounter additional friction to access your funds, creating a certainty where none previously existed.

Phase A: Disallows sending of any funds to quantum-vulnerable addresses, hastening the adoption of PQ address types.

Phase B: Renders ECDSA/Schnorr spends invalid, preventing all spending of funds in quantum-vulnerable UTXOs. This is triggered by a well-publicized flag-day five years after activation.

Phase C (TBD): Pending further research, a separate BIP proposing a method to allow quantum safe recovery of legacy UTXOs, likely via zero knowledge proof of possession of a corresponding BIP-39 seed phrase.

It is funny how this quotes McKinsey at one point, a company that is known to be full of bullshit and for ruining many things that they got their hands on. Names matter people, the truth is pointless.  



The issue here is that Phase C is not guaranteed. If it is guaranteed then the freezing can be somewhat more defended as people would still have the option to recover their coins regardless of how old they are. Thoughts, @d5000? It mentions explicitly compatibility with an Hourglass style proposal at the very end, so I thought you'd definitely be interested in it.

Furthermore, the proposal still does not specify which quantum-safe signatures we are going with (it is not supposed to anyway) and as such we are stuck at the same position as we have been the whole time. It does not make sense to vote on this BIP until such signatures are chosen, therefore this is mostly a thing to be done after. This is simply due to the fact that we do not know the exact implications that such signatures are going to have on the transaction throughput, and whether even migrating within the given period at time will even be feasible without a block size increase. Someone could run an estimate based on the number of UTXOs that are applicable and how much total block space we would need to migrate everything.

[BayAreaCoins]

Unreal that the conversation of bad actors attempting to steal Bitcoins is even a thing.

Not shocking because they do it in Testnet too, but my god...

Lopp is a bad actor hands down.

[Accardo]

Unreal that the conversation of bad actors attempting to steal Bitcoins is even a thing.

Not shocking because they do it in Testnet too, but my god...

Lopp is a bad actor hands down.

He calls it a contingency plan, which he hopes never gets implemented, if the quantum computing progression stall out, meaning he assumes it's the best thing to do regarding the dormant legacy wallets vulnerable to the quantum attack. This phony proposal is a big threat to the Bitcoin network, trust is almost creeping out, and most big whales could sell their big holdings to have a safe rest on their assets, the whole argument is getting out of hand and investors could get restless over the steady weird development, diminishing the whole point of long term holding.

[d5000]

Is everything accepted as a BIP these days? Who's in charge of the BIP repository? (This is IMO almost more concerning than quantum computers.)

I also don't see where this is really different from the original proposal. I originally thought it was limited to P2PK and other public-key revealing scripts. But the BIP actually is clear: "legacy" means also scripts that can't be hacked by quantum computers until they're spent.

Even worse: I think the recovery mechanism should be implemented BEFORE the "blocking" is even considered. We have already a candidate proposal from Tadge Dryja. And 3-5 years until activation are too long. Now we have no idea how far away a quantum threat is. In 5 years we may come to the conclusion that Quantum Day is still 10+ years away, with our funds already blocked ... Such a BIP should be clearly an emergency BIP, i.e. activation should be at most 2 years away, and activated when there is already a clear path to a quantum computer who can run Shor's algorithm for ECDSA.

So my thoughts are the same than about the original one: Ignore. Next.

Furthermore, the proposal still does not specify which quantum-safe signatures we are going with

I guess this is meant as a follow-up to BIP-360, which in its second phase would select a post-quantum algorithm.

For me a more reasonable one would be the following:

- Next 1-2 years: Implement SHRIMPS (and maybe SHRINCs too, for cold wallets it may be an interesting option). So we have already a candidate, even if it is still not very attractive, for big hodlers to switch their coins to post-quantum if they want to.
- Pre-Q Day (when a clear path to a Shor-capable QC is visible on the horizon): Block P2PK/P2MS, disallow P2TR keyspends for new P2TR transactions. Implement recovery mechanism.
- The ECDSA/Schnorr blocking contingency plan should be activated in a 2-step process: On Pre-Q-Day, it is decided that in at least 1 year, the blocking can be activated with another 1-year waiting phase.

Almost nobody's coins would be unsafe (with the exception of P2PK/P2MS/P2TR keyspend and reused addresses): If Tadge Dryja's mechanism is implemented, then all coins on un-reused addresses are safe and can be sent with the recovery mechanism to a PQ address.

[stwenhao]

Is everything accepted as a BIP these days?

Maybe not "everything", but definitely a lot:

Stumbled upon this ... I wonder how this got accepted as a BIP? Wasn't there a quite length-ish process for BIPs to be accepted which had to be fulfilled by the proposers?

No, the process was always essentially to publish virtually anything so long as the proposers applied with some relatively trivial formalities and there are plenty of pretty awful bips.  But for a long time Luke-jr was the only person doing anything and he'd just sit on stuff forever, so that did rate limit it.  More recently there are new editors who are no longer letting things languish and have also leaned into the original principal of being generally permissive.  But still even the simplest of formalities still stops a lot of people.

Hopefully some of the harm of crappy bips will be mitigated by more crappy bips, and will help shake people out of believing that because there is a bip number assigned that it's something anyone should implement.

Who's in charge of the BIP repository?

If you assume, that every BIP should be implemented, then you are wrong. Basically, BIPs are just used for standardizing things. They only reflect the point of view of the authors. And they are used just for coordinating things, like "I, as the author, want to do X, if you agree, then you can implement it in a compatible way". In decentralized consensus, it is mainly needed, just to group similar ideas together: because for example if you implement Silent Payments differently than in BIP-352, then you could end up with people, sending coins to each other, which wouldn't be visible by the second party, if the scanning would be completely different.

And similarly, for quantum proposals, it should be more or less clear, what people are going to support: if they accept freezing coins or not. If they want to block some things permanently, and make them recoverable only with a hard-fork, or if they will just put a huge locktime, and make them movable later in a backward-compatible way. And for things like that, it doesn't really matter, which algorithm would you pick: the decision to freeze or not to freeze, is the same in all cases. Currently, I don't see the case, where someone would want to freeze coins for "foobar" signatures, but not freeze them for "barbaz" signatures.

I originally thought it was limited to P2PK and other public-key revealing scripts.

No. Every time, when you have OP_CHECKSIG, or its equivalent, then it is applicable. The whole Lightning Network works on public keys.

Almost nobody's coins would be unsafe (with the exception of P2PK/P2MS/P2TR keyspend and reused addresses)

I don't know why people think, that breaking secp256k1 with 128-bit security would be faster, than reaching RIPEMD-160 collisions, where they have 80-bit security against collisions.

What will cause a bigger FUD: a theoretical quantum computer, which could break random public keys in theory, or a real classical computer, which could spend coins from the same 160-bit address in two or more different ways?