diff --git a/.aspell.en.pws b/.aspell.en.pws
index 7de4fad86..bf7e2213a 100644
--- a/.aspell.en.pws
+++ b/.aspell.en.pws
@@ -358,6 +358,7 @@ optimizations
 structs
 CompactSize
 encodings
+remotekey
 bigsize
 BigSize
 namespaces
@@ -370,3 +371,4 @@ tlvs
 snprintf
 GitHub
 IRC
+bitmasks
diff --git a/.copy-edit-stylesheet-checklist.md b/.copy-edit-stylesheet-checklist.md
index 2a986e512..1f8660e33 100644
--- a/.copy-edit-stylesheet-checklist.md
+++ b/.copy-edit-stylesheet-checklist.md
@@ -1,6 +1,6 @@
 # Basic checklist/stylesheet used for copy editing BOLTs
 
-Contributions should comply with this checklist/stylsheet to maintain correct, clear, consistent, and concise BOLTS. 
+Contributions should comply with this checklist/stylesheet to maintain correct, clear, consistent, and concise BOLTS. 
 
   - spelling
     - run `tools/spellcheck.sh --check [0-9][0-9]-*.md`
diff --git a/01-messaging.md b/01-messaging.md
index 32f37c3df..3b2742aaa 100644
--- a/01-messaging.md
+++ b/01-messaging.md
@@ -108,7 +108,11 @@ messages, a `tlv_stream` is typically placed after all currently defined fields.
 
 The `type` is a varint encoded using the BigSize format. It functions as a
 message-specific, 64-bit identifier for the `tlv_record` determining how the
-contents of `value` should be decoded.
+contents of `value` should be decoded. `type` identifiers below 2^16 are
+reserved for use in this specification. `type` identifiers greater than or equal
+to 2^16 are available for custom records. Any record not defined in this
+specification is considered a custom record. This includes experimental and
+application-specific messages.
 
 The `length` is a varint encoded using the BigSize format signaling the size of
 `value` in bytes.
@@ -121,6 +125,13 @@ according to the message-specific format determined by `type`.
 The sending node:
  - MUST order `tlv_record`s in a `tlv_stream` by monotonically-increasing `type`.
  - MUST minimally encode `type` and `length`.
+ - When defining custom record `type` identifiers:
+   - SHOULD pick random `type` identifiers to avoid collision with other
+     custom types.
+   - SHOULD pick odd `type` identifiers when regular nodes should ignore the
+     additional data.
+   - SHOULD pick even `type` identifiers when regular nodes should reject the
+     full tlv stream containing the custom record.
  - SHOULD NOT use redundant, variable-length encodings in a `tlv_record`.
 
 The receiving node:
@@ -158,7 +169,7 @@ structs, should do so by defining the encoding such that the object is
 serialized within a single `tlv_record`. The uniqueness constraint, among other
 things, enables the following optimizations:
  - canonical ordering is defined independent of the encoded `value`s.
- - canonical ordering can be known at compile-time, rather that being determined
+ - canonical ordering can be known at compile-time, rather than being determined
    dynamically at the time of encoding.
  - verifying canonical ordering requires less state and is less-expensive.
  - variable-size fields can reserve their expected size up front, rather than
@@ -215,14 +226,14 @@ The following convenience types are also defined:
 
 Once authentication is complete, the first message reveals the features supported or required by this node, even if this is a reconnection.
 
-[BOLT #9](09-features.md) specifies lists of features. Each feature is generally represented by 2 bits. The least-significant bit is numbered 0, which is _even_, and the next most significant bit is numbered 1, which is _odd_.
+[BOLT #9](09-features.md) specifies lists of features. Each feature is generally represented by 2 bits. The least-significant bit is numbered 0, which is _even_, and the next most significant bit is numbered 1, which is _odd_.  For historical reasons, features are divided into global and local feature bitmasks.
 
 The `features` field MUST be padded to bytes with 0s.
 
 1. type: 16 (`init`)
 2. data:
-   * [`u16`:`ignorelen`]
-   * [`ignorelen*byte`:`ignore`]
+   * [`u16`:`gflen`]
+   * [`gflen*byte`:`globalfeatures`]
    * [`u16`:`flen`]
    * [`flen*byte`:`features`]
 
@@ -231,9 +242,9 @@ The `features` field MUST be padded to bytes with 0s.
 
 The sending node:
   - MUST send `init` as the first Lightning message for any connection.
-  - MUST set `ignorelen` to zero.
   - MUST set feature bits as defined in [BOLT #9](09-features.md).
   - MUST set any undefined feature bits to 0.
+  - SHOULD NOT set features greater than 13 in `globalfeatures`.
   - SHOULD use the minimum length required to represent the `features` field.
 
 The receiving node:
@@ -246,7 +257,8 @@ The receiving node:
 
 #### Rationale
 
-There used to be two feature bitfields here, but the first is now ignored.
+There used to be two feature bitfields here, but for backwards compatibility they're now
+combined into one.
 
 This semantic allows both future incompatible changes and future backward compatible changes. Bits should generally be assigned in pairs, in order that optional features may later become compulsory.
 
@@ -416,8 +428,8 @@ function that takes a `uint64` value `x` and produces:
 Here `+` denotes concatenation and `be16`, `be32`, and `be64` produce a
 big-endian encoding of the input for 16, 32, and 64-bit integers, respectively.
 
-A value is said to be _minimally encoded_ if it could have been encoded using a
-smaller representation. For example, a BigSize encoding that occupies 5 bytes
+A value is said to be _minimally encoded_ if it could not be encoded using
+fewer bytes. For example, a BigSize encoding that occupies 5 bytes
 but whose value is less than 0x10000 is not minimally encoded. All values
 decoded with BigSize should be checked to ensure they are minimally encoded.
 
@@ -862,7 +874,7 @@ failure:
 
 ## References
 
-1. <a id="reference-2">http://www.unicode.org/charts/PDF/U2600.pdf</a>
+1. <a id="reference-1">http://www.unicode.org/charts/PDF/U2600.pdf</a>
 
 ## Authors
 
diff --git a/02-peer-protocol.md b/02-peer-protocol.md
index 1cbf488c2..03d44717a 100644
--- a/02-peer-protocol.md
+++ b/02-peer-protocol.md
@@ -6,7 +6,7 @@ operation, and closing.
 # Table of Contents
 
   * [Channel](#channel)
-    * [Definition of `channel_id`](#definition-of-channel-id)
+    * [Definition of `channel_id`](#definition-of-channel_id)
     * [Channel Establishment](#channel-establishment)
       * [The `open_channel` Message](#the-open_channel-message)
       * [The `accept_channel` Message](#the-accept_channel-message)
@@ -365,6 +365,12 @@ This message introduces the `channel_id` to identify the channel. It's derived f
 
 #### Requirements
 
+Both peers:
+  - if `option_static_remotekey` was negotiated:
+    - `option_static_remotekey` applies to all commitment transactions
+  - otherwise:
+    - `option_static_remotekey` does not apply to any commitment transactions
+
 The sender MUST set:
   - `channel_id` by exclusive-OR of the `funding_txid` and the `funding_output_index` from the `funding_created` message.
   - `signature` to the valid signature, using its `funding_pubkey` for the initial commitment transaction, as defined in [BOLT #3](03-transactions.md#commitment-transaction).
@@ -376,6 +382,12 @@ The recipient:
   - on receipt of a valid `funding_signed`:
     - SHOULD broadcast the funding transaction.
 
+#### Rationale
+
+We decide on `option_static_remotekey` at this point when we first have to generate the commitment
+transaction.  Even if a later reconnection does not negotiate this parameter, this channel will continue to use `option_static_remotekey`; we don't support "downgrading".
+This simplifies channel state, particularly penalty transaction handling.
+
 ### The `funding_locked` Message
 
 This message indicates that the funding transaction has reached the `minimum_depth` asked for in `accept_channel`. Once both nodes have sent this, the channel enters normal operating mode.
@@ -388,6 +400,8 @@ This message indicates that the funding transaction has reached the `minimum_dep
 #### Requirements
 
 The sender MUST:
+  - NOT send `funding_locked` unless outpoint of given by `funding_txid` and
+   `funding_output_index` in the `funding_created` message pays exactly `funding_satoshis` to the scriptpubkey specified in [BOLT #3](03-transactions.md#funding-transaction-output).
   - wait until the funding transaction has reached
 `minimum_depth` before sending this message.
   - set `next_per_commitment_point` to the
@@ -396,7 +410,7 @@ transaction, derived as specified in
 [BOLT #3](03-transactions.md#per-commitment-secret-requirements).
 
 A non-funding node (fundee):
-  - SHOULD forget the channel if it does not see the
+  - SHOULD forget the channel if it does not see the correct
 funding transaction after a reasonable timeout.
 
 From the point of waiting for `funding_locked` onward, either node MAY
@@ -410,11 +424,6 @@ funds are at risk. If the fundee were to remember the channel forever, this
 would create a Denial of Service risk; therefore, forgetting it is recommended
 (even if the promise of `push_msat` is significant).
 
-#### Future
-
-An SPV proof could be added and block hashes could be routed in separate
-messages.
-
 ## Channel Close
 
 Nodes can negotiate a mutual close of the connection, which unlike a
@@ -835,7 +844,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 to the use of a separate
-identifier; its assumed a 64-bit counter never wraps.
+identifier; it's assumed a 64-bit counter never wraps.
 
 Retransmissions of unacknowledged updates are explicitly allowed for
 reconnection purposes; allowing them at other times simplifies the
@@ -1118,8 +1127,8 @@ messages are), they are independent of requirements here.
    * [`channel_id`:`channel_id`]
    * [`u64`:`next_commitment_number`]
    * [`u64`:`next_revocation_number`]
-   * [`32*byte`:`your_last_per_commitment_secret`] (option_data_loss_protect)
-   * [`point`:`my_current_per_commitment_point`] (option_data_loss_protect)
+   * [`32*byte`:`your_last_per_commitment_secret`] (option_data_loss_protect,option_static_remotekey)
+   * [`point`:`my_current_per_commitment_point`] (option_data_loss_protect,option_static_remotekey)
 
 `next_commitment_number`: A commitment number is a 48-bit
 incrementing counter for each commitment transaction; counters
@@ -1167,10 +1176,13 @@ The sending node:
   next `commitment_signed` it expects to receive.
   - MUST set `next_revocation_number` to the commitment number of the
   next `revoke_and_ack` message it expects to receive.
-  - if it supports `option_data_loss_protect`:
+  - if `option_static_remotekey` applies to the commitment transaction:
+    - MUST set `my_current_per_commitment_point` to a valid point.
+  - otherwise, if it supports `option_data_loss_protect`:
     - MUST set `my_current_per_commitment_point` to its commitment point for
       the last signed commitment it received from its channel peer (i.e. the commitment_point 
       corresponding to the commitment transaction the sender would use to unilaterally close).
+  - if `option_static_remotekey` applies to the commitment transaction, or the sending node supports `option_data_loss_protect`:
     - if `next_revocation_number` equals 0:
       - MUST set `your_last_per_commitment_secret` to all zeroes
     - otherwise:
@@ -1209,7 +1221,16 @@ A node:
       - SHOULD fail the channel.
 
  A receiving node:
-  - if it supports `option_data_loss_protect`, AND the `option_data_loss_protect`
+  - if `option_static_remotekey` applies to the commitment transaction:
+    - if `next_revocation_number` is greater than expected above, AND
+    `your_last_per_commitment_secret` is correct for that
+    `next_revocation_number` minus 1:
+      - MUST NOT broadcast its commitment transaction.
+      - SHOULD fail the channel.
+    - otherwise:
+	  - if `your_last_per_commitment_secret` does not match the expected values:
+        - SHOULD fail the channel.
+  - otherwise, if it supports `option_data_loss_protect`, AND the `option_data_loss_protect`
   fields are present:
     - if `next_revocation_number` is greater than expected above, AND
     `your_last_per_commitment_secret` is correct for that
@@ -1302,6 +1323,14 @@ is valid. However, this also means the fallen-behind node has revealed this
 fact (though not provably: it could be lying), and the other node could use this to
 broadcast a previous state.
 
+`option_static_remotekey` removes the changing `to_remote` key,
+so the `my_current_per_commitment_point` is unnecessary and thus
+ignored (for parsing simplicity, it remains and must be a valid point,
+however), but the disclosure of previous secret still allows
+fall-behind detection.  An implementation can offer both, however, and
+fall back to the `option_data_loss_protect` behavior if
+`option_static_remotekey` is not negotiated.
+
 # Authors
 
 [ FIXME: Insert Author List ]
diff --git a/03-transactions.md b/03-transactions.md
index 805e6983d..c72bd0981 100644
--- a/03-transactions.md
+++ b/03-transactions.md
@@ -411,9 +411,9 @@ committed HTLCs:
 
 ## Key Derivation
 
-Each commitment transaction uses a unique set of keys: `localpubkey` and `remotepubkey`.
+Each commitment transaction uses a unique `localpubkey`, and a `remotepubkey`.
 The HTLC-success and HTLC-timeout transactions use `local_delayedpubkey` and `revocationpubkey`.
-These are changed for every transaction based on the `per_commitment_point`.
+These are changed for every transaction based on the `per_commitment_point`, with the exception of `remotepubkey` if `option_static_remotekey` is negotiated.
 
 The reason for key change is so that trustless watching for revoked
 transactions can be outsourced. Such a _watcher_ should not be able to
@@ -426,8 +426,9 @@ avoid storage of every commitment transaction, a _watcher_ can be given the
 the scripts required for the penalty transaction; thus, a _watcher_ need only be
 given (and store) the signatures for each penalty input.
 
-Changing the `localpubkey` and `remotepubkey` every time ensures that commitment
-transaction ID cannot be guessed; every commitment transaction uses an ID
+Changing the `localpubkey` every time ensures that commitment
+transaction ID cannot be guessed except in the trivial case where there is no
+`to_local` output, as every commitment transaction uses an ID
 in its output script. Splitting the `local_delayedpubkey`, which is required for
 the penalty transaction, allows it to be shared with the _watcher_ without
 revealing `localpubkey`; even if both peers use the same _watcher_, nothing is revealed.
@@ -441,14 +442,13 @@ For efficiency, keys are generated from a series of per-commitment secrets
 that are generated from a single seed, which allows the receiver to compactly
 store them (see [below](#efficient-per-commitment-secret-storage)).
 
-### `localpubkey`, `remotepubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey` Derivation
+### `localpubkey`, `local_htlcpubkey`, `remote_htlcpubkey`, `local_delayedpubkey`, and `remote_delayedpubkey` Derivation
 
 These pubkeys are simply generated by addition from their base points:
 
 	pubkey = basepoint + SHA256(per_commitment_point || basepoint) * G
 
 The `localpubkey` uses the local node's `payment_basepoint`;
-the `remotepubkey` uses the remote node's `payment_basepoint`;
 the `local_htlcpubkey` uses the local node's `htlc_basepoint`;
 the `remote_htlcpubkey` uses the remote node's `htlc_basepoint`;
 the `local_delayedpubkey` uses the local node's `delayed_payment_basepoint`;
@@ -459,6 +459,19 @@ secrets are known (i.e. the private keys corresponding to `localpubkey`, `local_
 
     privkey = basepoint_secret + SHA256(per_commitment_point || basepoint)
 
+### `remotepubkey` Derivation
+
+If `option_static_remotekey` is negotiated the `remotepubkey` is simply the
+remote node's `payment_basepoint`, otherwise it is calculated as above using
+the remote node's `payment_basepoint`.
+
+The simplified derivation means that a node can spend a commitment
+transaction even if it has lost data and doesn't know the
+corresponding `per_commitment_point`.  A watchtower could correlate
+transactions given to it which only have a `to_remote` output if it
+sees one of them onchain, but such transactions do not need any
+enforcement and should not be handed to a watchtower.
+
 ### `revocationpubkey` Derivation
 
 The `revocationpubkey` is a blinded key: when the local node wishes to create a new
diff --git a/07-routing-gossip.md b/07-routing-gossip.md
index 80f812c0b..f4b2e2d3c 100644
--- a/07-routing-gossip.md
+++ b/07-routing-gossip.md
@@ -453,21 +453,21 @@ The origin node:
   - otherwise:
     - MUST set the `direction` bit of `channel_flags` to 1.
   - if the `htlc_maximum_msat` field is present:
-	- MUST set the `option_channel_htlc_max` bit of `message_flags` to 1.
-	- MUST set `htlc_maximum_msat` to the maximum value it will send through this channel for a single HTLC.
-		- MUST set this to less than or equal to the channel capacity.
-		- MUST set this to less than or equal to `max_htlc_value_in_flight_msat`
-		  it received from the peer.
-        - for channels with `chain_hash` identifying the Bitcoin blockchain:
-          - MUST set this to less than 2^32.
+    - MUST set the `option_channel_htlc_max` bit of `message_flags` to 1.
+    - MUST set `htlc_maximum_msat` to the maximum value it will send through this channel for a single HTLC.
+      - MUST set this to less than or equal to the channel capacity.
+      - MUST set this to less than or equal to `max_htlc_value_in_flight_msat`
+    it received from the peer.
+      - for channels with `chain_hash` identifying the Bitcoin blockchain:
+        - MUST set this to less than 2^32.
   - otherwise:
-	- MUST set the `option_channel_htlc_max` bit of `message_flags` to 0.
+    - MUST set the `option_channel_htlc_max` bit of `message_flags` to 0.
   - MUST set bits in `channel_flags` and `message_flags `that are not assigned a meaning to 0.
   - MAY create and send a `channel_update` with the `disable` bit set to 1, to
   signal a channel's temporary unavailability (e.g. due to a loss of
   connectivity) OR permanent unavailability (e.g. prior to an on-chain
   settlement).
-    - MAY sent a subsequent `channel_update` with the `disable` bit  set to 0 to
+    - MAY sent a subsequent `channel_update` with the `disable` bit set to 0 to
     re-enable the channel.
   - MUST set `timestamp` to greater than 0, AND to greater than any
   previously-sent `channel_update` for this `short_channel_id`.
@@ -517,10 +517,10 @@ The receiving node:
     - MUST consider `htlc_maximum_msat` not to be present.
   - otherwise:
     - if `htlc_maximum_msat` is not present or greater than channel capacity:
-	  - MAY blacklist this `node_id`
-	  - SHOULD ignore this channel during route considerations.
-	- otherwise:
-	  - SHOULD consider the `htlc_maximum_msat` when routing.
+      - MAY blacklist this `node_id`
+      - SHOULD ignore this channel during route considerations.
+    - otherwise:
+      - SHOULD consider the `htlc_maximum_msat` when routing.
 
 ### Rationale
 
@@ -576,7 +576,7 @@ Note that a 65535-byte zlib message can decompress into 67632120
 bytes<sup>[2](#reference-2)</sup>, but since the only valid contents
 are unique 8-byte values, no more than 14 bytes can be duplicated
 across the stream: as each duplicate takes at least 2 bits, no valid
-contents could decompress to more then 3669960 bytes.
+contents could decompress to more than 3669960 bytes.
 
 Query messages can be extended with optional fields that can help reduce the number of messages needed to synchronize routing tables by enabling:
 
@@ -598,6 +598,7 @@ Nodes can signal that they support extended gossip queries with the `gossip_quer
 2. types:
     1. type: 1 (`query_flags`)
     2. data:
+        * [`u8`:`encoding_type`]
         * [`...*byte`:`encoded_query_flags`]
 
 `encoded_query_flags` is an array of bitfields, one varint per bitfield, one bitfield for each `short_channel_id`. Bits have the following meaning:
@@ -670,13 +671,13 @@ The receiver:
         - MUST reply with the latest `node_announcement` for `node_id_1`
       - if bit 4 of `query_flag` is set and it has received a `node_announcement` from `node_id_2`:
         - MUST reply with the latest `node_announcement` for `node_id_2`
-	- SHOULD NOT wait for the next outgoing gossip flush to send these.
+    - SHOULD NOT wait for the next outgoing gossip flush to send these.
   - SHOULD avoid sending duplicate `node_announcements` in response to a single `query_short_channel_ids`.
   - MUST follow these responses with `reply_short_channel_ids_end`.
   - if does not maintain up-to-date channel information for `chain_hash`:
-	- MUST set `complete` to 0.
+    - MUST set `complete` to 0.
   - otherwise:
-	- SHOULD set `complete` to 1.
+    - SHOULD set `complete` to 1.
 
 #### Rationale
 
@@ -723,14 +724,15 @@ Though it is possible, it would not be very useful to ask for checksums without
     * [`len*byte`:`encoded_short_ids`]
     * [`reply_channel_range_tlvs`:`tlvs`]
 
-1. tlvs: `query_channel_range_tlvs`
+1. tlvs: `reply_channel_range_tlvs`
 2. types:
     1. type: 1 (`timestamps_tlv`)
     2. data:
+        * [`u8`:`encoding_type`]
         * [`...*byte`:`encoded_timestamps`]
     1. type: 3 (`checksums_tlv`)
     2. data:
-        * [`...*byte`:`checksums`]
+        * [`...*channel_update_checksums`:`checksums`]
 
 For a single `channel_update`, timestamps are encoded as:
 
@@ -772,8 +774,7 @@ The receiver of `query_channel_range`:
   - if it has not sent all `reply_channel_range` to a previously received `query_channel_range` from this sender:
     - MAY fail the connection.
   - MUST respond with one or more `reply_channel_range` whose combined range
-	cover the requested `first_blocknum` to `first_blocknum` plus
-	`number_of_blocks` minus one.
+  cover the requested `first_blocknum` to `first_blocknum` plus `number_of_blocks` minus one.
   - For each `reply_channel_range`:
     - MUST set with `chain_hash` equal to that of `query_channel_range`,
     - MUST encode a `short_channel_id` for every open channel it knows in blocks `first_blocknum` to `first_blocknum` plus `number_of_blocks` minus one.
@@ -823,17 +824,17 @@ The receiver:
   - SHOULD send all gossip messages whose `timestamp` is greater or
     equal to `first_timestamp`, and less than `first_timestamp` plus
     `timestamp_range`.
-	- MAY wait for the next outgoing gossip flush to send these.
+    - MAY wait for the next outgoing gossip flush to send these.
   - SHOULD restrict future gossip messages to those whose `timestamp`
     is greater or equal to `first_timestamp`, and less than
     `first_timestamp` plus `timestamp_range`.
   - If a `channel_announcement` has no corresponding `channel_update`s:
-	- MUST NOT send the `channel_announcement`.
+    - MUST NOT send the `channel_announcement`.
   - Otherwise:
-	  - MUST consider the `timestamp` of the `channel_announcement` to be the `timestamp` of a corresponding `channel_update`.
-	  - MUST consider whether to send the `channel_announcement` after receiving the first corresponding `channel_update`.
+    - MUST consider the `timestamp` of the `channel_announcement` to be the `timestamp` of a corresponding `channel_update`.
+    - MUST consider whether to send the `channel_announcement` after receiving the first corresponding `channel_update`.
   - If a `channel_announcement` is sent:
-	  - MUST send the `channel_announcement` prior to any corresponding `channel_update`s and `node_announcement`s.
+    - MUST send the `channel_announcement` prior to any corresponding `channel_update`s and `node_announcement`s.
 
 #### Rationale
 
@@ -868,7 +869,7 @@ interactions with them.
 
 A node:
   - if the `gossip_queries` feature is negotiated:
-	- MUST NOT relay any gossip messages unless explicitly requested.
+    - MUST NOT relay any gossip messages unless explicitly requested.
   - otherwise:
     - if it requires a full copy of the peer's routing state:
       - SHOULD set the `initial_routing_sync` flag to 1.
@@ -900,7 +901,7 @@ A receiving node:
 
 A node:
   - if the `gossip_queries` feature is negotiated:
-	- MUST not send gossip until it receives `gossip_timestamp_filter`.
+    - MUST not send gossip until it receives `gossip_timestamp_filter`.
   - SHOULD flush outgoing gossip messages once every 60 seconds, independently of
   the arrival times of the messages.
     - Note: this results in staggered announcements that are unique (not
@@ -1065,7 +1066,7 @@ per [HTLC Fees](#htlc-fees):
 
         fee_base_msat + ( amount_to_forward * fee_proportional_millionths / 1000000 )
 
-	200 + ( 4999999 * 2000 / 1000000 ) = 10199
+        200 + ( 4999999 * 2000 / 1000000 ) = 10199
 
 Similarly, it would need to add B->C's `channel_update` `cltv_expiry` (20), C's
 requested `min_final_cltv_expiry` (9), and the cost for the _shadow route_ (42).
@@ -1085,7 +1086,7 @@ A->D's `update_add_htlc` message would be:
    * `amount_msat`: 5020398
    * `cltv_expiry`: current-block-height + 40 + 9 + 42
    * `onion_routing_packet`:
-	 * `amt_to_forward` = 4999999
+     * `amt_to_forward` = 4999999
      * `outgoing_cltv_value` = current-block-height + 9 + 42
 
 And D->C's `update_add_htlc` would again be the same as B->C's direct payment
diff --git a/08-transport.md b/08-transport.md
index a2c5d661c..699b02b0f 100644
--- a/08-transport.md
+++ b/08-transport.md
@@ -153,8 +153,7 @@ Throughout the handshake process, each side maintains these variables:
 The following functions will also be referenced:
 
   * `ECDH(k, rk)`: performs an Elliptic-Curve Diffie-Hellman operation using
-    `k`, which is a valid private key, and `rk`, which is a `secp256k1` public key
-    within the finite field, as defined by the curve parameters
+    `k`, which is a valid `secp256k1` private key, and `rk`, which is a valid public key
       * The returned value is the SHA256 of the DER-compressed format of the
 	    generated point.
 
diff --git a/09-features.md b/09-features.md
index ca465dbdc..c684ff2db 100644
--- a/09-features.md
+++ b/09-features.md
@@ -12,9 +12,6 @@ can be introduced as optional (_odd_ bits) and later upgraded to be compulsory
 (_even_ bits), which will be refused by outdated nodes:
 see [BOLT #1: The `init` Message](01-messaging.md#the-init-message).
 
-
-## Assigned `features` flags
-
 Some features don't make sense on a per-channels or per-node basis, so
 each feature defines how it is presented in those contexts.  Some
 features may be required for opening a channel, but not a requirement
@@ -27,6 +24,7 @@ The Context column decodes as follows:
 * `C`: presented in the `channel_announcement` message.
 * `C-`: presented in the `channel_announcement` message, but always odd (optional).
 * `C+`: presented in the `channel_announcement` message, but always even (required).
+* `9`: presented in [BOLT 11](11-payment-encoding.md) invoices.
 
 | Bits  | Name                             | Description                                               | Context  | Link                                  |
 |-------|----------------------------------|-----------------------------------------------------------|----------|---------------------------------------|
@@ -36,6 +34,7 @@ The Context column decodes as follows:
 | 6/7   | `gossip_queries`                 | More sophisticated gossip control                         | IN       | [BOLT #7][bolt07-query]               |
 | 8/9   | `var_onion_optin`                | Requires/supports variable-length routing onion payloads  | IN       | [Routing Onion Specification][bolt04] |
 | 10/11 | `gossip_queries_ex`              | Gossip queries can include additional information         | IN       | [BOLT #7][bolt07-query]               |
+| 12/13 | `option_static_remotekey`         | Static key for remote output                              | IN       | [BOLT #3](03-transactions.md)         |
 | 14/15 | `option_support_large_channel`   | Can create large channels                                 | INC+     | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
 
 ## Requirements
diff --git a/11-payment-encoding.md b/11-payment-encoding.md
index d22d4de8a..e9a28770a 100644
--- a/11-payment-encoding.md
+++ b/11-payment-encoding.md
@@ -272,7 +272,8 @@ Don't be like the school of [Little Bobby Tables](https://xkcd.com/327/).
 ## Feature Bits
 
 Feature bits allow forward and backward compatibility, and follow the
-_it's ok to be odd_ rule.
+_it's ok to be odd_ rule.  Features appropriate for use in the `9` field
+are marked in [BOLT 9](09-features.md).
 
 The field is big-endian.  The least-significant bit is numbered 0,
 which is _even_, and the next most significant bit is numbered 1,
@@ -285,9 +286,9 @@ but it's worth noting that [BOLT #4](04-onion-routing.md#requirements-2) specifi
 accept up to twice the expected `amount`, so the payer can make
 payments harder to track by adding small variations.
 
-The intent is that the payer recover the payee's node ID from the
+The intent is that the payer recovers 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
+expiry, and block timeout are acceptable, attempts a payment. It can use `r` fields to
 augment its routing information, if necessary to reach the final node.
 
 If the payment succeeds but there is a later dispute, the payer can