You've already forked specification
Cleaning up various remaining items from BU PR #26.
This commit is contained in:
@@ -24,9 +24,10 @@ Since [BIP-34](/protocol/forks/bip-0034), the block height is now required to be
|
|||||||
- `D5D27987D2A3DFC724E359870C6644B40E497BDC0589A033220FE15429D88599`
|
- `D5D27987D2A3DFC724E359870C6644B40E497BDC0589A033220FE15429D88599`
|
||||||
- `E3BF3D07D4B0375638D5F1DB5255FE07BA2C4CB067CD81B84EE974B6585FB468`
|
- `E3BF3D07D4B0375638D5F1DB5255FE07BA2C4CB067CD81B84EE974B6585FB468`
|
||||||
|
|
||||||
In contrast to many hashing algorithm implementations, Bitcoin Cash block and transaction hashes use a little-endian representation.
|
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.
|
||||||
This means they are displayed and sent over the network with the least-significant byte first.
|
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.
|
||||||
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.
|
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
|
||||||
[RIPEMD-160](https://en.wikipedia.org/wiki/RIPEMD) is used in Bitcoin Cash scripts to create short, quasi-anonymous representations of payees for transactions.
|
[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.
|
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
|
## Murmur
|
||||||
|
|
||||||
[MurmurHash](https://en.wikipedia.org/wiki/MurmurHash) is used in Bitcoin to support [Bloom filters](https://en.wikipedia.org/wiki/Bloom_filter).
|
[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.
|
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.
|
||||||
|
|||||||
@@ -9,10 +9,10 @@ The P2P protocol is designed around messages.
|
|||||||
Each message is separate and self-contained.
|
Each message is separate and self-contained.
|
||||||
Nodes should be tolerant of message-types they do not understand.
|
Nodes should be tolerant of message-types they do not understand.
|
||||||
It is best to simply ignore those.
|
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.
|
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.
|
Events can be notifications of new data (transactions/blocks/etc), requests for such data to be sent, or the sending of the data itself.
|
||||||
Or, in some specific cases a `reject` message.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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
|
### Command String
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user