Improve wording

Author: alfred-hodler

bip-alfredhodler-privatepayments.mediawiki

@@ -120,7 +120,7 @@ When Alice wants to notify Bob that he will receive future payments from her, sh
 # Commits to one of Bob's accepted address types by choosing its ordinal value. Going forward Alice must not send to address types other than the one she committed to in the notification.
 # Constructs a notification payload by concatenating the above values according to the formula.
 # Selects any UTXO in her wallet, preferably not associated with her.
-# Sends a transaction with a single <code>OP_RETURN</code> output whose value is set to the constructed payload.
+# Sends a transaction including an <code>OP_RETURN</code> output whose value is set to the constructed payload.
 
 When Bob notices an <code>OP_RETURN</code> starting with the search key, he performs the following procedure:
 
@@ -218,7 +218,7 @@ When Bob wants to spend from such addresses, he calculates his private keys in t
 
 '''p<sub>c</sub>:''' 0xf2f9c44c15a0b9f3590ab36e6324ab781b12e3f40abc745611d06a46894aab88
 
-==Appendix B: Potential OP_RUTURN Services==
+==Appendix B: Potential OP_RETURN Services==
 
 Compact Block Filters, as formulated in BIP-0158, do not cover <code>OP_RETURN</code> data payloads. In support of light wallets, an external service could publish transaction proofs for all transactions that include the tagged notification payload. Light wallets would download all such transactions, filter for matches against their payment code, then verify the transaction proofs against the block headers obtained over the P2P network.