-This section documents how the GNUnet transport service validates connections
-with other peers. It is a high-level description of the protocol necessary to
-understand the details of the implementation. It should be noted that when we
-talk about PING and PONG messages in this section, we refer to transport-level
-PING and PONG messages, which are different from core-level PING and PONG
-messages (both in implementation and function).
-
-The goal of transport-level address validation is to minimize the chances of a
-successful man-in-the-middle attack against GNUnet peers on the transport
-level. Such an attack would not allow the adversary to decrypt the P2P
-transmissions, but a successful attacker could at least measure traffic volumes
-and latencies (raising the adversaries capablities by those of a global passive
-adversary in the worst case). The scenarios we are concerned about is an
-attacker, Mallory, giving a HELLO to Alice that claims to be for Bob, but
-contains Mallory's IP address instead of Bobs (for some transport). Mallory
-would then forward the traffic to Bob (by initiating a connection to Bob and
-claiming to be Alice). As a further complication, the scheme has to work even
-if say Alice is behind a NAT without traversal support and hence has no address
-of her own (and thus Alice must always initiate the connection to Bob).
-
-An additional constraint is that HELLO messages do not contain a cryptographic
-signature since other peers must be able to edit (i.e. remove) addresses from
-the HELLO at any time (this was not true in GNUnet 0.8.x). A basic
-@strong{assumption} is that each peer knows the set of possible network
-addresses that it @strong{might} be reachable under (so for example, the
-external IP address of the NAT plus the LAN address(es) with the respective
-ports).
-
-The solution is the following. If Alice wants to validate that a given address
-for Bob is valid (i.e. is actually established @strong{directly} with the
-intended target), it sends a PING message over that connection to Bob. Note
-that in this case, Alice initiated the connection so only she knows which
-address was used for sure (Alice maybe behind NAT, so whatever address Bob
-sees may not be an address Alice knows she has). Bob checks that the address
-given in the PING is actually one of his addresses (does not belong to
-Mallory), and if it is, sends back a PONG (with a signature that says that Bob
-owns/uses the address from the PING). Alice checks the signature and is happy
-if it is valid and the address in the PONG is the address she used. This is
-similar to the 0.8.x protocol where the HELLO contained a signature from Bob
-for each address used by Bob. Here, the purpose code for the signature is
+This section documents how the GNUnet transport service validates
+connections with other peers. It is a high-level description of the
+protocol necessary to understand the details of the implementation. It
+should be noted that when we talk about PING and PONG messages in this
+section, we refer to transport-level PING and PONG messages, which are
+different from core-level PING and PONG messages (both in implementation
+and function).
+
+The goal of transport-level address validation is to minimize the chances
+of a successful man-in-the-middle attack against GNUnet peers on the
+transport level. Such an attack would not allow the adversary to decrypt
+the P2P transmissions, but a successful attacker could at least measure
+traffic volumes and latencies (raising the adversaries capablities by
+those of a global passive adversary in the worst case). The scenarios we
+are concerned about is an attacker, Mallory, giving a HELLO to Alice that
+claims to be for Bob, but contains Mallory's IP address instead of Bobs
+(for some transport). Mallory would then forward the traffic to Bob (by
+initiating a connection to Bob and claiming to be Alice). As a further
+complication, the scheme has to work even if say Alice is behind a NAT
+without traversal support and hence has no address of her own (and thus
+Alice must always initiate the connection to Bob).
+
+An additional constraint is that HELLO messages do not contain a
+cryptographic signature since other peers must be able to edit
+(i.e. remove) addresses from the HELLO at any time (this was not true in
+GNUnet 0.8.x). A basic @strong{assumption} is that each peer knows the
+set of possible network addresses that it @strong{might} be reachable
+under (so for example, the external IP address of the NAT plus the LAN
+address(es) with the respective ports).
+
+The solution is the following. If Alice wants to validate that a given
+address for Bob is valid (i.e. is actually established @strong{directly}
+with the intended target), it sends a PING message over that connection
+to Bob. Note that in this case, Alice initiated the connection so only
+she knows which address was used for sure (Alice maybe behind NAT, so
+whatever address Bob sees may not be an address Alice knows she has). Bob
+checks that the address given in the PING is actually one of his addresses
+(does not belong to Mallory), and if it is, sends back a PONG (with a
+signature that says that Bob owns/uses the address from the PING). Alice
+checks the signature and is happy if it is valid and the address in the
+PONG is the address she used. This is similar to the 0.8.x protocol where
+the HELLO contained a signature from Bob for each address used by Bob.
+Here, the purpose code for the signature is