Make sure the specification is less implementation specific

protocol/forks/2019-05-15-schnorr.md

@@ -203,7 +203,7 @@ The advantage of re-using the same encoding (and potentially same keypairs) is t
 * It may be possible eventually to remove ECDSA support (and thereby allow fully batched verification), without blocking any old coins.
 
 There is a theoretical disadvantage in re-using keypairs.
-In the case of a severe break in the ECDSA or Schnorr algorithm, all addresses may be vulnerable whether intended solely for Schnorr or ECDSA --- "the security of signing becomes as weak as the weakest algorithm".<sup>[ref](https://lists.bitcoinunlimited.info/pipermail/bch-dev/2018-December/000002.html)</sup>
+In the case of a severe break in the ECDSA or Schnorr algorithm, all addresses may be vulnerable whether intended solely for Schnorr or ECDSA --- "the security of signing becomes as weak as the weakest algorithm".
 
 For privacy reasons, it may be beneficial for wallet developers to coordinate a 'Schnorr activation day' where all wallets simultaneously switch to produce Schnorr signatures by default.
 

protocol/network/messages.md

@@ -88,20 +88,6 @@ Messages with an unrecognized `command string` are ignored by most implementatio
 | [tx](/protocol/network/messages/tx) | *Provides a transaction* |
 | [verack](/protocol/network/messages/verack) | *Response to a [version](/protocol/network/messages/version) message* |
 
-#### Other Message Types (Extensions)
-
-| Command String | Synopsis | Supported Implementations
-| -- | -- | -- |
-| get_xblocktx |  |  |
-| get_xthin |  |  |
-| sendcmpct |  |  |
-| thinblock |  |  |
-| xblocktx |  |  |
-| xthinblock |  |  |
-| [xupdate](/protocol/network/messages/xupdate)  | *Communicates a change in peer capabilities* | BCHUnlimited
-| [xversion](/protocol/network/messages/xversion) | *Describes peer capabilities in an extensible manner* | BCHUnlimited
-| [xverack](/protocol/network/messages/xverack) | *Response to an [xversion](/protocol/network/messages/xversion) message* | BCHUnlimited
-
 ## Example message
 
 The below segments, when concatenated in order, create a sample [verack](/protocol/network/messages/verack) message.
@@ -117,10 +103,3 @@ Below is the full, concatenated sample message (in hexadecimal):
 
 `E3E1F3E876657261636B000000000000000000005DF6E0E2`
 
-# Node Specific Behavior
-
-## Bitcoin Unlimited
-
-### Payload Checksum
-
-Bitcoin Unlimited does not validate the message checksum since messages are sent via TCP which has its own checksum paradigm.

protocol/network/messages/filteradd.md

@@ -14,4 +14,4 @@ Add an entry into the installed bloom filter.
 | data length | variable | [variable length integer](/protocol/formats/variable-length-integer) | The size of the piece of the data to be added to the bloom filter. |
 | data | `data_length` bytes | bytes | The raw data of the object to the be added. |
 
-*data* is inserted into the bloom filter, exactly as if the [insert](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/eb264e627e231f7219e60eef41b4e37cc52d6d9d/src/bloom.cpp#L116) operation had been called locally before sending the filter.
+*data* is inserted into the bloom filter, exactly as if the insert operation had been called locally before sending the filter.

protocol/network/messages/getblocks.md

@@ -27,9 +27,3 @@ The response will begin at **the child of** the first hash in the locator list t
 ### Stop At Hash
 
 The sender will stop sending INVs if it encounters this hash.  If the hash is never encountered, the sender will stop after 500 INV messages or when it hits the blockchain tip.
-
-## Server Implementations 
-
-[Bitcoin Unlimited](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/net_processing.cpp#L1077)
-
-## Client Implementations

protocol/network/messages/getdata.md

@@ -14,9 +14,3 @@ As such, a getdata request carries the same general format as an inventory messa
 |--|--|--|--|
 | inventory count | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of inventory items being requested in this message. |
 | inventory items | `inventory_count` * 36 bytes | `inventory_count` [inventory items](/protocol/network/messages/inv#inventory-item-format) | The set of inventory items being requested. |
-
-## Server Implementations 
-
-[Bitcoin Unlimited](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/net_processing.cpp#L1021)
-
-## Client Implementations

protocol/network/messages/getheaders.md

@@ -34,9 +34,3 @@ If a non-empty locator is provided, when constructing a response message, the se
 If the locator is empty, the response includes only the header identified by this field (note it  **includes** this hash, which differs from the behavior of the locator).  In this case, if this hash is not found in the blockchain, the request is silently ignored.
 
 *Use an empty locator and a valid block hash identifier to request the header of a specific block.*
-
-## Server Implementations
-
-[Bitcoin Unlimited](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.7.0.0/src/net_processing.cpp#L1131)
-
-## Client Implementations

protocol/network/messages/inv.md

@@ -40,4 +40,3 @@ The type of the object that is available.
 |   6  |  Graphene Block (Bitcoin Unlimited)
 | 0x94a0 | [DSProof](/protocol/network/messages/dsproof-beta) |
 
-Implementations: [C++](https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/eb264e627e231f7219e60eef41b4e37cc52d6d9d/src/protocol.h#L477)

protocol/network/messages/xupdate.md

@@ -16,6 +16,3 @@ See the [xversion fields](/protocol/network/messages/xversion#xversion-fields) f
 | number of values | variable | [variable length integer](/protocol/formats/variable-length-integer) | The number of values being sent. |
 | values | variable | `number_of_values` * [xversion values](/protocol/network/messages/xversion#xversion-value-format) | The list of values to communicate. |
 
-
-### Support
-Supported by: **Bitcoin Unlimited**