EIP-8: clarification clarifications

EIPS/eip-8.md

@@ -112,7 +112,7 @@ version simply send a packet with higher version and possibly additional list el
 #### Changes to the RLPx Discovery Protocol
 
 The relaxation of discovery packet decoding rules largely codifies current practice. Most
-existing clients do not care about the number of list elements (a notable exception being
+existing implementations do not care about the number of list elements (an exception being
 go-ethereum) and do not reject nodes with mismatching version. This behaviour is not
 guaranteed by the spec, though.
 
@@ -160,21 +160,22 @@ if decrypt(packet) {
 }
 ```
 
-The plain text size prefix is perhaps the most controversial aspect of this document.
-it has been argued that the prefix aids adversaries that seek to filter and identify
-RLPx connections on the network level.
+The plain text size prefix is perhaps the most controversial aspect of this document. It
+has been argued that the prefix aids adversaries that seek to filter and identify RLPx
 
-Whether this is an issue depends on the attacker's budget and the availability
-of other indicators. If the recommendation to randomise the lengths is followed,
-pure pattern-based packet recognition is unlikely to succeed.
+connections on the network level.
+
+This is largely a question of how much effort the adversary is willing to expense. If the
+recommendation to randomise the lengths is followed, pure pattern-based packet
+recognition is unlikely to succeed.
 
 * For typical firewall operators, blocking all connections whose first two bytes form an
-  integer in range [300,600] is probably too invasive. Port-based blocking is likely to
-  be a more effective measure for filtering most RLPx traffic.
-* For an attacker who can afford to correlate many criteria, the size prefix will ease
-  recognition because it adds to the indicator set. However, such an attacker can also be
-  expected to read and or participate in RLPx Discovery traffic, in which case effective
-  blocking is possible irrespective of the size prefix.
+  integer in range [300,600] is probably too invasive. Port-based blocking is likely to be
+  a more effective measure for filtering most RLPx traffic.
+* For an attacker who can afford to correlate many criteria, the size prefix would ease
+  recognition because it adds to the indicator set. However, such an attacker could also
+  be expected to read or participate in RLPx Discovery traffic, which would be sufficient
+  to enable blocking of RLPx TCP connections whatever their format is.
 
 ### Backwards Compatibility