Can Quantum Computer's destroy Blockchain and Bitcoins[SHA-256 specifically]

[d5000]

Just wanted to add a thought I had some days ago (have thought about it and I see no drawback until now).

Like garlonicon wrote in this post, most of we'd need to make Bitcoin "quantum-resistant" is to extend Bitcoin Script with mechanisms to handle other public key cryptosystems than ECDSA.

While there's surely a long way to go to get this implemented in the Bitcoin protocol, one could imagine an extension protocol for tokens based on the OP_RETURN mechanism, like OmniLayer, supporting interesting quantum-resistant cryptosystem candidates first, which would be possible much faster (they could simply copy/paste parts of the algo of this shitcoin which was promoted in this thread by a certain FUDster ). You could then not only create Tether-like centralized tokens which are quantum resistant, but also in theory an 1:1 pegged Bitcoin stablecoin - the easiest way would be using a proof-of-burn scheme, where each bitcoin burnt would entitle its owner to create one unit of the quantum-resistant Bitcoin stablecoin (we could call it QBitcoin).

If the threat becomes real at some point and Bitcoin extends its Script language to support a quantum-secure algorithm, then it should be possible to "merge" the QBitcoin with the "old" upgraded Bitcoin. This would be a way to ensure QBitcoin's peg with Bitcoin holds, although maybe not absolutely necessary.

I write this mostly because if someone is really worried about quantum computers then this could be possibly a straightforward path for Bitcoin to achieve quantum resistance step by step, without having to wait for a complete, thoroughly-tested implementation - and no shitcoin is really needed.

By the way, I wonder if Simplicity, if it gets included into Bitcoin, could provide the necessary functions for "quantum resistant addresses"? In the whitepaper it's mentioned that it's "expressive enough to represent any finitary function", so wouldn't "quantum computer resistant cryptography" be a possible use case?

[1715226003]

1715226003

[1715226003]

1715226003

[1715226003]

1715226003

[1715226003]

1715226003

[casinotester0001]

.. most of we'd need to make Bitcoin "quantum-resistant" is to extend Bitcoin Script with mechanisms to ...

What will we make with early mined coins that haven't been moved since ~2010, eg. Satoshi's coins?

[d5000]

.. most of we'd need to make Bitcoin "quantum-resistant" is to extend Bitcoin Script with mechanisms to ...

What will we make with early mined coins that haven't been moved since ~2010, eg. Satoshi's coins?

If they're "lost", i.e. nobody has access to them anymore, there would be no way to protect them with the exception of harsh methods like the blocking of these addresses/utxos (something similar Ethereum did when TheDAO was exploited).

I personally would be against this - I'd rather be ok if they're "stolen" and dumped, even if this meant a sudden price crash. Distribution afterwards would probably be better, and I expect only short term price turbulences. Take into account that if these coins were mined by a single entity (most likely Satoshi) then there is always the danger that they're suddenly moved and be sold, either because Satoshi himself is selling them, or because his computer was hacked (he should have had some knowledge how to secure his data, but nothing is impossible). This danger would then be gone forever, so I expect a quick price recovery. (Anyway, quantum computers would have to solve each address separately, and at first they would be rather slow with that task. So the dumping process could be pretty long - at least if the "dumpers" wanted to maximize profit - and maybe thus the amounts would be too low to generate much panic)

[casinotester0001]

...

exactly.

I think that Satoshi thought about it and made the same decission like you described it here. Let them move 

[o_e_l_e_o]

If they're "lost", i.e. nobody has access to them anymore, there would be no way to protect them with the exception of harsh methods like the blocking of these addresses/utxos (something similar Ethereum did when TheDAO was exploited).

That's not entirely true. It would be possible to lock some coins in a way in which the original owner could move them but a quantum attacker reversing the ECDLP could not steal them. This would be done by requiring some proof, ideally a zero knowledge proof, of possession of the seed phrase or master private key which was used to derive the relevant private key. The true owner who had derived the private key in an HD wallet would be able to provide this proof, while a quantum attacker who had obtained the private key from the public key would not.

The downside to this approach is two-fold, though. Firstly, it only protects reused HD addresses, and does nothing for the 1.73 million BTC in P2PK addresses. Secondly, there is no way of knowing which addresses were generated in an HD manner and which were not, which would mean some coins being locked forever and being irrecoverable by anyone, the true owner included.

[Babu590]

Are there any puzzle or Crypto vendors for your Bitcoin Crypto Grafix.
You believe you won't take any keys and you'll catch them at another party?
So think we are far behind and your attacks will be successful, think about it .

[d5000]

That's not entirely true. It would be possible to lock some coins in a way in which the original owner could move them but a quantum attacker reversing the ECDLP could not steal them. This would be done by requiring some proof, ideally a zero knowledge proof, of possession of the seed phrase or master private key which was used to derive the relevant private key. The true owner who had derived the private key in an HD wallet would be able to provide this proof, while a quantum attacker who had obtained the private key from the public key would not.

Interesting. I wonder how would this be done technically, is this mechanism described anywhere? My doubt is about how "the blockchain" (i.e. the Bitcoin client in combination with the blockchain data) can know about HD seed phrases / master public keys. All what is stored on the blockchain (from my knowledge) are signatures, public key hashes and (in the case of P2PK) public keys, can you derive information about the HD "master key" from one of these elements?

[BlackHatCoiner]

[...]

Thirdly, there's no HD standard. Most wallet software have adopted BIP39, Electrum & Armory have their own (AFAIK), etc. But the protocol recognizes no deterministic keys; that's something the Bitcoin community - and specifically some developers - have invented unofficially and nonconsensually. Therefore, such change is beneficial subjectively, because you can't include all wallet software's HD rules nor there is a "neutral" list of those software.

And even if there was such list, you're burdening full node's cost, because it now has to verify computationally expensive functions such as PBKDF2 and HMAC-SHA256, that can be deliberately abused to establish an attack successfully. For example, I can provide a zero-knowledge proof of my HD wallet in which I used millions of PBKDF2 rounds to generate.

[theogonies]

Have been researching QC's and bitcoin for months. It is not clear from many sources of the World Wide Web whether or not QC is a threat to the sha256 of Bitcoin.
1.Can we if possible mine more than the specified value of BTC in less than a minute with the help of a powerfully-eligible Quantum Computer?

Agree that QC's can destroy Elliptic Curve Digital Signature Algorithm and steal our private keys. So considering all of the above threats,

2.Is it possible to fork Bitcoin and solve the following problems?

3.How to secure the SHA256 encryption and make it immutable to QC attacks?

I am pretty sure, Satoshi Nakamoto must have thought about the possible problems there has to be a solution, but exactly where?

Researching for months but didn't somehow come across this?

SHA-256 is very strong.  It's not like the incremental step from MD5 to SHA1.  It can last several decades unless there's some massive breakthrough attack.

If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.

If the hash breakdown came gradually, we could transition to a new hash in an orderly way.  The software would be programmed to start using a new hash after a certain block number.  Everyone would have to upgrade by that time.  The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.

...