Author

Topic: Could alternative (e.g. post-quantum) cryptography be introduced via BitVM? (Read 121 times)

copper member
Activity: 909
Merit: 2301
Quote
However, the idea with BitVM is that any cryptosystem could be emulated.
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.

Quote
The Bitcoin developers would have some time more to decide which algorithm is the best one
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.

Quote
I'm however not sure how much must be posted on-chain in the case a spend is contested.
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

Quote
if BitVM can/should be used for this purpose
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).
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
It is better to make a regular soft-fork in that case: https://groups.google.com/g/bitcoindev/c/p8xz08YTvkw
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.

It shouldn't matter, because you shouldn't put everything on-chain. See: https://bitcointalksearch.org/topic/really-really-ultimate-blockchain-compression-coinwitness-277389 (this topic contains the word "witness", but it is not about Segwit).
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.

Even if ECDSA will be broken, then still, there are scripts you can do, which could be safely used,
Interesting Smiley Will try to investigate about this.

Well, there are some posts. Here is another one: https://groups.google.com/g/bitcoindev/c/SPmrzARLMFU
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).
copper member
Activity: 909
Merit: 2301
Quote
Would this be possible?
It is better to make a regular soft-fork in that case: https://groups.google.com/g/bitcoindev/c/p8xz08YTvkw

Quote
I can imagine the "simulation algorithm" to be enormous, like the gigabyte-big ZK provers.
It shouldn't matter, because you shouldn't put everything on-chain. See: https://bitcointalksearch.org/topic/really-really-ultimate-blockchain-compression-coinwitness-277389 (this topic contains the word "witness", but it is not about Segwit).

Quote
Or are there unsurmountable challenges?
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.

Quote
Was this perhaps even discussed in some technical forum or mailing list already?
Well, there are some posts. Here is another one: https://groups.google.com/g/bitcoindev/c/SPmrzARLMFU
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
It is possible that eventually ECDSA (the cryptosystem Bitcoin uses for its PKS, i.e. private and public keys) is broken, be it due to quantum computers or an undiscovered flaw.

Of course the developers could add opcodes for challenges in alternative cryptosystems once this becomes a real issue, and currently it seems very far away and it may even be impossible or in the far future. But judging by the fact that all the time threads are opened about quantum computers and how they could "destroy" ECDSA and Bitcoin (and even SHA256 according to some), perhaps it could make sense to offer this alternative earlier -- and to end the quantum computer FUD once and for all time.

With BitVM we now have a working concept to "emulate" all kinds of programs with Bitcoin Script via "logic gates" built into a special kind of transactions.

There have been lots of ideas with BitVM already, but I haven't seen the use case to "emulate" post quantum cryptography.

Would this be possible? I can imagine the "simulation algorithm" to be enormous, like the gigabyte-big ZK provers. But in theory it should be possible to build a "challenge" based on alternative cryptosystems to "lock" a coin so it is spendable only with the "post-quantum" keys. Or are there unsurmountable challenges? Was this perhaps even discussed in some technical forum or mailing list already?
Jump to: