Pages:
Author

Topic: Can Quantum Computer's destroy Blockchain and Bitcoins[SHA-256 specifically] - page 4. (Read 1787 times)

sr. member
Activity: 1190
Merit: 469
I think this is somebody who wants to profit from the fear of some Bitcoiners about "quantum computers hacking the blockchain!!" luring people into his shitcoin.
I don't see the point in any "quantum resistant" coin at the moment when we are still decades away from quantum computers being a threat to elliptic curve cryptography. Whatever quantum resistant algorithm they implement today will either be completely outdated by the time it is relevant (so maybe things such as much larger signatures and transactions than necessary, far less functionality allowing for different script/address types, much more resource heavy or slower to computer/verify, etc.), or might itself be broken and completely insecure.

It would be like a video game developer building a game today which won't be released until 2045 for the PlayStation 9. They have no idea what the technology will be or what its capabilities will be 20 years in the future, and whatever they come up with today will be incredibly outdated and might not even work by the time it becomes relevant.



Well, it's not just that. Another problem is these Post Quantum algorithms aren't really vetted in the sense like AES encryption is or say Elliptic Curve is. They dont have decades of trying to crack them so they might even be vulnerable to a normal computer to say nothing of a Quantum Computer. Bitcoin might be better off sticking to what it has than going with a shiny new object that ends up being cracked by a pentium 4 laptop running for a weekend or two. There's nothing magic about post quantum crypto it's still a game of cat and mouse. No one can prove anything... Angry As long as they keep trying to rely on complexity, they're in trouble. Complexity should be in quotation marks that is.
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
BTW, that's just for one type of addresses. If you wanted both Legacy (1) and SegWit (3, bc1) you'd have to triple the effort.

With recent Taproot update, actually it's 4x effort. Native SegWit have prefix bc1q while Taproot have prefix bc1p.

You could find ways to compress all this, though. For instance, private key 1 doesn't need to take 32 bytes.

Alternatively don't store private key without coin.
legendary
Activity: 2268
Merit: 18711
You could find ways to compress all this, though. For instance, private key 1 doesn't need to take 32 bytes.
Sure, but I'm just pointing out how infeasible this would all be. Compression would save some time, but I also glossed over that for each and every key you would also need to perform an elliptic curve multiplication, four hash functions, and a hex to Base58 conversion, all just for the legacy addresses. And then of course you would need to look the address up against a full node to see if it contains any coins. And even if you someone managed to compress a billion private keys in to the space usually occupied by a single private key (32 bytes), you're still looking at needing an entire galaxy filled with Dyson spheres to have the energy to do something like this.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
[...]
Plus: You would need to find a way to transfer information unbelievably fast. Even if one planet in one of those galaxies found a collision, they had to somehow share it with others. Good luck on that too!  Tongue

BTW, that's just for one type of addresses. If you wanted both Legacy (1) and SegWit (3, bc1) you'd have to triple the effort.

2256 private keys * 32 bytes each = 3.7*1054 yottabytes.
You could find ways to compress all this, though. For instance, private key 1 doesn't need to take 32 bytes.
legendary
Activity: 2268
Merit: 18711
What I was imagining was a computer that tried all possible outcome for private keys in one run.

At once. No queue.
2256 private keys * 32 bytes each = 3.7*1054 yottabytes.

Current estimates for the amount of data ever created in the entire world are less than 0.2 yottabytes.

So even if there were 1 billion galaxies, each with 1 billion planet Earths, and each Earth produced a billion times more data than us, and each Earth had been churning out this much data for a billion years, you still need a computer which can handle a billion billion times more data than that all at once.

Good luck.
sr. member
Activity: 1572
Merit: 267
What I was imagining was a computer that tried all possible outcome for private keys in one run.

At once. No queue.
hero member
Activity: 1274
Merit: 561
Leading Crypto Sports Betting & Casino Platform
QC is actually a way for brands like Microsoft to get funds from investors. Quantum computer cannot exist in the first place because of the number of qubits required to solve a cryptographic problem is much and they are fragile too. The qubits cannot stay in some environments. It depends on weather conditions.
legendary
Activity: 2268
Merit: 18711
In this case, the blockchain and all values are 0 and cannot be moved.
Even ignoring that it will be decades before there is a quantum computer which can solve the ECDLP, it will be many more years between one can that solve the ECDLP over a period of weeks and one which can solve the ECDLP in less than the 10 minutes required to attempt to double spend an unconfirmed transaction.

Unclaimed coins can be used.
I don't think we should intervene here. We have absolutely no way of knowing which coins are simply being held long term by their owners and which coins are lost or otherwise inaccessible. The network and the community absolutely shouldn't be taking decisions to deprive the rightful owners access to their coins, even if the inaction of these owners to move their coins to a quantum resistant address will result in their coins being stolen.
member
Activity: 73
Merit: 19
the problem here is not sha256
The problem is that the private key of the pubkey entering sha256 is broken.
if ECDLP of secp256k1 is decrypted.
then we can talk about this apocalypse.
In this case, the blockchain and all values are 0 and cannot be moved.
If we want to move the values, we can do it according to the priv key, but we can't because it breaks. I think new blockchain movable with losses. bitcoin can suffer serious damage from this. Unclaimed coins can be used.
legendary
Activity: 2268
Merit: 18711
I think this is somebody who wants to profit from the fear of some Bitcoiners about "quantum computers hacking the blockchain!!" luring people into his shitcoin.
I don't see the point in any "quantum resistant" coin at the moment when we are still decades away from quantum computers being a threat to elliptic curve cryptography. Whatever quantum resistant algorithm they implement today will either be completely outdated by the time it is relevant (so maybe things such as much larger signatures and transactions than necessary, far less functionality allowing for different script/address types, much more resource heavy or slower to computer/verify, etc.), or might itself be broken and completely insecure.

It would be like a video game developer building a game today which won't be released until 2045 for the PlayStation 9. They have no idea what the technology will be or what its capabilities will be 20 years in the future, and whatever they come up with today will be incredibly outdated and might not even work by the time it becomes relevant.

legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
I think this is somebody who wants to profit from the fear of some Bitcoiners about "quantum computers hacking the blockchain!!" luring people into his shitcoin.

Iota tried this, too, but they're now worth much less than before. I wouldn't call them outright scams still, but quantum resistant cryptography has much less testing until to date than traditional algorithms, and this coin was created in 2017 so it has even less testing than "current" quantum resistant algos (they may be hardforking to newer crypto algorithm versions - but Bitcoin could do that, too, in theory, so they haven't any advantage).

Stay away.
member
Activity: 73
Merit: 19
Hello
someone else mentioned this
do you mean something like this?

https://coinmarketcap.com/cryptown/profile/xufd90jiwedh?guid=77572615

"Quantum Apocalypse"
I think it's trying .

Thanks.
legendary
Activity: 2268
Merit: 18711
Yes, but all P2TR addresses has an option to spend by key.
For now, sure. But there is nothing stopping us from implementing script-path only taproot addresses or even just hashing P2TR addresses and creating some P2PKH-P2TR hybrid, which would allow us to use taproot addresses in a more quantum resistant way prior to the implementation of whatever full quantum resistant scheme we end up with.
copper member
Activity: 901
Merit: 2244
Quote
How will I stay in a network where blocks contain transactions that I consider invalid?
You will stay in a network if you make them non-standard (that would be no-fork). You will also stay in a network if some soft-fork will make them invalid and you will use some old version.

Quote
Still, with taproot you can use specific script-paths rather than use key-paths at no extra cost to avoid the issue of your public key being revealed.
Yes, but all P2TR addresses has an option to spend by key. And if P2PK is broken, then you can ignore a script path (that can be even some unspendable OP_RETURN) and use key path. Only P2TR coins sent to invalid public keys can be considered unspendable by consensus, for example when you send coins to bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpqqenm (on the other hand, bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqs5pgpxg seems to be unspendable, but it may be, if you somehow reach the private key for 020000000000000000000000000000000000000000000000000000000000000001).
legendary
Activity: 2268
Merit: 18711
If P2PK coins are vulnerable, then P2TR coins also are. In both cases you reveal your public key.
As are all the coins in reused addresses. As are all the coins in light wallets which send master public keys to servers to look up their balances. As are all the coins received via payment processors where the user uploads their master public key to generate new addresses for each customer. And eventually, as are all coins as soon between the time they are spent and they are confirmed.

Taproot was never designed to be quantum resistant. Still, with taproot you can use specific script-paths rather than use key-paths at no extra cost to avoid the issue of your public key being revealed.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
You can run a node and make P2PK non-standard in your node (and reject all transactions that create or spend any P2PK coins), you will stay in the network if you do that.

How will I stay in a network where blocks contain transactions that I consider invalid?
copper member
Activity: 901
Merit: 2244
Quote
Isn't invalid today to consider P2PK unspendable? It's currently spendable.
It is perfectly valid. You can run a node and make P2PK non-standard in your node (and reject all transactions that create or spend any P2PK coins), you will stay in the network if you do that. If most nodes will do that, then in practice P2PK will be unspendable by any average user. It is the same as in case of Value Overflow Incident: you can run some old node with old rules, you can create a transaction that will create coins out of thin air, but your transaction will be ignored by other nodes. On the other hand, you will still stay in the network, as long as the heaviest chain moved to the new rules. So, making P2PK non-standard is a no-fork solution that can work right now. Soft-fork is just one step further, where you make P2PK invalid and reject blocks, in the same way as you reject P2TR blocks without signatures (but they were accepted in the past), and in the same way as you reject blocks creating coins out of thin air because of Value Overflow Incident.

Quote
How would the new Scripts resist? Are you saying that we wouldn't need a resistant algorithm?
And how would P2TR resist? We just moved to "OP_1 ". We can move to "OP_2 " in the same way (if calculating the private key for any public key will be possible and P2TR will be vulnerable) and add any rules, any algorithm we want, for example it can require lattice-based signature. The same with script, we have tapscript with OP_CHECKSIGADD, it is entirely new Script version, where we have OP_SUCCESS opcodes, and where OP_CHECKMULTISIG(VERIFY) is invalid. If only spending by key in P2TR will be vulnerable, we can force spending by script, invalidate OP_CHECKSIG(ADD) and force using some new OP_SUCCESS that can be replaced for example by OP_CHECKLATTICE.
legendary
Activity: 1512
Merit: 7340
Farewell, Leo
In hard-forks "things invalid today are valid tomorrow", but we don't need that.
Isn't invalid today to consider P2PK unspendable? It's currently spendable.

If ECDSA will be broken, we would need just another Scripts, nothing more than that.
How would the new Scripts resist? Are you saying that we wouldn't need a resistant algorithm?
copper member
Activity: 901
Merit: 2244
Quote
What we do about the vulnerable P2PK coins is another matter.
If P2PK coins are vulnerable, then P2TR coins also are. In both cases you reveal your public key. More than that: everything that is "ongoing", just transactions sitting in mempools are also vulnerable in exactly the same way, because when you spend your coins, you reveal your public key. Not to mention all situations, where you have any multisig, for example in the Lightning Network, where all public keys are known by all members of the channel.

Quote
I don't like hard forks, but I assume this can be tackled that way without damaging the owners of those addresses.
Making coins unspendable would be a soft-fork, because "things valid today are invalid tomorrow", that's how soft-forks work. In hard-forks "things invalid today are valid tomorrow", but we don't need that.

If ECDSA will be broken, we would need just another Scripts, nothing more than that. Instead of " OP_CHECKSIG", there would be " OP_NEWCHECKSIG", probably with a better name than "new checksig". Also, it depends what will be broken and what kind of attack will be possible. Because if it will be possible to make a fake signature for a given z-value without knowing the private key and without knowing secret k-value, that's completely different situation than when it will be possible to recover any private key.
copper member
Activity: 2996
Merit: 2374
I am pretty sure, Satoshi Nakamoto must have thought about the possible problems there has to be a solution, but exactly where?
There are a couple of quotes from Satoshi I am aware of which are relevant here:

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.

However, if something happened and the signatures were compromised (perhaps integer factorization is solved, quantum computers?), then even agreeing upon the last valid block would be worthless.
True, if it happened suddenly.  If it happens gradually, we can still transition to something stronger.  When you run the upgraded software for the first time, it would re-sign all your money with the new stronger signature algorithm.  (by creating a transaction sending the money to yourself with the stronger sig)

Quantum computers will not break bitcoin overnight. It will take decades of slow progress that everyone can see coming before they become a threat, and they will break many other weaker algorithms along the way. They also only provide a linear increase in the speed to find a hash collision (as opposed to an exponential increase in the speed to solve the ECDLP), and so are unlikely to be able to break SHA256. But if it ever was to become a concern, then as Satoshi has said above, we will have plenty of time to transition in an orderly way to new quantum resistant functions and algorithms.
A hash function, such as SHA256 is intended to be a one-way function. That means it is possible to get the output of a function based on the input, but not the input based on the output. The problem is that it not possible to know for sure that a particular function is in fact a one-way function. To my knowledge, no one knows how to calculate the input, based on the output of a SHA256 function. That doesn't mean that someone will not figure out how to "break" SHA256 in the future.

I don't think breaking SHA256 (if it gets broken), will necessarily be done via QC. SHA256 getting broken is still a risk.
Pages:
Jump to: