Understanding Bitcoin's Hashing Function in Simple Terms

[butka]

This is my attempt to understand SHA-256, Bitcoin's hashing function, at least to the extent needed for a better understanding of Bitcoin. I would appreciate any correction or suggestion from the other members of this forum.

SHA-256 is a function that is used in Bitcoin often. It is used, for example:

• in the Proof of Work (PoW) algorithm,
• to create bitcoin addresses,
• to provide a compact form for denoting transactions.

The name, SHA-256, may suggest something complicated. At least, that was my initial reaction. This very fact may hinder your attempts to understand it. Without involving too many technical terms, let's try to see what it does.
SHA-256 is a function. As with any other function, F(x)=y

we have 2 important things related to it:

a) the input, x

b) the output, y

Unless you are a mathematician or cryptographer, what's under the hood, the actual F, is not so important.

All that matters it that SHA-256 takes an input and produces an output.

Code:

SHA(x) = y

In this case, our output, y, is also called a hash.

Unlike any ordinary function (for example a square root) which takes only numbers, SHA-256 can take anything: numbers, letters, text, video, binary file, or anything that can be represented in a digital form.

SHA-256 reduces the input to a well defined output, the hash. The hash is always 256 bits.

This is like a matrix, 16x16, with randomly distributed zeros and ones.

Code:

1 0 0 1 0 0 1 0 1 0 1 0 1 0 0 1
0 1 0 1 1 1 0 1 0 0 0 1 0 1 0 1
1 1 1 1 0 1 0 1 0 1 1 1 0 0 0 0
0 0 1 1 1 0 1 1 0 0 0 0 1 1 0 0
1 0 0 0 0 1 1 0 1 0 1 0 0 1 1 1
1 0 0 1 0 1 0 0 0 1 0 0 0 0 0 1
0 1 1 0 0 1 1 0 0 0 1 0 0 1 0 1
0 1 1 1 1 1 0 1 0 1 1 1 1 0 1 0
0 0 1 0 0 1 1 0 1 0 0 0 0 1 0 0
1 0 0 1 1 0 1 1 1 1 0 1 1 1 1 0
1 0 1 0 0 0 1 0 0 0 1 0 0 1 0 1
1 0 1 0 0 1 1 1 0 1 0 0 1 0 1 1
0 0 1 0 1 1 0 1 0 1 0 0 0 0 1 0
0 0 0 1 1 0 1 1 0 1 0 0 1 1 0 0
1 1 1 0 1 0 1 0 1 0 1 0 1 1 0 0
0 1 1 0 1 1 0 1 0 0 1 0 0 0 0 1

The number of different ways these 1s and 0s can be distributed is HUGE. It is precisely 2²⁵⁶, which, according to this large numbers calculator, is exactly this many combinations:

115792089237316195423570985008687907853269984665640564039457584007913129639936

How huge the above number is can be illustrated by comparing it to the estimated number of atoms in the observable universe, which is something like 10⁸⁰. It is only several orders of magnitude smaller.
SHA-256 produces a unique hash. The chances that you would ever obtain two identical patterns of ones and zeros for two different inputs is zero (is it actually zero or a negligible small number?). Because of the uniqueness of our hash function output, we can use it as a digital signature.

In Bitcoin, the binary form of the hash can be represented as a hexadecimal number, in which case, there are 64 digits and a relatively more compact form:

Code:

92A95D15F5703B0C86A7944166257D7A26849BDEA225A74B2D421B4CEAAC6D21

Properties of a good hashing function

• It takes the same time on average to hash large and small inputs.
• It should be fast to compute.
• The outputs of similar inputs should be distinctly different.
• A good hashing function should be collision resistant. This means, no two different inputs should produce the same output.
• Given the output, to find the input one would have to randomly hash all possible inputs (brute force attack). This implies that if one has no clue about the form of the input, finding it, just based on the output, should be practically an impossible task. How difficult it might be to do a brute force attack on SHA-256 even with quantum computers at one's disposal, is illustrated in this post. We are talking about billions of years.

Sources:

https://medium.com/@ConsenSys/blockchain-underpinnings-hashing-7f4746cbd66b
https://en.bitcoin.it/wiki/SHA-256

Now to the questions:

1. I understand the use of hashing in PoW, but what's the point of using SHA-256 to generate bitcoin addresses? Security doesn't look too important here, as we obtain these addresses from public keys, not the private ones.

2. What are the advantages (or disadvantages) of the newest generation of SHA3 Keccak hashing function vs SHA2-256?

3. Is the only benefit of hashing transactions their compact representation?

[1714110699]

1714110699

[1714110699]

1714110699

[1714110699]

1714110699

[1714110699]

1714110699

[ranochigo]

1. I understand the use of hashing in PoW, but what's the point of using SHA-256 to generate bitcoin addresses? Security doesn't look too important here, as we obtain these addresses from public keys, not the private ones.

The standard for sending transactions at the beginning was actually directly to the ECDSA public key (P2PK). It was changed only after awhile to public key hash. The main advantage to using SHA256 as a method to send address is that it is way smaller than public keys and hence more convenient to store and type. The added advantage is that there isn't any known attack against SHA256 as of now but ECDSA is susceptible to quantum computer attacks due to Shor's algorithm.

Since your public key isn't exposed till you spend your coins, your address would likely be safe against it.

2. What are the advantages (or disadvantages) of the newest generation of SHA3 Keccak hashing function vs SHA2-256?

One obvious disadvantage is that it would require a hard fork to implement it in Bitcoin. I can't think of any significant advantage for Keccak over SHA256 since there isn't any glaring vulnerability about it right now.

[Slava79]

1. I understand the use of hashing in PoW, but what's the point of using SHA-256 to generate bitcoin addresses? Security doesn't look too important here, as we obtain these addresses from public keys, not the private ones.

2. What are the advantages (or disadvantages) of the newest generation of SHA3 Keccak hashing function vs SHA2-256?

3. Is the only benefit of hashing transactions their compact representation?

The best answer I know about so far https://bitcoin.stackexchange.com/questions/3600/why-are-bitcoin-addresses-hashes-of-public-keys

It's just to get shorter addresses. Regular public keys are 65 bytes long, which is much too long to be convenient. Compressed public keys are 33 bytes and could potentially be used instead of hashes, though these are a little longer than 20-byte hashes. It also seems likely that Satoshi didn't know about compressed public keys or wasn't comfortable with using them when he designed Bitcoin.

Hashes seem to help against certain attacks (some attacks against ECDSA, for example), though they also open up the possibility of other attacks (such as attacks against RIPEMD-160). It's not clear to me that they do improve security overall.

It is answered by someone with a nick "theymos", this sounds familiar, not sure why...

[bob123]

2. What are the advantages (or disadvantages) of the newest generation of SHA3 Keccak hashing function vs SHA2-256?

One disadvantage would probably the high performance on ASIC's [1] which would lead to a more centralized system.
There is no need to switch to SHA-3.


Statement from NIST:

Currently there is no need to transition applications from SHA-2 to SHA-3

Source: https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions




[1] https://ehash.iaik.tugraz.at/wiki/SHA-3_Hardware_Implementations#High-Speed_Implementations_.28ASIC.29

3. Is the only benefit of hashing transactions their compact representation?

No. Hash functions are also used for verification.
Probably the simpliest example: Checksums [2] (e.g. Message Authentication Code (MAC)).

In Bitcoin a hashing function allows to easily verify all transactions within a block.

And additionally it serves as PoW.



[2] https://en.wikipedia.org/wiki/Checksum

[butka]

The main advantage to using SHA256 as a method to send address is that it is way smaller than public keys and hence more convenient to store and type.

I see, thanks for the reply. It turns out that this size reduction of the original input is another useful property of the hashing function.

Since your public key isn't exposed till you spend your coins, your address would likely be safe against it.

So, does this imply that the first time one decides to spend some coins (and expose their public key) their private key is potentially less safe?

It is answered by someone with a nick "theymos", this sounds familiar, not sure why...

Very interesting, thanks for sharing. I should've done better job researching this subject. It appears that my question has been answered a long time ago!

[Xynerise]

So, does this imply that the first time one decides to spend some coins (and expose their public key) their private key is potentially less safe

Theoretically, yes, but practically it doesn't really matter -- for now anyways, and perhaps for a long time.

[pebwindkraft]

...
Because of the uniqueness of our hash function output, we can use it as a digital signature.

a minor comment on signatures: there might be use cases where you can use a sha256 fingerprint as a digital signature, cause everytime you provide the same input, it returns the exactly same output.
Generally speaking in crypto world, digital signatures are based on a different logic, and in bitcoin world the ECDSA logic is used.
 
I would like to say, that for digital signatures the common software is [EC]DSA logic, and sha256 (or other hashing) is seldom used for signatures. Next to the (H)MAC functions (as described above by bob123), the main benefit and use case of sha256 (and other hashing software) is, that you can say, if content of a file/data has been changed. E.g. you transfer data from system A to B. And also you provide the short checksum. Then B can run the sha256 also on the file, once received, and must receive the exactly same hash value. Otherwise file has changed. Same is true for files on your hard drive: you can check them once, store it in a reference file, and run every day/week/month a sha256 again, compare results against the reference file, and see if contents of (important) files has changed -> this allows to detect malicious code/software on a system.

[butka]

No. Hash functions are also used for verification.
Probably the simpliest example: Checksums [2] (e.g. Message Authentication Code (MAC)).

I would like to say, that for digital signatures the common software is [EC]DSA logic, and sha256 (or other hashing) is seldom used for signatures. Next to the (H)MAC functions (as described above by bob123), the main benefit and use case of sha256 (and other hashing software) is, that you can say, if content of a file/data has been changed. E.g. you transfer data from system A to B. And also you provide the short checksum. Then B can run the sha256 also on the file, once received, and must receive the exactly same hash value. Otherwise file has changed.

Thanks, I never thought of that. So using Hash functions as checksums is more important in this context. Even if there is no bad intention from any party involved in the process, computer bugs, corrupt data, or similar problems can always occur. Therefore it is important to check the integrity of the data.

[kaar]

Just a small note:

SHA-256 produces a unique hash. The chances that you would ever obtain two identical patterns of ones and zeros for two different inputs is zero (is it actually zero or a negligible small number?). Because of the uniqueness of our hash function output, we can use it as a digital signature.

• A good hashing function should be collision resistant. This means, no two different inputs should produce the same output.

In most, if not all cases, and particularly in SHA-256, there are many inputs which produce the same output. This is inevitable since the size of the domain is greatly larger than the size of the target. So the chances that two different inputs would produce the same hash is greater than zero. However, as you correctly noted, the chances are so small, that practically they are considered to be zero.

[butka]

This is inevitable since the size of the domain is greatly larger than the size of the target. So the chances that two different inputs would produce the same hash is greater than zero. However, as you correctly noted, the chances are so small, that practically they are considered to be zero.

I get it. This cannot be 1-to-1 mapping. It has to be many-to-1 mapping due to fact that the size of the first domain, by definition, is much larger than the size of second domain.

[pebwindkraft]

To further provide some info on possible collision in hash functions, there are many discussions on crypto.SE, see e.g here and the links in this page‘s sidebar:

https://crypto.stackexchange.com/questions/58214/how-can-hashes-be-unique-if-they-are-limited-in-number

[bob123]

I think they also include a check-sum as well but feel free to contest this and no one should trust services
provided by Windows black-box code with any data because it's all being stolen by Back-Door-Bill Gates who was working for the
CIA/NSA before half the users of Bitcoin were even born.

Noone was talking about anything related to windows.
Please start reading the threads you are shitposting in.

You additionally seem to miss the whole point regarding the checksum.
You post a few lines of code where the RIPEMD160 hash function is called and claim thats the only part you understand and that it is 'from windows' ?   

I'd highly recommend you read this: https://en.wikipedia.org/wiki/Hash_function

[btc-facebook]

AFAIK bitcoin using SHA 256 as their security but why it still can be hack ?

Let say if they are using brute force attempt but they can do it less than 1 year, not billions of years

I'm still new about SHA things so if my question too stupid, please forgive me.

[ranochigo]

AFAIK bitcoin using SHA 256 as their security but why it still can be hack ?

Let say if they are using brute force attempt but they can do it less than 1 year, not billions of years

First of all, the Bitcoin hacks that you've seen in the news and around the forum has absolutely nothing to do with the protocol itself. So the strength of your SHA256 has nothing to do with them.

Second of all, yes SHA256 is indeed very strong. The main areas for which it is used is in the final step of the transaction (for which we can do without), addresses (we also don't need it), assembling of transactions for merkle root (everyone can do this; they have the transaction list) and the block header. Being able to bruteforce anything faster would only give you a larger hashrate and really no advantage over the other blackhat hacker.