From 7ee88e2062bd7b6af3edf5ab35556f40d7522ccb Mon Sep 17 00:00:00 2001 From: Olaoluwa Osuntokun Date: Tue, 31 Aug 2021 19:12:24 -0700 Subject: [PATCH] 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 | 3 +++ 09-features.md | 1 + 2 files changed, 4 insertions(+) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index b869f02a4..587d891bc 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