Update closing_signed fee requirement (#847)

With anchor outputs, we can keep the commit tx feerate lower than the real
on-chain feerate. That means that when closing the channel, the resulting
fee will not necessarily be lower than the current commit tx fee, this
requirement doesn't make sense to be strict.

Both sides can optionally include a preferred fee range in their
`closing_signed`. This lets their peer know what fees they find acceptable
and simplifies the closing negotiation.

02-peer-protocol.md

@@ -600,11 +600,24 @@ the other node then replies similarly, using a fee it thinks is fair.  This
 exchange continues until both agree on the same fee or when one side fails
 the channel.
 
+In the modern method, the funder sends its permissable fee range, and the
+non-funder has to pick a fee in this range. If the non-funder chooses the same
+value, negotiation is complete after two messages, otherwise the funder will
+reply with the same value (completing after three messages).
+
 1. type: 39 (`closing_signed`)
 2. data:
    * [`channel_id`:`channel_id`]
    * [`u64`:`fee_satoshis`]
    * [`signature`:`signature`]
+   * [`closing_signed_tlvs`:`tlvs`]
+
+1. `tlv_stream`: `closing_signed_tlvs`
+2. types:
+    1. type: 1 (`fee_range`)
+    2. data:
+        * [`u64`:`min_fee_satoshis`]
+        * [`u64`:`max_fee_satoshis`]
 
 #### Requirements
 
@@ -613,12 +626,17 @@ The funding node:
     - SHOULD send a `closing_signed` message.
 
 The sending node:
-  - MUST set `fee_satoshis` less than or equal to the
- base fee of the final commitment transaction, as calculated in [BOLT #3](03-transactions.md#fee-calculation).
-  - SHOULD set the initial `fee_satoshis` according to its
- estimate of cost of inclusion in a block.
-  - MUST set `signature` to the Bitcoin signature of the close
- transaction, as specified in [BOLT #3](03-transactions.md#closing-transaction).
+  - SHOULD set the initial `fee_satoshis` according to its estimate of cost of
+  inclusion in a block.
+  - SHOULD set `fee_range` according to the minimum and maximum fees it is
+  prepared to pay for a close transaction.
+  - if it doesn't receive a `closing_signed` response after a reasonable amount of time:
+    - MUST fail the channel
+  - if it is not the funder:
+    - SHOULD set `max_fee_satoshis` to at least the `max_fee_satoshis` received
+    - SHOULD set `min_fee_satoshis` to a fairly low value
+  - MUST set `signature` to the Bitcoin signature of the close transaction,
+  as specified in [BOLT #3](03-transactions.md#closing-transaction).
 
 The receiving node:
   - if the `signature` is not valid for either variant of closing transaction
@@ -627,31 +645,51 @@ The receiving node:
   - if `fee_satoshis` is equal to its previously sent `fee_satoshis`:
     - SHOULD sign and broadcast the final closing transaction.
     - MAY close the connection.
-  - otherwise, if `fee_satoshis` is greater than
-the base fee of the final commitment transaction as calculated in
-[BOLT #3](03-transactions.md#fee-calculation):
-    - MUST fail the connection.
-  - if `fee_satoshis` is not strictly
-between its last-sent `fee_satoshis` and its previously-received
-`fee_satoshis`, UNLESS it has since reconnected:
+  - if `fee_satoshis` matches its previously sent `fee_range`:
+    - SHOULD use `fee_satoshis` to sign and broadcast the final closing transaction
+    - SHOULD reply with a `closing_signed` with the same `fee_satoshis` value if it is different from its previously sent `fee_satoshis`
+    - MAY close the connection.
+  - if the message contains a `fee_range`:
+    - if there is no overlap between that and its own `fee_range`:
+      - SHOULD fail the connection
+      - MUST fail the channel if it doesn't receive a satisfying `fee_range` after a reasonable amount of time
+    - otherwise:
+      - if it is the funder:
+        - if `fee_satoshis` is not in the overlap between the sent and received `fee_range`:
+          - MUST fail the channel
+        - otherwise:
+          - MUST reply with the same `fee_satoshis`.
+      - otherwise (it is not the funder):
+        - if it has already sent a `closing_signed`:
+          - if `fee_satoshis` is not the same as the value it sent:
+            - MUST fail the channel
+        - otherwise:
+          - MUST propose a `fee_satoshis` in the overlap between received and (about-to-be) sent `fee_range`.
+  - otherwise, if `fee_satoshis` is not strictly between its last-sent `fee_satoshis`
+  and its previously-received `fee_satoshis`, UNLESS it has since reconnected:
     - SHOULD fail the connection.
-  - if the receiver agrees with the fee:
+  - otherwise, if the receiver agrees with the fee:
     - SHOULD reply with a `closing_signed` with the same `fee_satoshis` value.
   - otherwise:
     - MUST propose a value "strictly between" the received `fee_satoshis`
-  and its previously-sent `fee_satoshis`.
+    and its previously-sent `fee_satoshis`.
 
 #### Rationale
 
-The "strictly between" requirement ensures that forward
-progress is made, even if only by a single satoshi at a time. To avoid
-keeping state and to handle the corner case, where fees have shifted
+When `fee_range` is not provided, the "strictly between" requirement ensures
+that forward progress is made, even if only by a single satoshi at a time.
+To avoid keeping state and to handle the corner case, where fees have shifted
 between disconnection and reconnection, negotiation restarts on reconnection.
 
 Note there is limited risk if the closing transaction is
 delayed, but it will be broadcast very soon; so there is usually no
 reason to pay a premium for rapid processing.
 
+Note that the non-funder is not paying the fee, so there is no reason for it
+to have a maximum feerate. It may want a minimum feerate, however, to ensure
+that the transaction propagates. It can always use CPFP later to speed up
+confirmation if necessary, so that minimum should be low.
+
 ## Normal Operation
 
 Once both nodes have exchanged `funding_locked` (and optionally [`announcement_signatures`](07-routing-gossip.md#the-announcement_signatures-message)), the channel can be used to make payments via Hashed Time Locked Contracts.