Add require_confirmed_inputs TLV

This lets any side of the protocol require the other side to use confirmed
inputs, to avoid paying the fees of a low feerate unconfirmed ancestor.

02-peer-protocol.md

@@ -1121,6 +1121,9 @@ This message initiates the v2 channel establishment workflow.
    1. type: 1 (`channel_type`)
    2. data:
         * [`...*byte`:`type`]
+   1. type: 2 (`require_confirmed_inputs`)
+   2. data:
+        * [`0*byte`:``]
 
 Rationale and Requirements are the same as for [`open_channel`](#the-open_channel-message),
 with the following additions.
@@ -1133,11 +1136,15 @@ If nodes have negotiated `option_dual_fund`:
 
 The sending node:
   - MUST set `funding_feerate_perkw` to the feerate for this transaction
+  - If it requires the receiving node to only use confirmed inputs:
+    - MUST set `require_confirmed_inputs`
 
 The receiving node:
   - MAY fail the negotiation if:
     - the `locktime` is unacceptable
     - the `funding_feerate_perkw` is unacceptable
+  - MUST fail the negotiation if:
+    - `require_confirmed_inputs` is set but it cannot provide confirmed inputs
 
 #### Rationale
 
@@ -1164,6 +1171,10 @@ whichever is greater.
 
 Note that `push_msat` has been omitted.
 
+The sending node may require the other participant to only use confirmed inputs.
+This ensures that the sending node doesn't end up paying the fees of a low
+feerate unconfirmed ancestor of one of the other participant's inputs.
+
 ### The `accept_channel2` Message
 
 This message contains information about a node and indicates its
@@ -1195,6 +1206,9 @@ acceptance of the new channel.
    1. type: 1 (`channel_type`)
    2. data:
         * [`...*byte`:`type`]
+   1. type: 2 (`require_confirmed_inputs`)
+   2. data:
+        * [`0*byte`:``]
 
 Rationale and Requirements are the same as listed above,
 for [`accept_channel`](#the-accept_channel-message) with the following
@@ -1205,6 +1219,12 @@ additions.
 The accepting node:
   - MUST use the `temporary_channel_id` of the `open_channel2` message
   - MAY respond with a `funding_satoshis` value of zero.
+  - If it requires the opening node to only use confirmed inputs:
+    - MUST set `require_confirmed_inputs`
+
+The receiving node:
+  - MUST fail the negotiation if:
+    - `require_confirmed_inputs` is set but it cannot provide confirmed inputs
 
 #### Rationale
 
@@ -1225,7 +1245,11 @@ protocol, with the following additional caveats.
 
 #### The `tx_add_input` Message
 
-No additional caveats or requirements.
+##### Requirements
+
+The sending node:
+  - if the receiver set `require_confirmed_inputs` in `open_channel2` or `accept_channel2`:
+    - MUST NOT send a `tx_add_input` that contains an unconfirmed input
 
 #### The `tx_add_output` Message
 
@@ -1250,12 +1274,15 @@ Upon receipt of consecutive `tx_complete`s, the receiving node:
         `open_channel2`.`funding_satoshis` and `accept_channel2`.
         `funding_satoshis`
       - the value of the funding output is less than the `dust_limit`
- - if it is an RBF attempt:
+  - if it is an RBF attempt:
     - MUST fail the negotiation if:
       - the transaction's total fees is less than the last
         successfully negotiated transaction's fees
       - the transaction does not share a common input with all previous
         funding transactions
+  - if it has sent `require_confirmed_inputs` in `open_channel2` or `accept_channel2`:
+    - MUST fail the negotiation if:
+      - one of the inputs added by the other peer is unconfirmed
 
 ### The `commitment_signed` Message