BOLT-02+09: introduce feature bit to gate new channel_type feature

In this commit, we add a new feature bit to gate the new explicit
channel type funding via the new `channel_type` TLV. The addition of
this new bit allows peers to seek out other peers that understand the
new explicit channel negotiation. This is useful in practice, as it
allows peers to avoid needing to "downgrade" the feature bits advertised
at the connection level due to one peer not understanding a new
required feature bit while it has a channel with a connecting peer.

Such a workaround is already deployed on the network between lnd peers
and certain eclair peers, as the `lnd` peers require static key, but the
feature bit is unknown to eclair peers. This situation (forced
downgrade) is undesirable, as until the connected peer updates (or the
channel is closed) and "worst" feature bit set must always be advertised
in order to maintain connectivity.

The other benefit of adding this feature bit is that it allows
implementations to simplify their code by ensuring that the new feature
will be used before sending any messages that include or reference that
feature. Without a feature bit, peers are instead forced to essentially
guess if a peer understands that feature, with logic to be able to "bail
out" of an invalid state.

The addition of this feature bit matches the prior precedent of adding
feature bits when new fields in the channel negotiation message (last
one was upfront shutdown) are added.

02-peer-protocol.md

@@ -233,6 +233,8 @@ The sending node:
     - MAY include `upfront_shutdown_script`.
   - if it includes `open_channel_tlvs`:
     - MUST include `upfront_shutdown_script`.
+  - if `option_channel_type` is negotiated:
+    - MUST set `channel_type`
   - if it includes `channel_type`:
     - MUST set it to a defined type representing the type it wants.
     - MUST use the smallest bitmap possible to represent the channel type.
@@ -252,6 +254,7 @@ The receiving node MUST:
     - discard the previous `open_channel` message.
 
 The receiving node MAY fail the channel if:
+  - `option_channel_type` was negotiated but the message doesn't include a `channel_type`
   - `announce_channel` is `false` (`0`), yet it wishes to publicly announce the channel.
   - `funding_satoshis` is too small.
   - it considers `htlc_minimum_msat` too large.

09-features.md

@@ -41,6 +41,7 @@ The Context column decodes as follows:
 | 20/21 | `option_anchor_outputs`          | Anchor outputs                                            | IN       | `option_static_remotekey` | [BOLT #3](03-transactions.md)         |
 | 22/23 | `option_anchors_zero_fee_htlc_tx` | Anchor commitment type with zero fee HTLC transactions   | IN       |                   | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful]|
 | 26/27 | `option_shutdown_anysegwit`         | Future segwit versions allowed in `shutdown`              | IN       |                   | [BOLT #2][bolt02-shutdown]   |
+| 44/45 | `option_channel_type`            | Node supports the `channel_type` field in open/accept     | IN       |                   | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
 
 ## Definitions