From 630bf989dbe6140d04273beb75e5c506aa03c50c Mon Sep 17 00:00:00 2001 From: Olaoluwa Osuntokun Date: Sun, 5 Dec 2021 16:35:35 -0800 Subject: [PATCH] BOLT-02+09: introduce feature bit to gate new channel_type feature (#906) 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 | 3 +++ 09-features.md | 1 + 2 files changed, 4 insertions(+) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 28a32ff45..36ece00a6 100644 --- a/02-peer-protocol.md +++ b/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. diff --git a/09-features.md b/09-features.md index 54cd2de6e..66234bc9c 100644 --- a/09-features.md +++ b/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