Elephant in the room: Quantum computers will destroy Bitcoin
Someone had to say it. Maybe the current drop is normies finally waking up and realizing that extrapolated accelerating developments in quantum computers will break encryption used in Bitcoin within 5 years.
It's also extremely naive to assume it will be easy to transfer a massive decentralized project to a post-quantum algorithm. Maybe new cryptos will be invented, but Bitcoin will not "retain value".
Things that will retain value if the entire internet is broken due to rapid deployment of quantum computers will be:
- Real estate
- Physical assets (gold, silver, etc)
- Physical stock certificates (printed on actual paper)
- Paper money
Since internet, cards, finance may just stop functioning one day as quantum computers break all encryption.
Feel free to prove me wrong.
18 comments
[ 4.4 ms ] story [ 58.1 ms ] threadInstead of ranting in public maybe study subject like hour or so.
It could derive private key from public key.
And how will you solve this?
Only quadratic speedup for most problems, like search. That's why hash functions with key size 256 or higher are safe, for example.
It’s naive to assume miners will not sufficiently coordinate to stop Bitcoin becoming worthless. They are all economically incentivised to keep the network continuing to function.
There will likely be different character lengths for account addresses and keys, so all of the DNS+HTTP web services and HTTP web forms built on top will need different form validation.
Vitalik Buterin presented on this subject a few years ago. Doubling key sizes may or may not be sufficient to limit the risk of quantum attacks on elliptical curve encryption algorithms employed by Bitcoin and many other DLTs.
The Chromium browser now supports the ML-KEM (Kyber) PQ cipher.
Very few web servers have PQ ciphers enabled. It is as simple as changing a text configuration file to specify a different cipher on the webserver, once the ciphers are tested by time and money.
There are patched versions of OpenSSH server, for example, but PQ support is not yet merged in core there yet either.
There are PQ ciphers and there are PQ cryptographic hashes.
There are already PQ-resistant blockchains.
Should Bitcoin hard fork to double key sizes or to implement a PQ cipher and hash?
Spelunking for Bitcoin by generating all possible keys and checking their account balances is not prevented by PQ algorithms.
Banking and Finance and Critical Infrastructure also need to upgrade to PQ ciphers. Like mining rigs, it is unlikely that existing devices can be upgraded with PQ software; we will need to buy new devices and recycle existing non-PQ devices.
If banks are on a 5 year IT refresh cycle, that means they need to be planning to upgrade everything to PQ 5 years or more before a QC quantum computer of a sufficient number of error-corrected qubits is online for adversaries that steal cryptoassets from people on the internet.
PQ or non-PQ does not predict asset price in 2025-02.
Breach disclosures apparently hardly affect asset prices; which is unfortunate if we want them to limit their and our taxable losses.
Where is this pending HF for BTC?
How can all of this work realistically without constant cat & mouse catch up game?
> Spelunking for Bitcoin by generating all possible keys and checking their account balances is not prevented by PQ algorithms.
So there will be no protection against this? There is no protection possible?
Other DLTs also have numbered document procedures for managing soft forks, hard forks, and changes to cipher and hash algorithms.
Litecoin, for example, is Bitcoin with the scrypt hash algorithm instead of SHA256.
Proof-of-Work mining rigs implement hashing algorithms in hardware as ASICs and FPGAs.
Stellar and Ripplenet validation servers still implement same in software FWIU?
Are there already ASICs for any of the PQ Hash and Cipher algorithms?
SSL Termination is expensive but necessary for HTTPS Everywhere and now HTTP STS Strict-Transport-Security headers and the HSTS preload list.
Are there still ASIC or FPGA SSL accelerator cards that need to implement PQ ciphers and hashes?
Multisig and similar m:n smart contracts support requiring more keys for a transaction to complete.
Rather than in an account with one sk/pk pair, funds can be stored in escrow such that various conditions must be met before a transaction can move the funds.
Running a full node helps the network by keeping another copy online and synchronized. A full node can optionally also index by transaction id (with LevelDB).
The block and transaction messages can be logged and monitored. Though it doesn't cost anything to check a balance given authorized or forged keys.
Spending the money in a bitcoin account discloses the public key, whereas only the double hash of the pubkey is necessary to send money to an account or scriptHash.