So I was just curious.
I really look up to Blockchain technology and I have read that Bitcoin uses double SHA-256 for hashing.
( from what I understood, double sha256 is essentially $\operatorname{SHA-256}(\operatorname{SHA256}(value))$ ).
Is double SHA-256 better than SHA-512 or any other hashing algorithm that bitcoin could use? Or maybe there are other alternatives that could bring some benefits over the double SHA-256 for bitcoin?
Since the initial release of Bitcoin is 9 January 2009, the designer had these NIST hash functions (NIST-FIPS 180-4) as available options: SHA-1( 1995), SHA-256 (2001), SHA-512 (2001), and some more.
The main difference between SHA-256 and SHA-512 is the target CPU. SHA-256 is designed for 32-bit CPUs and SHA-512 is designed for 64-bit CPUs. That makes a huge difference in the target CPUs.
One can argue that the designer wanted protection against the length extension attacks. However, SHA-512/256, which has the same pre-image, secondary-preimage, and collision resistance as SHA256, is secure against length extension attacks. Though not officially available at that time, simply trimming the 256 bit from the output of SHA-512 is the countermeasure. The knowledge was there since SHA-384 (2001) was available and it is trimmed from SHA-512 with different initial values for domain seperation *.
The obvious choice can be considered as the speed. SHA512, according to the Blake2 site, is 50% faster than SHA-256. SHA-1 is 2-times faster than SHA-256. However, the output size of SHA-1 is 160 bit and can be considered small for security during 2009 and for the mining space.
Another parameter for the choice of 256-bit is that Bitcoin used ECDSA-SHA-256 signatures. The obvious choice for hashing the message is using SHA-256.
Therefore, we can conclude that the designer didn't want fast mining, compatible with the ECDSA-SHA-256 signature so choose the $\operatorname{SHA-256}$ and, to prevent length extension attacks, selected double hashing. The double hashing is invented by Ferguson and Schneier in their book Practical Cryptography to countermeasure against length extension attacks.
As a side note, double-hashing doesn't prevent collision attacks since any collision $\operatorname{SHA256}(x)=\operatorname{SHA256}(y)$ is also a collision for $$\operatorname{SHA256}(\operatorname{SHA256}(x))=\operatorname{SHA256}(\operatorname{SHA256}(y)).$$
*In academics, the first occurence the trimming as a countermeasure againt the length extension attack goes back to 1995
Comparing double sha256 to sha512 is like comparing apples to oranges. For one, the result of sha512 is 512 bits in length. The result of double sha256 (or triple sha256, or quadruple sha256, for that matter) is 256 bits in length.
There has been a lot of conjecture over the years as to why the creator of bitcoin chose to use double sha256 in the protocol. One theory is that it was done to mitigate length-extension attacks. For more info, see https://bitcoin.stackexchange.com/questions/6037/why-are-hashes-in-the-bitcoin-protocol-typically-computed-twice-double-computed.
The typical reason one uses double hashing is to deal with length-extension attacks. That's because any Merkle-Dåmgard algorithm that outputs its entire state (e.g., SHA-1, SHA-256, and SHA-512) is vulnerable to a length extension attack, where users who know a hash can append additional data and also produce a valid hash.
There are other algorithms, such as SHA-3 and BLAKE2, which don't have this problem because they use a different construction. SHA-3 uses a large state and outputs only a portion, while BLAKE2 modifies the input data of the last block processed to distinguish it. A design lacking this problem is preferable these days.
However, those algorithms didn't exist at the time Bitcoin was created (2008), and SHA-256 was the standard hash algorithm to use for secure contexts, even though it has this weakness.
Whether an algorithm is "better" in a context depends on one's needs. Presently, if one needs security against length extension attacks, one chooses SHA-3 or BLAKE2. If one needs performance, one uses BLAKE2 or SHA-256 (if accelerated on the relevant hardware). If one needs compliance, one uses SHA-2 or SHA-3. There are many criteria to consider.
In the context of when the design was made, the choice was probably responsible and defensible and was the best that could be done under the circumstances, even if we would prefer a different algorithms today (because we have better ones available). Since SHA-256 is presently considered secure and robust, there's little reason to change right now. If in the future that changes, then using a different algorithm may be warranted.
