tiny rewrite of initial paragraphs

text/0000-wallet-replay-protection.md

@@ -1,4 +1,3 @@
-
 - Title: `wallet-(re)play-protection`
 - Authors: Phyro, John Tromp, Yeastplume
 - Start date: `Aug 9, 2020`
@@ -10,14 +9,19 @@
 ## Summary
 [summary]: #summary
 
-Given certain conditions, UTXOs that belong to a user can be moved without their explicit permission. This document outlines the fixes that prevents this behaviour from occuring by introducing additional rules a wallet should follow.
+Given certain conditions, UTXOs that appear in a user's wallet can be spent without
+their explicit instruction. This document outlines possible fixes that prevent this
+behaviour from occuring, by introducing additional rules a wallet should follow.
 
 ## Motivation
 [motivation]: #motivation
 
-A new class of attacks was found on Grin that we call (re)play attacks. A Mimblewimble transaction that already happened can be replayed if the exact conditions are recreated. In order to be able to replay a transaction the following conditions must be true:
+A new class of attacks was found on Grin that we call (re)play attacks. A
+Mimblewimble transaction that already happened can be replayed if the exact
+conditions are recreated. In order to be able to replay a transaction the
+following conditions must be true:
 1. The inputs must be in the utxo set
-2. The outputs of the transaction must not be in the utxo set (Grin does not allow duplicate outputs in the utxo set)
+2. The outputs of the transaction must not be in the utxo set (Grin does not allow duplicates in the utxo set)
 
 This means that if Alice sent some coins to Bob and the outputs have been spent, anyone that saw their original transaction could replay the transaction if the same inputs existed in the utxo set. But why would the same inputs exist on the chain in the first place? Alice could send those coins to Bob again, using different inputs but the same output for Bob, and trick Bob into thinking that this constitutes a new payment. If Bob accepts it as such, then Alice can replay Bob's spend of the recreated output at an opportune moment. Similarly, a _play_ attack comes from the same reasoning, but with the difference that a transaction never made it to the chain for some reason. One such reason could be that an input was spent before it was broadcasted which would make the current transaction invalid. In this document, we propose new wallet behaviours that make it robust in the face of (re)play attacks so the end users can't be victims of these attacks.
 
@@ -325,4 +329,4 @@ The options of transaction building configuration and programmability are only l
 
 [Replay attacks and possible mitigations](https://forum.grin.mw/t/replay-attacks-and-possible-mitigations/7415)
 
-[PayJoins for replay protection](https://forum.grin.mw/t/payjoins-for-replay-protection/7544)
+[PayJoins for replay protection](https://forum.grin.mw/t/payjoins-for-replay-protection/7544)