Add funding expiry to channel open

Routing nodes have an incentive to use low fees when opening channels to
ensure their activity is economically viable.

However, when a funding transaction takes too long to confirm, the fundee
may have forgotten the channel. In that case the funder is forced to
broadcast the first commit tx to get his funds back and then open a new
channel, which is costly.

We can avoid this issue by having an explicit commitment to a block before
which the funding tx will be confirmed. The fundee will keep the channel
around for that duration, and the funder needs to ensure the funding tx
confirms before that deadline.

02-peer-protocol.md

@@ -130,6 +130,9 @@ the funding transaction and both versions of the commitment transaction.
     1. type: 0 (`upfront_shutdown_script`)
     2. data:
         * [`...*byte`:`shutdown_scriptpubkey`]
+    1. type: 1 (`funding_expiry`)
+    2. data:
+        * [`tu32`:`funding_expiry_block`]
 
 The `chain_hash` value denotes the exact blockchain that the opened channel will
 reside within. This is usually the genesis hash of the respective blockchain.
@@ -192,6 +195,9 @@ The `shutdown_scriptpubkey` allows the sending node to commit to where
 funds will go on mutual close, which the remote node should enforce
 even if a node is compromised later.
 
+The `funding_expiry` is a commitment from the funder that the funding
+transaction will be confirmed before the provided block.
+
 The `option_support_large_channel` is a feature used to let everyone 
 know this node will accept `funding_satoshis` greater than or equal to 2^24.
 Since it's broadcast in the `node_announcement` message other nodes can use it to identify peers 
@@ -239,6 +245,7 @@ The receiving node MAY fail the channel if:
   - it considers `channel_reserve_satoshis` too large.
   - it considers `max_accepted_htlcs` too small.
   - it considers `dust_limit_satoshis` too small and plans to rely on the sending node publishing its commitment transaction in the event of a data loss (see [message-retransmission](02-peer-protocol.md#message-retransmission)).
+  - it considers `funding_expiry` too large.
 
 The receiving node MUST fail the channel if:
   - the `chain_hash` value is set to a hash of a chain that is unknown to the receiver.
@@ -351,6 +358,8 @@ The sender MUST set:
 The sender:
   - when creating the funding transaction:
     - SHOULD use only BIP141 (Segregated Witness) inputs.
+  - if it committed to a `funding_expiry` in `open_channel`:
+    - MUST ensure the funding transaction confirms before `funding_expiry` is reached
 
 The recipient:
   - if `signature` is incorrect OR non-compliant with LOW-S-standard rule<sup>[LOWS](https://github.com/bitcoin/bitcoin/pull/6769)</sup>:
@@ -362,6 +371,8 @@ The `funding_output_index` can only be 2 bytes, since that's how it's packed int
 
 A transaction with all Segregated Witness inputs is not malleable, hence the funding transaction recommendation.
 
+The funder may use CPFP on a change output to ensure that the funding transaction confirms before `funding_expiry`.
+
 ### The `funding_signed` Message
 
 This message gives the funder the signature it needs for the first
@@ -415,16 +426,15 @@ This message indicates that the funding transaction has reached the `minimum_dep
 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
-per-commitment point to be used for the following commitment
-transaction, derived as specified in
-[BOLT #3](03-transactions.md#per-commitment-secret-requirements).
+  - wait until the funding transaction has reached `minimum_depth` before
+  sending this message.
+  - set `next_per_commitment_point` to the per-commitment point to be used
+  for the following commitment 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 correct
-funding transaction after a reasonable timeout.
+  - SHOULD forget the channel if it does not see the correct funding
+  transaction after `funding_expiry` (if provided) or a reasonable timeout.
 
 From the point of waiting for `funding_locked` onward, either node MAY
 fail the channel if it does not receive a required response from the
@@ -437,6 +447,11 @@ 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).
 
+If the fundee forgets the channel before it was confirmed, the funder will need
+to broadcast the commitment transaction to get his funds back and open a new
+channel. To avoid this, the funder should set `funding_expiry` and ensure the
+funding transaction confirms in time.
+
 ## Channel Close
 
 Nodes can negotiate a mutual close of the connection, which unlike a