Topic: do we need SHA-512? (Read 323 times)

It is unfair to compare classical computers to quantum computers because they are fundamentally different. Reason why Quantum Computers are better at breaking ECDSA or other public-key cryptography is due to Shor's algorithm which can provide an exponential speedup, as compared to the quadratic speed up of classical computers. The qubits required to actually run Grover's with a pre-image would be fairly high, presumably (3+ times) far higher than Shor's just to outpace ASICs alone. That would mean that when QCs actually outpace the ASICs that we have today, then QC would be so mature that ECDSA would've been cracked more than a few decades ago.

I remember reading another research paper on this issue and the conclusion was that this isn't really a problem at all. [1]

[1] https://arxiv.org/pdf/1710.10377.pdf

A quantum computer would still need to brute force all the possible hashes until it finds the right block. It's just that those individual hashing calculations could happen much faster -- or rather, within many fewer steps -- than with a classical CPU. Bitcoin's difficulty adjustment algorithm is therefore not affected by it, ie. at worst we'd face shorter blocktimes followed by steeper difficulty increases, similar to when the first ASICs went online.

Well, given that the algorithm is a double SHA256, a QC would have to brute force the results of both operations sequentially.

However, the intermediate SHA256 result of the first round is not known beforehand. This makes it harder to brute force the input from the final hash because there is no guarantee that the resulting hash is reachable from some small, valid input using one round only.

ASICs are designed to perform operations more efficiently than a CPU, however an ASIC is still employing a brute force algorithm to find blocks. Mining when employing brute force, requires a linear amount of time, meaning for every one unit the difficulty increases, the expected amount of time it takes to find a block will increase by a constant amount, x (if difficulty increases by 10 units, the expected amount of time it takes to find a block increases by 10x).

My understanding about QC is that QC can find solutions to certain encryption problems in a way that is more efficient than linear. So for each unit the difficulty increases, the increase in the additional amount of effort required to find a block will decrease. This means if QC computers are able to mind at any kind of scale, they would quickly overtake the miners using ASICs, and it would be easier for someone to attack the network.

QC is still in its infancy, and any threat to any encryption is theoretical. I am not sure if the current mining algorithm is even theoretically vulnerable to QC.

Sooner or later ASIC development will reach a point where speed and efficiency can not be much further improved due to physical constraints. So assuming QC doesn't hit similar constraints it is bound to catch up eventually. Thing is, I wouldn't expect QC to be able to match ASICs until far into its technological life cycle, ie. until after QC has become available to the general public or at least businesses. Think decades.

In the end it won't matter for PoW though -- Either QC is cheap enough to attack Bitcoin's PoW in which case it becomes more economical to simply mine, or it isn't, in which case other attack surfaces (i.e. Bitcoin's signature scheme) would be more attractive targets.

No. QC remains too expensive for most tasks and the task for which it excels at requires specific algorithm, Grover's and Shor's for example. You can possibly do the operations faster than classical computers, but it would be too difficulty for it to match ASIC in terms of speed and efficiency.

I'm not really sure why pre-image would necessarily benefit them in the context of mining. You still need a very specific inputs for the block to be valid; finding a pre-image to a block hash doesn't do anything unless it is also a valid block header.

OP, I believe the Core developers already have a bias for SHA-3 if another mining algorithm needs to take the place of the current SHA-2.

To Kakmakr‘s question about the threat of Quantum Computing, the current research shows that SHA-3 is resistant to QC.

Do we ever expect for QC to become a threat for mining though? Keep in mind that when talking about operations where QC is faster than classical computing the comparison is usually drawn to CPUs. ASICs are a few orders of magnitudes faster than CPUs so it will be pretty hard for QC to catch up. Once QC catches up to ASIC mining it's more likely that QC will simply be used for mining as well.



From my understanding Bitcoin's signature scheme is more at risk than mining.



You'd need a new type of ASIC and be back at CPU / GPU mining. Accordingly transitioning to a new PoW scheme would be quite tricky, both from a technical and a political perspective.

Ok, might be a stupid question .... but some people said that the solution for the future to counter the threat of Quantum computing, would be to implement SHA512 or something stronger... was that just a popular misconception then?

If it is stronger and the output are more or less the same and it is faster.....  why do we not use it then? There must be a down-side to this for it not to be upgraded? (More hashing power needed to hash it or a whole new ASIC development?)

The reason why Ripemd160 was chosen over other message digests is to minimize the the length of the resulting scripts, which will make transaction fees slightly lower (because fees are measured in byte length).

It depends on the context. In context of brute forcing, it is not a benefit. Mining is a form of brute forcing too, so in a way you don't want to introduce an algorithm that can be computed faster than the existing one. You usually want to make it harder when replacing an algorithm.

Depends on why you believe we would need it. Is it because of the funds' security? If that's so, we don't use SHA-256 in the final step, but RIPEMD-160 as told by mynonce above. I really can't think of another reason. SHA-256 is also used in mining, but that's probably not related.

Collision with 256 bits seems realistically impossible. Watch this for fun: How secure is 256 bit security?

Isn't speed a benefit? And not only speed, but computational expense.

No, because there is no benefit in using the 512 bit version of SHA2 under any circumstance.
For starters they are using the same exact algorithm defined by second version of SHA so they are providing the same security and possible flaws as far as the algorithm is concerned.
As for the speed, SHA512 is faster to compute compared to SHA256 in modern hardware so there is no benefits there either.
Finally there is no point in using SHA512 anywhere else either (such as in ECDSA) because in those places we are dealing with 256-bit values (eg. the 256-bit curve) and using a bigger hash digest is pointless since it has to be truncated anyways.

mynonce thinks you are referring to the privatekey->public address sequence of events of cryptography. not block hashing (which you are asking about) which has no ripemd160.

..
a better answer to your question about block hash generation is
when you have a block with 1mb of data.
both sha256 and sha512 do not take that entire block of 1mb data and hash it as a single message.
both of them break up the 1mb into smaller messages. and then compute them as a series.

the end result hash is the same length no matter what the blocksize message is.
it doesnt matter if a block is 1mb or 20mb. the hash length is the same.
for sha256 the resultant hash is 32byte
for sha512 the resultant hash is 64byte

these end resultant hash values
for sha256(32byte) and sha512(64byte) dont really take up much space in a block
EG a block has 2 hash. one for current block and another for previous block. so thats 64byte 128byte respectively

meaning a 1mb block of 1,000,000byte is only taking up 64 or 128byte of that million. which is 0.0064%-0.0128% of a block

if a block was 4mb.. 4,000,000byte is taken up by up 64 or 128byte of that 4million. which is 0.0016%-0.0032% of a block
again negligible impact.

because computers can hash soo soo quickly. (millions of times a second (cpu) trillions/sec(asic)) you are not going to see any real time delay/advantage if it was sha256 or sha512
we are not talking about millisecond differences, nor microsecond differences, nor nanosecond differences, but picoseconds differences at best

the only real impact.. would be all of them 1.5million mining asic machines hashing blocks would become obsolete the second a hash algo change happens. and new asics handling sha512 will have to run in their place.

Bitcoin safety = public key safety = bitcoinaddress safety


If you replace here SHA-256 with SHA-512 or even SHA-1024, you will get as result a 20 bytes output.

Explain to me why. The ripemd160 doesn't have that big result as SHA512 or whirlpool. Then why should be not sha512 more safely as SHA256?

RIPEMD-160 is the next safety bottleneck. Changing from SHA-256 to SHA-512 wouldn't change the safety.

I wanna ask if is there a need to add the SHA512 Hash generator. Ofc. the storage of the mined block gonna be bigger (difficulty gonna be changed)
but it's gonna be more safety