From ab071542f670253af1a651d060760e8ce9334b72 Mon Sep 17 00:00:00 2001 From: Andrew Groot Date: Tue, 13 Oct 2020 14:50:20 -0400 Subject: [PATCH] Cleaning up various remaining items from BU PR #26. --- protocol/blockchain/hash.md | 9 +++++---- protocol/network/messages.md | 9 ++++----- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/protocol/blockchain/hash.md b/protocol/blockchain/hash.md index b9f2d1a..bbc161f 100644 --- a/protocol/blockchain/hash.md +++ b/protocol/blockchain/hash.md @@ -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. @@ -35,4 +36,4 @@ This SHA-256 then RIPEMD-160 process has its own operation for ease-of-use, [OP_ ## Murmur [MurmurHash](https://en.wikipedia.org/wiki/MurmurHash) is used in Bitcoin to support [Bloom filters](https://en.wikipedia.org/wiki/Bloom_filter). -The specific version used is the MurmurHash version 3 (32-bit), with the first hash initialized to `(numberOfHashesRequired * 0xFBA4C795L + nonce)` where `nonce` is a randomly chosen 32-bit unsigned integer. \ No newline at end of file +The specific version used is the MurmurHash version 3 (32-bit), with the first hash initialized to `(numberOfHashesRequired * 0xFBA4C795L + nonce)` where `nonce` is a randomly chosen 32-bit unsigned integer. diff --git a/protocol/network/messages.md b/protocol/network/messages.md index 5063e0f..f81d509 100644 --- a/protocol/network/messages.md +++ b/protocol/network/messages.md @@ -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