blip-0033: commit fees channel flag

Standard lightning channels require the channel opener to pay the
mining fees for the commitment transaction and mutual close transaction.
This requirement forces the channel opener to contribute to the funding
transaction and makes it impossible to open channels by only purchasing
inbound liquidity from a remote node.

We want to allow nodes to opt into paying the commitment transaction
fees even though they're not the channel opener.

Author: t-bast

README.md

@@ -25,3 +25,4 @@ For more detail on the process, please read [bLIP-0001](./blip-0001.md) and
 | [10](./blip-0010.md)     | Podcasting 2.0            | Satoshis Stream             | Active |
 | [11](./blip-0011.md)     | NameDesc                  | Hampus Sjöberg              | Active |
 | [17](./blip-0017.md)     | Hosted Channels           | Anton Kumaigorodskiy        | Active |
+| [33](./blip-0033.md)     | Commit fees channel flag  | Bastien Teinturier          | Active |

blip-0033.md

@@ -0,0 +1,123 @@
+```
+bLIP: 33
+Title: Commit fees channel flag
+Status: Active
+Author: Bastien Teinturier <[email protected]>
+Created: 2024-07-02
+License: CC0
+```
+
+## Abstract
+
+Standard lightning channels require the channel opener to pay the mining fees
+for the commitment transaction and mutual close transaction. This requirement
+forces the channel opener to contribute to the funding transaction and makes
+it impossible to open channels by only purchasing inbound liquidity from a
+remote node.
+
+We want to allow nodes to opt into paying the commitment transaction fees even
+though they're not the channel opener.
+
+## Copyright
+
+This bLIP is licensed under the CC0 license.
+
+## Specification
+
+### `channel_flags` extension
+
+We extend the `channel_flags` field from `open_channel2`. The BOLTs only use
+the least-significant bit of that field, and require readers to ignore the
+remaining bits. We define the next bit to `non_initiator_pays_commit_fees`: if
+set, the acceptor will pay the mining fees of the commitment transaction, for
+the lifetime of the channel.
+
+### Requirements
+
+The channel opener:
+
+* MAY set `non_initiator_pays_commit_fees` when sending `open_channel2`.
+* If the receiver sends `accept_channel2`:
+  * MUST deduce the commitment fees from the remote node's channel balance.
+  * MUST NOT send `update_fee` for the lifetime of the channel.
+
+The channel acceptor:
+
+* If `non_initiator_pays_commit_fees` is set in `open_channel2`:
+  * MUST fail the channel if it doesn't want to pay the commitment fees.
+  * Otherwise:
+    * MUST respond with `accept_channel2`.
+    * MUST contribute to the funding transaction.
+    * MUST deduce the commitment fees from its channel balance.
+    * SHOULD send `update_fee` when it wants to update the feerate of the
+      commitment transaction.
+
+When exchanging `shutdown` without `option_simple_close`:
+
+* If `non_initiator_pays_commit_fees` is set:
+  * The node responsible for paying the commitment fees is also responsible
+    for paying the mutual close fees.
+  * The node responsible for paying the commitment fees sends `closing_signed`
+    first.
+
+### Rationale
+
+We don't define a feature bit to signal support for receiving this new channel
+flag, because this feature doesn't make sense alone: protocols that need this
+channel flag must explicitly mention that they include support for receiving
+this flag.
+
+Some messages that should be sent first by the channel opener are instead sent
+first by the node paying the commitment fees wherever it makes sense. This is
+the case for `update_fee` (since the node paying that fee should decide on the
+feerate) and `closing_signed`.
+
+### Test vectors
+
+The following test vectors describe how the `channel_flags` byte should be
+encoded depending on the values set:
+
+```json
+[
+  {
+    "channel_flags": {
+      "announceChannel": false,
+      "non_initiator_pays_commit_fees": false
+    },
+    "encoded": "0x00"
+  },
+  {
+    "channel_flags": {
+      "announceChannel": true,
+      "non_initiator_pays_commit_fees": false
+    },
+    "encoded": "0x01"
+  },
+  {
+    "channel_flags": {
+      "announceChannel": false,
+      "non_initiator_pays_commit_fees": true
+    },
+    "encoded": "0x02"
+  },
+  {
+    "channel_flags": {
+      "announceChannel": true,
+      "non_initiator_pays_commit_fees": true
+    },
+    "encoded": "0x03"
+  }
+]
+```
+
+## Motivation
+
+This feature would typically be used by mobile wallets purchasing liquidity
+from their service provider. This allows mobile wallet users to onboard the
+lightning network without requiring them to own and use a utxo. Since they
+are purchasing liquidity, the service provider is incentivized to accept the
+burden of paying the commitment fees.
+
+This BLIP won't be necessary anymore once commitment transactions start using
+[TRUC](https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki)
+transactions and don't need to include mining fees.