BitcoinCash/specification
1
Fork 0
Code Issues Pull Requests Releases Activity

Corrected the hash endianness clarification

Browse Source 
Corrected the hash endianness clarification.
This commit is contained in:
Paul Chandler
2020-03-25 03:36:58 -04:00
committed by bitcoin
parent f4cdd5a4ac
commit 15d51628a2
1 changed files with 1 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
protocol/blockchain/hash.md
+1 -2
View File
@@ -24,8 +24,7 @@ Since [BIP-34](/protocol/forks/bip-0034), the block height is now required to be
- `D5D27987D2A3DFC724E359870C6644B40E497BDC0589A033220FE15429D88599`
- `E3BF3D07D4B0375638D5F1DB5255FE07BA2C4CB067CD81B84EE974B6585FB468`
In contrast to many hashing algorithm implementations, Bitcoin Cash block and transaction hashes are *displayed* and *sent over the network* using a little-endian representation.
This can be confusing when, for example, a block hash is treated as a big-endian integer during comparisons with the block difficulty for block validation or mining.
In contrast to many hashing algorithm implementations, Bitcoin Cash block and transaction hashes use a little-endian representation. This means they are displayed and sent over the network with the least-significant byte first. This permits a block hash stored in memory to be interpreted without swapping endianness for integer operations such as the comparison with the block difficulty during block validation or mining.
## RIPEMD-160
[RIPEMD-160](https://en.wikipedia.org/wiki/RIPEMD) is used in Bitcoin Cash scripts to create short, quasi-anonymous representations of payees for transactions.
Since its brevity is also a potential liability for the anonymity it provides (since shorter hashes generally provide less collision-resistance), it is used in conjunction with SHA-256 when generating an address from a public key.