stylesheet update and apply to BOLT 2,3

Author: toadlyBroodle

.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

@@ -110,7 +110,7 @@ across many distinct blockchains as well as have channels within multiple
 blockchains opened to the same peer (if it supports the target chains).
 
 The `temporary_channel_id` is used to identify this channel until the
-funding transaction is established. 
+funding transaction is established.
 
 `funding_satoshis` is the amount the sender is putting into the
 channel. `push_msat` is an amount of initial funds that the sender is
@@ -119,21 +119,21 @@ threshold below which outputs should not be generated for this node's
 commitment or HTLC transactions (i.e. HTLCs below this amount plus
 HTLC transaction fees are not enforceable on-chain). This reflects the
 reality that tiny outputs are not considered standard transactions and
-will not propagate through the Bitcoin network. `channel_reserve_satoshis` 
+will not propagate through the Bitcoin network. `channel_reserve_satoshis`
 is the minimum amount that the other node is to keep as a direct
 payment. `htlc_minimum_msat` indicates the smallest value HTLC this
 node will accept.
 
 `max_htlc_value_in_flight_msat` is a cap on total value of outstanding
 HTLCs, which allows a node to limit its exposure to HTLCs; similarly,
 `max_accepted_htlcs` limits the number of outstanding HTLCs the other
-node can offer. 
+node can offer.
 
 `feerate_per_kw` indicates the initial fee rate by 1000-weight
 (i.e. 1/4 the more normally-used 'fee rate per kilobyte') that this
 side will pay for commitment and HTLC transactions, as described in
 [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted
-later with an `update_fee` message). 
+later with an `update_fee` message).
 
 `to_self_delay` is the number of blocks that the other node's to-self
 outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this
@@ -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: