From 32a76e80c737155db196ec96a27395fd27586260 Mon Sep 17 00:00:00 2001 From: t-bast Date: Mon, 28 Feb 2022 23:40:31 +0100 Subject: [PATCH] Echo channel_type in accept_channel One argument for adding a feature bit for channel types was to make things more explicit and remove ambiguity. When sending `open_channel`, we require funders to include a `channel_type`, so it would make sense to require fundees to echo that `channel_type` back to explicitly confirm that they're ok with this `channel_type`. --- 02-peer-protocol.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index c0bf2a0..1779b08 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -348,8 +348,8 @@ The sender: avoid double-spending of the funding transaction. - MUST set `channel_reserve_satoshis` greater than or equal to `dust_limit_satoshis` from the `open_channel` message. - MUST set `dust_limit_satoshis` less than or equal to `channel_reserve_satoshis` from the `open_channel` message. - - if it sets `channel_type`: - - MUST set it to the `channel_type` from `open_channel` + - if `option_channel_type` was negotiated: + - MUST set `channel_type` to the `channel_type` from `open_channel` The receiver: - if `minimum_depth` is unreasonably large: @@ -360,6 +360,8 @@ The receiver: - MUST reject the channel. - if `channel_type` is set, and `channel_type` was set in `open_channel`, and they are not equal types: - MUST reject the channel. + - if `option_channel_type` was negotiated but the message doesn't include a `channel_type`: + - MAY reject the channel. Other fields have the same requirements as their counterparts in `open_channel`.