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

Cleaning up various remaining items from BU PR #26.

Browse Source
This commit is contained in:
Andrew Groot
2020-10-13 14:50:20 -04:00
parent 615e0d747a
commit ab071542f6
2 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
protocol/blockchain/hash.md
+4 -3
View File
@@ -24,9 +24,10 @@ 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 use a little-endian representation.
This means they are displayed and sent over the network with the least-significant byte first.
And ultimately 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.
In contrast to many other protocols, Bitcoin Cash sometimes treats block and transaction hashes as a number, for example when comparing with block difficulty during block validation or mining.
In these situations, the output byte array of the hashing algorithm is interpreted as a 256 bit number in little-endian format, particularly when transmitted over the network.
This is the opposite of standard protocol design, so it may be simpler to think of hashes as byte arrays that occasionally are turned into little-endian numbers, than as numbers with a lot of display/encoding caveats.
## 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.
protocol/network/messages.md
+4 -5
View File
@@ -9,10 +9,10 @@ The P2P protocol is designed around messages.
Each message is separate and self-contained.
Nodes should be tolerant of message-types they do not understand.
It is best to simply ignore those.
Detailed descriptions of the messages follows below.
Generally speaking, each message is an event that the node can choose to respond to.
Events range from notifications of new data (transactions/blocks/etc) and actual requests for such data to be send and last the actual data being sent.
Or, in some specific cases a `reject` message.
Events can be notifications of new data (transactions/blocks/etc), requests for such data to be sent, or the sending of the data itself.
In some specific cases a message can indicate the rejection of another message, though this is optional and should not be relied upon.
These design decisions were made with consideration to communication with untrusted/uncooperative partners.
@@ -37,11 +37,10 @@ See [Example Message](#example-message) for a concrete example of this with a me
The network identifier is used to separate blockchains and test networks.
This reduces unnecessary load on peers, allowing them to rapidly ban nodes rather then forcing the peer to do a blockchain analysis before banning or disconnecting.
For Bitcoin Cash main net, the `net magic` field is always `0xE3E1F3E8`.
For Bitcoin Cash main net, the `net magic` field is always `0xE3E1F3E8` (the ASCII string, "cash", with each byte's highest bit set).
Any message received that does not begin with the `net magic` is invalid.
The `net magic` is designed to be unlikely to occur in normal data--the characters are rarely used upper ASCII, are not valid as UTF-8, and produce a large 32-bit integer with any alignment.
`0xE3E1F3E8` is the ASCII string, "cash", with each byte's highest bit set.
### Command String