Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Echo channel_type in accept_channel #960

Merged
merged 1 commit into from
Mar 14, 2022

Conversation

t-bast
Copy link
Collaborator

@t-bast t-bast commented Feb 17, 2022

One argument for adding a feature bit for channel types was to make things more explicit and remove ambiguity (the other main argument was to be able to filter out peers that don't support this feature).

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 particular channel_type.

This is the current behavior of eclair, please let me know if other implementations are doing it differently, and if you think this additional requirement shouldn't be added.

Copy link
Collaborator

@TheBlueMatt TheBlueMatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We technically currently violate this, but we'll fix it ASAP. I have no qualms with this being enforced over the coming months.

Copy link
Contributor

@vincenzopalazzo vincenzopalazzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 9bc97ff

Copy link
Collaborator

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🪁

@Roasbeef
Copy link
Collaborator

Spec meeting comment, waiting for someone from CL to confirm: cc @niftynei @rustyrussell -- can merge at will once confirmed.

@@ -348,6 +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 `option_channel_type` was negotiated:
- MUST set `channel_type`
- if it sets `channel_type`:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this not the same as the requirement the two lines below? is option_channel_type being negotiated different from 'setting channel_type'?

  - if it sets `channel_type`:

is the same as

- if `option_channel_type` was negotiated

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

anyway, clightnng enforces the draft, which is "if the opener sends a channel_type, we reply with a channel type.

Copy link
Collaborator Author

@t-bast t-bast Feb 28, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's not quite the same: we never explicitly said here that having negotiated option_channel_type means we must set it. But if I understand you correctly, instead of adding two new lines I could just enrich the two lines below to more explicitly say that you MUST set channel type to what was in the open_channel, is that right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know if 584b03e is better, I modified the existing requirement to clarify it instead of adding a new one on top

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep that's great -- thanks!

@niftynei
Copy link
Collaborator

concept ACK, but change NACK: is already expressed in the spec (but maybe needs rewording)

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`.
@t-bast t-bast force-pushed the accept-channel-type branch from 9bc97ff to 584b03e Compare February 28, 2022 22:40
@niftynei
Copy link
Collaborator

niftynei commented Mar 1, 2022

ACK 584b03e

- 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`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, this isn't quite right, anymore. Recall that the feature was added after the channel_type stuff was, thus, the "authoritative" data is the channel_type field, not the feature. It feels strange to remove the mention of setting the type here if you don't negotiate the feature.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recall that the feature was added after the channel_type stuff was, thus, the "authoritative" data is the channel_type field, not the feature.

That's true, but since now all implementations do use the feature bit, this is a historical artifact that can be removed from the spec, isn't it? Now that there is a feature bit, it does simplify requirements to always use it

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really? There are releases of node software that does not set the feature bit and expects the channel_type flags as sent to determine the channel type. I'd rather keep the channel_type so that we're clear on how things work, including with some nodes on the network.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that sounds reasonable (and matches my first version of this PR). @niftynei does that work for you, since you requested changes in the initial version?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it feels like the mention of the feature flag is unnecessary? is there ever a case where the feature flag will be set but there won't be a channel_type to mirror back in the accept?

maybe i'm unclear on what case we're solving for here, apologies.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the whole point of this PR, previously we didn't require the channel_type be set even if the feature flag is, but, as you note its somewhat nonsensical for that to happen. This PR simply fixes that oversight and says "yea, if you negotiate the feature that says you support this, you MUST support this, yo"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then the change belongs on the open channel message, not the accept message.

The accept message behavior is unchanged and the existing spec should be sufficient.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No? The change here is about the channel_type field in the accept message. The current spec only says that if you set channel_type in accept then it has to be a specific value, it never says anything about when you have to include the channel_type to begin with.

Copy link
Collaborator

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(clicked button again, ignore this)

@niftynei
Copy link
Collaborator

ACK 584b03e

@niftynei niftynei merged commit 32a76e8 into lightning:master Mar 14, 2022
@t-bast t-bast deleted the accept-channel-type branch March 24, 2022 07:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants