finish second pass copy edit to EOF, to bring in line with stylesheet

11-payment-encoding.md

@@ -191,59 +191,60 @@ A reader:
 
 The type-and-length format allows future extensions to be backward
 compatible. `data_length` is always a multiple of 5 bits, for easy
-encoding and decoding. For fields that are expected may change, readers
-also ignore ones of different length.
+encoding and decoding. Readers also ignore fields of different length,
+for fields that are expected may change.
 
 The `p` field supports the current 256-bit payment hash, but future
-specs could add a new variant of different length, in which case
-writers could support both old and new, and old readers would ignore
-the one not the correct length.
+specs could add a new variant of different length: in which case,
+writers could support both old and new variants, and old readers would
+ignore the variant not the correct length.
 
 The `d` field allows inline descriptions, but may be insufficient for
-complex orders; thus the `h` field allows a summary, though the method
+complex orders. Thus, the `h` field allows a summary: though the method
 by which the description is served is as-yet unspecified and will
-probably be transport dependent. The `h` format could change in future
+probably be transport dependent. The `h` format could change in the future,
 by changing the length, so readers ignore it if it's not 256 bits.
 
 The `n` field can be used to explicitly specify the destination node ID,
 instead of requiring signature recovery.
 
 The `x` field gives warning as to when a payment will be
-refused; this is mainly to avoid confusion. The default was chosen
+refused: mainly to avoid confusion. The default was chosen
 to be reasonable for most payments and to allow sufficient time for
-on-chain payment if necessary.
+on-chain payment, if necessary.
 
-The `c` field gives a way for the destination node to require a specific
+The `c` field allows a way for the destination node to require a specific
 minimum CLTV expiry for its incoming HTLC. Destination nodes may use this
-to require a higher, more conservative value than the default one, depending
-on their fee estimation policy and their sensitivity to time locks. Note
+to require a higher, more conservative value than the default one (depending
+on their fee estimation policy and their sensitivity to time locks). Note
 that remote nodes in the route specify their required `cltv_expiry_delta`
 in the `channel_update` message, which they can update at all times.
 
-The `f` field allows on-chain fallback. This may not make sense for
-tiny or time-sensitive payments, however. It's possible that new
-address forms will appear, and so multiple `f` fields in an implied
-preferred order help with transition, and `f` fields with versions 19-31
+The `f` field allows on-chain fallback; however, this may not make sense for
+tiny or time-sensitive payments. It's possible that new
+address forms will appear; thus, multiple `f` fields (in an implied
+preferred order) help with transition, and `f` fields with versions 19-31
 will be ignored by readers.
 
-The `r` field allows limited routing assistance: as specified it only
-allows minimum information to use private channels, but it could also
+The `r` field allows limited routing assistance: as specified, it only
+allows minimum information to use private channels, however, it could also
 assist in future partial-knowledge routing.
 
 ### Security Considerations for Payment Descriptions
 
 Payment descriptions are user-defined and provide a potential avenue for
-injection attacks, both in the process of rendering and persistence.
+injection attacks: during the processes of both rendering and persistence.
 
 Payment descriptions should always be sanitized before being displayed in
-HTML/Javascript contexts, or any other dynamically interpreted rendering
-frameworks. Implementers should be extra perceptive to the possibility of
-reflected XSS attacks when decoding and displaying payment descriptions. Avoid
+HTML/Javascript contexts (or any other dynamically interpreted rendering
+frameworks). Implementers should be extra perceptive to the possibility of
+reflected XSS attacks, when decoding and displaying payment descriptions. Avoid
 optimistically rendering the contents of the payment request until all
-validation, verification, and sanitization have been successfully completed.
+validation, verification, and sanitization processes have been successfully
+completed.
 
 Furthermore, consider using prepared statements, input validation, and/or
-escaping to protect against injection vulnerabilities against persistence
+escaping, to protect against injection vulnerabilities in persistence
 engines that support SQL or other dynamically interpreted querying languages.
 
 * [Stored and Reflected XSS Prevention](https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
@@ -262,7 +263,7 @@ payments harder to track by adding small variations.
 The intent is that the payer recover the payee's node ID from the
 signature, and after checking that conditions such as fees,
 expiry, and block timeout are acceptable, attempt a payment. It can use `r` fields to
-augment its routing information if necessary to reach the final node.
+augment its routing information, if necessary to reach the final node.
 
 If the payment succeeds but there is a later dispute, the payer can
 prove both the signed offer from the payee and the successful
@@ -270,15 +271,20 @@ payment.
 
 ## Payer / Payee Requirements
 
-A payer SHOULD NOT attempt a payment after the `timestamp` plus
-`expiry` has passed. Otherwise, if a Lightning payment fails, a payer
-MAY attempt to use the address given in the first `f` field that it
-understands for payment. A payer MAY use the sequence of channels
-specified by the `r` field to route to the payee. A payer SHOULD consider the
-fee amount and payment timeout before initiating payment. A payer
-SHOULD use the first `p` field that it did NOT skip as the payment hash.
+A payer:
+  - after the `timestamp` plus `expiry` has passed:
+    - SHOULD NOT attempt a payment.
+  - otherwise:
+    - if a Lightning payment fails:
+      - MAY attempt to use the address given in the first `f` field that it
+      understands for payment.
+  - MAY use the sequence of channels, specified by the `r` field, to route to the payee.
+  - SHOULD consider the fee amount and payment timeout before initiating payment.
+  - SHOULD use the first `p` field that it did NOT skip as the payment hash.
 
-A payee SHOULD NOT accept a payment after `timestamp` plus `expiry`.
+A payee:
+  - after the `timestamp` plus `expiry` has passed:
+    - SHOULD NOT accept a payment.
 
 # Implementation