remove trailing whitespace

Author: markblundeberg

cashaccounts_retention.md

@@ -2,4 +2,4 @@
 
 This is a stub for the specs of an example Retention Server based on Cashaccounts.
 
-The server shall retain transaction ids for its client in a relatively permissionless way; to subscribe for its service, a client will simply need to supply a Cashaccount registration, along with the scan privkey. To maximize DoS resistance efficiency, first implementations of this retention server can be coupled with the relay server as well, opening relays to other types of retention servers as well as personal subscribers. Future implementations can be more decoupled, with retention servers acquiring trusted tokens from relays to allow for higher subscription bandwidth. 
+The server shall retain transaction ids for its client in a relatively permissionless way; to subscribe for its service, a client will simply need to supply a Cashaccount registration, along with the scan privkey. To maximize DoS resistance efficiency, first implementations of this retention server can be coupled with the relay server as well, opening relays to other types of retention servers as well as personal subscribers. Future implementations can be more decoupled, with retention servers acquiring trusted tokens from relays to allow for higher subscription bandwidth.

key_hookup.md

@@ -1,2 +1,2 @@
- This is a stub intended to specify hookups with single Cashaddr via Shammah Chancellor's 
-[keyserver](https://github.com/cashweb/keyserver) system. Reusable addresses that has graceful fallback is possible via such a keyserver network, and serves as an excellent way to introduce reusable addresses to the masses without additional effort from the user's side. 
+This is a stub intended to specify hookups with single Cashaddr via Shammah Chancellor's
+[keyserver](https://github.com/cashweb/keyserver) system. Reusable addresses that has graceful fallback is possible via such a keyserver network, and serves as an excellent way to introduce reusable addresses to the masses without additional effort from the user's side.

recovery_servers.md

@@ -4,52 +4,52 @@ This is a stub for the specs of communication protocol needed for the proposed R
 
 Method ideas:
 
-**version** 
+**version**
 
-Simple version handshake. Client sends a version request with his own desired version, server returns with two values: min_version and max_version, which indicates features it supports. 
+Simple version handshake. Client sends a version request with his own desired version, server returns with two values: min_version and max_version, which indicates features it supports.
 
 **get_history**
 
-Client requests: 
+Client requests:
 
 1. Version
-2. Start_block 
+2. Start_block
 3. End_block (0 if including unconfirmed)
 4. Prefix length
 5. Desired prefix
 6. Flag
 
-Server rejects if version unsupported. 
+Server rejects if version unsupported.
 
 Otherwise server first returns an estimated size of transactions (or txids, if compact) to transmit. Client acknowledges, then between start_block and end_block inclusive, return a list of transactions with at least one qualifying input's double sha256 hash matching the desired prefix string and length, each accompanied by their block number if confirmed. Returns error if rate-limited.
 
 Flag can be used to request utxo (returns only unspent) and/or compact (returns txid instead of whole transactions).
 
 **subscribe**
 
-Client request: 
+Client request:
 
 1. Version
 2. Prefix length
 3. Desired prefix
 4. Expiry time
 5. Flag
 
-Server monitors mempool + newly confirmed blocks, and pass any matching transactions (see get_history) to client. Server stops monitoring at expiry time, can be renewed. Rejects if expiry time is too far in the future. 
+Server monitors mempool + newly confirmed blocks, and pass any matching transactions (see get_history) to client. Server stops monitoring at expiry time, can be renewed. Rejects if expiry time is too far in the future.
 
-Flag can be used to request compact (returns txid instead of whole transactions). 
+Flag can be used to request compact (returns txid instead of whole transactions).
 
 -- optional --
 
-**get_peers** 
+**get_peers**
 
-get a list of known server peers (host/ports) along with their min_version and max_versions. Useful for federation. 
+get a list of known server peers (host/ports) along with their min_version and max_versions. Useful for federation.
 
-**add_peer** 
+**add_peer**
 
-A server announces its existence to other servers along with its min/max versions, which indicates features it support. Useful for federation. Peers may periodically check each other for integrity using minimal get_history. 
+A server announces its existence to other servers along with its min/max versions, which indicates features it support. Useful for federation. Peers may periodically check each other for integrity using minimal get_history.
 
-**paid_history** 
+**paid_history**
 
 Like get_history, but server returns a paycode and amount along with the size estimate. Instead of a simple acknowledgement, client returns a transaction, which the server parses and broadcasts before serving data. Returns error if payment invalid or insufficient.
 

relay_server.md

@@ -2,10 +2,10 @@
 
 This is a stub for the specs of communication protocol needed for the proposed Ephemeral Relay Server.
 
-The initial subscription shall follow the [CashID](https://gitlab.com/cashid/protocol-specification) protocol, with the scan_pubkey as the desired identity, and the client specifying how long the subscription shall be - a standalone wallet client only looking to send transactions will have a shorter, ephemeral subscription. The Challenge Request can then be signed with the scan_privkey in a response. 
+The initial subscription shall follow the [CashID](https://gitlab.com/cashid/protocol-specification) protocol, with the scan_pubkey as the desired identity, and the client specifying how long the subscription shall be - a standalone wallet client only looking to send transactions will have a shorter, ephemeral subscription. The Challenge Request can then be signed with the scan_privkey in a response.
 
 When implementing federation, a relay server can act as the intermediate and relay challenge messages between its clients and a remote relay server to start the subscription.
 
-After a successful subscription, the server shall periodically challenge the server for responses to refresh the subscription. 
+After a successful subscription, the server shall periodically challenge the server for responses to refresh the subscription.
 
-At sending, a logged in client will encrypt the transcription with the recipient's scan_pubkey and sent to the relay server. The relay server will hand it to the appropriate subscriber(s) as well as other relay servers; it returns an ack to the sending client upon relay, but the sending wallet shall not trust that message. The message is immediately destroyed upon successful relay. 
+At sending, a logged in client will encrypt the transcription with the recipient's scan_pubkey and sent to the relay server. The relay server will hand it to the appropriate subscriber(s) as well as other relay servers; it returns an ack to the sending client upon relay, but the sending wallet shall not trust that message. The message is immediately destroyed upon successful relay.