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

Latest Quantum Computer available commercially - D-Wave Quantum Computer
Costs: $15,000 (That too un-configured for Bitcoin Mining, coding will cost additional man's salary)

Quantum Computer Operation: Well you will probably need a room or at least superconductors which would be cooling down your 2000Qubic chip down to the -273 degree celsium.

If you have money then it's fine, buying computer worth $15 million wont be big deal for you. The question is would you be able to maintain the temperature below zero degrees all the time? Imagine the power consumption required to do that one.

Forget about break even point, you wont be able to recover the yearly power consumption out of the bitcoin mining.

If you start to inject the market with heavy supplies of bitcoin, assuming you are mining 1000x others, then ideally the supply will easily fill up the demand and might reduce in the pricing.

For example, Supercomputer in China, named Tianhe-2 use 18 megawatts of electricity.

In conclusion even if we use it, it wont be beneficial at all.

they're trying to develop it but new things aren't always so solid. you need time to try and crack them. like years and years. no one broken RSA in decades so it's pretty solid. but you can't say the same thing about most of this new stuff.

https://www.linkedin.com/pulse/post-quantum-almost-standard-completely-cracked-lessons-roger-grimes

you also have some mineable new blockchain based on NIST round 3 quantum resistant signature algorithms:
-Doge protocol https://dogeprotocol.org/
-Tidecoin https://tidecoin.org/
-Arielcoin https://arielcoin.org/

And QRL based on quantum resistant algorithm called XMSS:
https://www.theqrl.org/

start mining & accumulating till the day (soon in the future, maybe by 2025...) when quantum threat wipes out 99.99% of crypto market caps (BTC, ETH, etc)

It's NOT a token project. It's a brand new blockchain. True that it's being supported by a token right now. But according to their roadmap, token holders will swap their tokens for native coins on the new L1 quantum resistant Qanplatform blockchain.

what do you think of the token $QANX ? QANPLATAFORM

they said to have a solution for this.

thanks!

It is simple. If you want to do it in backward-compatible way, then it will be always slower than the current implementation. You will have new_computing_time=old_computing_time+upgraded_version. If that "upgraded version" is positive, then the total computing time will always be greater than today. For example, if old_computing_time=1 and upgraded_version=0.1, then it is ten times faster. But as long as the old version is not broken, it is 10% slower.

The mailing mention NTRU would make node perform extra validation, yet NTRU implementation show it's far faster than ECC-NIST (closest one to cryptography which Bitcoin use). Can someone explain why?


Source: https://tbuktu.github.io/ntru/

Don't worry, people know about it and there are some discussions on our mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020209.html

So, you think that not even the devs working on Bitcoin Core wouldn't see it coming in time of implementing Quantum resistance algorithms? I am sure they are aware and they are bright enough to see it coming. I mean, the technology must be developed, software must be developed and I don't believe that can be hidden from everyone up to a point that nobody will see it coming!

it would clearly be a profitable operation to run a qc, hacking few 1000s of btc/eth, then silently dump them to the sheep saying "quantum threat is decades away blablablabla". you won't see it coming even if you know that it's coming. And at first, it's clear that no individual or small organization will have access to such infrastructure, but some state sponsored actors or  big tech corps (Google, IBM, Microsoft, etc) would

I don't think it can. At least, in the upcoming few years, I think Quantum computers are still too expensive for someone to try such thing. I remember to watch a video quite some time ago and the video was explaining how hard it is to keep the computer running smoothly, how much energy it would spend and how would it cost, like per day, or something like that. The numbers were alarmingly high and the technology needed to keep the computer running was also large.

A part from that, I think there are already people working on Quantum resistant algorithms for when that time comes!

I agree. We've all heard and read the stories of people saying they have lost hard drives or wallets with hundreds or even thousands of bitcoin on them (although again, such stories are impossible to verify), and I'm sure the total number does add up to several hundreds of thousands. But the 4 million number we see bandied about on a lot of low quality clickbait articles is generally reached by someone saying "Look, all these coins haven't moved in 5/8/10 years, therefore they must be lost". Which, as I explained above, is highly inaccurate at best since we fairly regularly see such coins "waking up" and being moved or in some cases having a message signed from their private key(s).

Coins which are provably lost, meaning we are 100% sure they are lost and can never be retrieved (bugs, failed to be claimed by miners, OP_RETURN outputs, unspendable outputs, etc.) number only a few thousand. Anything more than that is speculation.

You are bringing up some good points/facts here, but I am sure there is a substantial amount that is not accessible. "Substantial" is relative here, I know, but I believe there have been people losing or killing their hard drives without thinking about cryptocurrencies breaking trillions of dollars of market cap one day. I know a nerd who mined Bitcoin in 2011 just because some other dude from World of Warcraft told him. They didn't really trade or anything and he actually lost or threw away dozens of Bitcoin. Not a crazy amount, but just didn't bother to take care of them. I would say that that guy is a prime example for people who haven't really tried to go down the rabbit hole and conduct research on all the different angles Bitcoin brings about (socially, politically, financially, technically, culturally, etc.), didn't really pay attention to the actual emergence of a global ecosystem and then just forgot about those coins or didn't give a damn.

I also doubt it is 4 million that could be lost, but it might add up here and there quite significantly, with some losses being pretty damn painful (probably in the thousands of Bitcoin) I would imagine.

Partly because of the answer garlonicon has given above, and partly because your average internet user is far less technically minded than your average bitcoin user. Most people are completely unaware how their computer works, how the internet works, how they communicate securely, and so on. Ask the average person the consequences of breaking SHA-256, and the response you will get is "What's SHA-256?" And the people who are working for the big tech companies on quantum resistant technologies aren't discussing their research in public forums, so we don't see it.

Absolutely the price would dip, but I'd much rather have a temporary dip in price than compromise the fundamentals of bitcoin itself. I also disagree strongly with the assumption that seems to be generally prevalent throughout the community that ~4 million coins are permanently lost. Just because a coin has not moved in x amount of time, does not mean it will never move. We not infrequently see coins dormant for 10 years start moving again, and a couple of years ago we saw for example a valid signature for over a hundred addresses containing thousands of bitcoin which hadn't moved since 2009 calling CSW a fraud, so we know that despite appearances many such coins are not lost and could indeed move at any time.

Because they don't use any blockchain. If you have just some software, you can change things in backward-incompatible way, if you have v1.0 of your software, you can just switch to v2.0 and do things in a completely different way. For example, if you store UNIX time as a 32-bit number, you can just extend it to 64-bit number. In case of a blockchain, it would be backward-incompatible, so it will be rejected, and finally accepted only if nobody has any better, backward-compatible idea.

Hash functions were replaced in the past. In centralized environment, it is easier to get rid of MD5 and use SHA-1 instead. The same with switching from SHA-1 to SHA-2. And it could be exactly the same in switching from SHA-2 to something else. Also, guess what: MD5 is broken only if it comes to collision-resistance, we still have no idea, how to produce a zero hash in case of MD5 (so we still don't know how to do any preimage attack on this hash function).

so why isn't the rest of the internet worried about this issue as much as bitcoin users? i guess they are just keeping their head in the sand thinking its someone elses problem to solve and when we finally "get there" someone else will have solved it?



that's an interesting opinion. expect a dip in price if that happens but people shouldn't complain if it did happen. after all. they are valid coins. just because no one expected them to be used doesn't mean they shouldn't be able to be.

Fixing asymmetric cryptography without touching hash functions is far easier. You can use ECDSA to spend coins from old addresses and move them for example to "OP_2 ". Then, that address type could require lattice-based signature or anything-based signature you want. Also, if you don't want to introduce a new address type, then you can require spending by TapScript instead of spending by key and redefine any OP_SUCCESS to OP_CHECKLATTICE and make scripts like " OP_CHECKLATTICE". It could be OP_CHECKANYTHING, it could be based on the new algorithm. It would work if you can break ECDSA, but if you cannot break SHA-256.

But yes, that case has the same problem: there is no consensus, no proposal, no BIP, so it should be made first.

Quote

How's a rehashed blockchain useful?

It is needed if SHA-256 is broken. In that case, you could change old transactions in old blocks and trick not-yet-synchronized nodes by feeding them with your own transactions that has the same hash. Also, z-value in any OP_CHECKSIG-based signature is just SHA-256 of a modified transaction, so by breaking SHA-256 you can generate some random ECDSA signature, you will get random z,r,s combination that will be valid for a given Q public key, and then you can find a preimage for that z-value, create a transaction, add your signature and broadcast it.

Quote

Say we switched to SHA-3; wouldn't that eliminate the work that is done in previous blocks?

That's why my description above is a combination of SHA-2 and SHA-3 (you can put any 256-bit hash function here, the algorithm is the same). Of course to do it in a soft-fork way, we would need two difficulties: one for SHA-2 and one for some new hash function. Then, after fully breaking SHA-2 we will have new block headers that will hash to all zeroes in SHA-2 and to some non-zero value in the new function. Then, soft-forked new difficulty will stop the attackers, because their zero hashes will be non-zero under new function, so miners will produce a lot of headers that will be zero in SHA-2, but only some of them will be small enough in SHA-3. You can use the same data in that combined hash, it would work, as described in the example above.

Quote

Also, how's that related with efficiency?

If that change would be done in a soft-fork way, then for each hash you would need to compute SHA-2 as today and some new hash function. That is obviously slower than today, but has a nice property of "gradually activating", so it is "soft". But the above method is acceptable only for block headers, for merkle root it should be done differently, because you don't have any "difficulty" in a single transaction hash or the hash of anything else not used for mining.

I wasn't talking about the hash function, but asymmetric cryptography. How's a rehashed blockchain useful? Say we switched to SHA-3; wouldn't that eliminate the work that is done in previous blocks?

Also, how's that related with efficiency?

The main reason is that there is no consensus how to switch and to what algorithms. To introduce a new soft-fork, someone has to make some proposal, get it discussed, create a BIP for that, and go through the same process of soft-forking as changes like Segwit and Taproot did. It's not something that will be introduced tomorrow, because some people think it is a good idea. It's something that will take a few years at least. But you can start that process if you have some ideas how to switch and into what exactly we should switch.

What I described above may be acceptable when it comes to block headers, but we also have other hashes. And in that case, we would need re-hashing everything that uses SHA-256. Here comes the first question: what function should be used in that re-hashing? SHA-3? A combination of some new function and SHA-256? Also, the current solution will be less efficient that it may be in the future, because if it is publicly known how to create any preimage for SHA-256, then you can use that knowlegde and require such solution in every hash. As I mentioned, you can replace 64-round SHA-256 with 16-round SHA-256 and try to protect it somehow, for example with SHA-3. Then you will see, what can be attacked, how to attack, and you can start designing soft-fork to some new hash function; it is not that obvious, how to make it "soft", that's the lack of proposals and the lack of consensus about it, someone has to build it.

Many computer systems are based on unsolved mathematical problems. Hash functions we use today have some properties that makes them strong. If they will ever be broken, we will have one more solved mathematical puzzle and at least one more open mathematical question. The new hash function will be probably designed, based on such attacks, so it is hard to know the weakness upfront, because you don't know what needs to be protected.

Just be the change you want to see and propose something. I described above how any new hash function could be introduced in block headers, but that's only the small part of the solution (also it has a nice property that if you can reach SHA-256 with all zeroes, then it is the same as putting your new hash function directly in the same field, so it is kind of "gradual activation" with backward-compatibility, similar to how we have new transaction hashes for Segwit). There are many things to design if you seriously think about it, and the lack of detailed and well-discussed proposal is what stops us from switching.

It is possible to build some network with re-hashed blockchain that will switch only after seeing a proof of breaking SHA-256. The Script is enough to describe both collision attack and preimage attack, also second preimage attack can be handled. So, technically you can protect yourself and convince people to use your software (having some working code covered with tests and running on some test network is the bare minimum if you want to ever see that on mainnet).

None of the quantum resistant algorithms I am aware of are easily scalable right now, although I admit I am not an expert on them by any means. If we consider Lamport signatures, for example, then the signature for a message consists of 256 numbers, with each of those numbers being 256 bits longs, resulting in a signature of 65,536 bits, or 8 kilobytes. Even if we ignore the fact that Lamport public keys are twice as large as the signatures, you would be reducing the average number of transactions per block to a few dozen, which is obviously completely unsustainable.

There are no post-quantum algorithms which are as efficient as ECDSA, at least not yet. Prematurely forking to a specific algorithm would bring a number of significant drawbacks immediately for a potential improvement in the far future, but more likely we would just have to fork again closer to the time since the algorithm we ended up with would need to be replaced by something either more secure, more efficient, or likely both.