stylesheet update and apply to BOLT 2,3

.copy-edit-stylesheet-checklist.md

@@ -9,6 +9,7 @@ temporarily included here for reference purposes.
     - dangling, misplaced modifiers
     - consistent paragraph tense (e.g. past, present, future)
     - passive voice (e.g. avoid 'we')
+      - use 'local/remote' terminology rather than 'us/them' or 'we/they'
       - exception: `Introduction` section
   - capitalization
     - table of contents

02-peer-protocol.md

@@ -775,7 +775,7 @@ Invalid amounts are a clear protocol violation and indicate a breakdown.
 
 If a node did not accept multiple HTLCs with the same payment hash, an
 attacker could probe to see if a node had an existing HTLC. This
-requirement, to deal with duplicates, leads us to use a separate
+requirement, to deal with duplicates, leads to the use of a separate
 identifier; its assumed a 64-bit counter never wraps.
 
 Retransmissions of unacknowledged updates are explicitly allowed for

03-transactions.md

@@ -304,7 +304,7 @@ Thus, a simplified formula for *expected weight* is used, which assumes:
 * There are a small number of outputs (thus 1 byte to count them).
 * There are always both a `to_local` output and a `to_remote` output.
 
-This gives us the following *expected weights* (details of the computation in [Appendix A](#appendix-a-expected-weights)):
+This yields the following *expected weights* (details of the computation in [Appendix A](#appendix-a-expected-weights)):
 
     Commitment weight:   724 + 172 * num-untrimmed-htlc-outputs
     HTLC-timeout weight: 663
@@ -518,9 +518,9 @@ In binary, it's helpful to think of any index in terms of a *prefix*,
 followed by some trailing 0s. You can derive the secret for any
 index which matches this *prefix*.
 
-For example, secret `0xFFFFFFFFFFF0` allows us to derive secrets for
-`0xFFFFFFFFFFF1` through `0xFFFFFFFFFFFF` inclusive. Secret `0xFFFFFFFFFF08`
-allows us to derive secrets `0xFFFFFFFFFF09` through `0xFFFFFFFFFF0F`
+For example, secret `0xFFFFFFFFFFF0` allows the secrets to be derived for
+`0xFFFFFFFFFFF1` through `0xFFFFFFFFFFFF`, inclusive; and secret `0xFFFFFFFFFF08`
+allows the secrets to be derive for `0xFFFFFFFFFF09` through `0xFFFFFFFFFF0F`,
 inclusive.
 
 This is done using a slight generalization of `generate_from_seed` above: