doc/src/misc/hashchain/network_protocol.md: Wrap lines at 72 columns

doc/src/misc/hashchain/network_protocol.md

@@ -3,8 +3,8 @@
 The protocol checks that `Event`s properly broadcast through the
 network before adding `Event`s to the `Model`.
 
-The read_confirms inside each `Event` indicate how many times the `Event` has
-been read from other nodes in the network.
+The read_confirms inside each `Event` indicate how many times the
+`Event` has been read from other nodes in the network.
 
 The protocol classifies the `Event`s by their state:
 
@@ -15,7 +15,8 @@ Read:	read_confirms >= MAX_CONFIRMS
 
 ## Inv
 
-Inventory vectors notify other nodes about objects they have or data which is being requested.
+Inventory vectors notify other nodes about objects they have or data
+which is being requested.
 
 | Description   | Data Type            | Comments                   |
 |-------------- | -------------------- | -------------------------- |
@@ -23,27 +24,30 @@ Inventory vectors notify other nodes about objects they have or data which is be
 
 ### Receiving an `Inv` message
 
-Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited
-or in reply to `getevents`.
+Allows a node to advertise its knowledge of one or more objects. It can
+be received unsolicited or in reply to `getevents`.
 
-An `Inv` message is a confirmation from a node in the network that the `Event`
-has been read.
+An `Inv` message is a confirmation from a node in the network that the
+`Event` has been read.
 
 Confirmation for an `Event` does not exist in the `UnreadEvents` list.
-Instead, the protocol sends a `GetData` message to request the missing `Event`.
+Instead, the protocol sends a `GetData` message to request the missing
+`Event`.
 
-The protocol updates the `Event` in the `UnreadEvents` list by increasing the
-read_confirms by one.
+The protocol updates the `Event` in the `UnreadEvents` list by
+increasing the read_confirms by one.
 
 The updated `Event` state changes to read when the read_confirms exceed
-`MAX_CONFIRMS`. Then, the `UnreadEvents` list removes the `Event` and adds it to the `Model`.
+`MAX_CONFIRMS`. Then, the `UnreadEvents` list removes the `Event` and
+adds it to the `Model`.
 
 The protocol rebroadcasts the received `Inv` to the network.
 
 ### Sending an `Inv` message
 
-Upon receiving an `Event` with unread status from the network, the protocol sends back
-an `Inv` message to confirm that the `Event` has been read.
+Upon receiving an `Event` with unread status from the network, the
+protocol sends back an `Inv` message to confirm that the `Event` has
+been read.
 
 ## GetData
 
@@ -53,8 +57,8 @@ an `Inv` message to confirm that the `Event` has been read.
 
 ### Receiving a `GetData` message
 
-The protocol searches in both `Model` and `UnreadEvents` for the requested `Event`s
-in `GetData` message.
+The protocol searches in both `Model` and `UnreadEvents` for the
+requested `Event`s in `GetData` message.
 
 ## UnreadEvents
 
@@ -64,10 +68,11 @@ in `GetData` message.
 
 ### Add new `Event` to `UnreadEvents`
 
-To add an `Event` to `UnreadEvents`, the protocol first must check the validity of
-`Event`.
+To add an `Event` to `UnreadEvents`, the protocol first must check the
+ validity of `Event`.
 
-The `Event` is not valid in the network if it's either too far in the future or in the past.
+The `Event` is not valid in the network if it's either too far in the
+future or in the past.
 
 ### Updating `UnreadEvents` list
 
@@ -86,11 +91,12 @@ until the state of `Event` updates to read.
 To achieve complete synchronization between nodes, the protocol sends a
 `SyncEvent` message every 2 seconds to other nodes in the network.
 
-The `SyncEvent` contains the hashes of `Event`s set in the leaves of `Model`'s tree.
+The `SyncEvent` contains the hashes of `Event`s set in the leaves of
+`Model`'s tree.
 
-On receiving `SyncEvent` message, the leaves in `SyncEvent` should match the
-leaves in the `Model`'s tree; otherwise, the protocol sends `Event`s which are the children of
-`Event`s in `SyncEvent`.
+On receiving `SyncEvent` message, the leaves in `SyncEvent` should
+match the leaves in the `Model`'s tree; otherwise, the protocol sends
+`Event`s which are the children of `Event`s in `SyncEvent`.
 
 ## Seen
 
@@ -103,25 +109,26 @@ The list contains only 2^16 ids.
 
 ## Receiving a new `Event`
 
-The new received `Event` with unread status is added to the `UnreadEvents` buffer after
-increasing the read_confirms by one.
+The new received `Event` with unread status is added to the
+`UnreadEvents` buffer after increasing the read_confirms by one.
 
 The `Event` with read status is added to the `Model`.
 
-The protocol broadcasts the received `Event` to the network, again. This ensures all nodes
-in the network get the Event.
+The protocol broadcasts the received `Event` to the network, again.
+This ensures all nodes in the network get the Event.
 
 ## Sending an `Event`
 
 A new created `Event` has unread status with read_confirms equal to 0.
 
-The protocol broadcasts the `Event` to the network after adding it to the
-`UnreadEvents`.
+The protocol broadcasts the `Event` to the network after adding it to
+the `UnreadEvents`.
 
 ## Add new `Event` to `Model`
 
-For the `Event` to be successfully added to the `Model`, the protocol checks if
-the previous `Event`'s hash inside the `Event` exists in the `Model`.
+For the `Event` to be successfully added to the `Model`, the protocol
+checks if the previous `Event`'s hash inside the `Event` exists in the
+`Model`.
 
 In case the previous `Event` check fails, the protocol
 sends a `GetData` message requesting the previous `Event`.