Cleaned up a couple sentences

Non-Interactive-Protocol.md

@@ -25,12 +25,12 @@ Once funding transaction signatures are exchanged, DLC parties aren't required t
 There are three scenarios to consider:
 
 1. The funding transaction doesn't confirm, and so a party must either bump its fee-rate to confirm
-  before the earliest DLC maturation or else double-spend its funding collateral canceling the DLC.
+    before the earliest DLC maturation or else double-spend its funding collateral canceling the DLC.
   * Child Pays For Parent (CPFP) with BIP 125 Replace by Fee (RBF) enabled is used for fee bumping.
 2. The funding transaction confirms, and the oracle releases the outcome signature, so a
    participant must broadcast the CET corresponding to the oracle outcome.
-3. The funding transaction confirms, and the oracle doesn't release an outcome signature,
-  so a party must broadcast the refund transaction after its time-lock expiration.
+3. The funding transaction confirms, and the oracle doesn't release an outcome signature
+    before the `refund_locktime`, so a party must broadcast the refund transaction.
 
 # General Requirements
 
@@ -59,11 +59,12 @@ A `security_point` is a client-side heuristic time/block-stamp after which the c
 transaction is a matter of contract safety.
 If confirmation does not occur soon after this point, the user can be vulnerable to a malicious double-spend if either
 the outcome odds change or an oracle signature is released.
-This point is determined as a function of the earliest possible event signing time, which may be static or dynamic.
+The `funding_security_point` is determined as a function of the earliest possible event signing time, which may be static or dynamic.
+The `refund_security_point` is determined as a function of the user's trust towards the oracle.
 We defer the exact determination of `security_point`s to the client.
 
-If the signing time is static (block height, epoch) or predictable, we recommend setting 
-`security_point`s to have a confirmation buffer of 20 blocks from earliest signing time.
+If the `security_point` time is static (block height, epoch) or predictable, we recommend setting 
+`security_point`s to have a confirmation buffer of 20 blocks from that time.
 
 A client's `congestion_bump_frequency`/`security_bump_frequency` can be scheduled on at least three
 different kinds of events: