Can we bring in alternative (like post-quantum) cryptography with BitVM?

There's a chance that ECDSA, which is what Bitcoin uses to generate its private and public keys, could get compromised sometime in the future. This could be because of quantum computers or some vulnerability we haven't found yet. Sure, developers could introduce opcodes for alternative cryptosystems when it becomes necessary, but that seems far off right now. And some folks even think it might be impossible or way down the line. But considering how often discussions pop up about quantum computers potentially wrecking ECDSA and Bitcoin (and even SHA256, according to some), it might be wise to consider offering alternatives earlier on to shut down the quantum computer FUD for good. With BitVM, we have a way to mimic various programs using Bitcoin Script through these "logic gates" embedded in a unique type of transaction. There have been tons of ideas floated around with BitVM, but I haven't really seen anyone talk about using it to simulate post-quantum cryptography. Is that even feasible? I can imagine the "simulation algorithm" could be massive, like those huge gigabyte-sized ZK provers. But theoretically, it should be possible to create a "challenge" that locks a coin so it can only be used with "post-quantum" keys. Or are there some major hurdles we just can't get past? Has anyone discussed this in any technical circles or mailing lists?

It is better to make a regular soft-fork in that case: https://groups.google.com/g/bitcoindev/c/p8xz08YTvkw It shouldn't matter, because you shouldn't put everything on-chain. See: https://bitcointalk.org/index.php?topic=277389.0 (this topic contains the word "witness", but it is not about Segwit). Even if ECDSA will be broken, then still, there are scripts you can do, which could be safely used, even in that kind of scenarios. For example: "OP_SHA256 OP_CHECKSIG" is one of those Scripts, where you have to put a message, which will hash perfectly into x-value of the public key, and will pass Schnorr signature verification. Another example is "Pay to Proof of Work", when you require a DER signature below N bytes. So, even if OP_CHECKSIG will lose its original meaning, then still, it will then be just a calculator, working on 256-bit numbers. But: it will be possible to mount another challenge, where you would need many OP_CHECKSIGs, to move the coins. And they can be wired in a way, where knowing the private key will give you no advantage, because the challenge will require solving dependencies between keys, and not the keys alone. Well, there are some posts. Here is another one: https://groups.google.com/g/bitcoindev/c/SPmrzARLMFU

Interesting that this was brought up very recently, perhaps due to the recent news of Chinese researchers which used D-WAVE annealing quantum computers to optimize an approach to crack RSA. However, the idea with BitVM is that any cryptosystem could be emulated. The Bitcoin developers would have some time more to decide which algorithm is the best one, and then could opt for a soft fork in the late 2020s or even in the 2030s, when the algorithms have been tested extensively. Meanwhile those who already want to secure their Bitcoins with a "candidate" post-quantum algorithm (or any "more advanced" cryptographic algorithm) could do it. Yes, this was already known to me. I'm however not sure how much must be posted on-chain in the case a spend is contested. Interesting Will try to investigate about this. It seems also to be a fork proposal and not based on BitVM. I've still not found anything regarding the question (if BitVM can/should be used for this purpose).

Yes. But it is costly, if you have to put all of that on-chain. It is much better to just have some external proof, and only commit to it on-chain. For example: something like this sudoku puzzle: https://github.com/zcash-hackworks/pay-to-sudoku Imagine how more complex everything would be, if you would push the whole NxN sudoku puzzle inside the input script. No matter what you pick, it should be deployed on some kind of test network first anyway. So, no matter if it would be a soft-fork, or a long Script, the way of deployment is similar. If you have some external proof, then in most cases, you cannot spend the coin on-chain, if you don't know the solution. And if some different elliptic curve is used, then you can use a DLEQ proof: https://groups.google.com/g/bitcoindev/c/MezoKV5md7s I guess not, because if you have to put a lot of data on-chain, then it is an equivalent to shrinking the maximum block size. And those limits will not be lifted in the nearest future, because it would only open a wide door for some spam, and the amount of real coin usage will be left unchanged (or even some users will switch into other networks, as a result).