blip-0033: commit fees channel flag

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,129 @@
+```
+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.
+
+## Reference Implementations
+
+* eclair:
+  * <https://github.com/ACINQ/eclair/pull/2845>
+  * <https://github.com/ACINQ/eclair/pull/2861>