Set node alias #330

enigbe · 2024-07-25T17:39:35Z

What this PR does:

Adds a function to allow users set the node alias.
If set, ensures that the provided alias is broadcast with the node announcement

Related issue(s):

Allow to set node alias #304

tnull

Excuse the delay here!

Thank you for looking into this, approach already looks pretty good! Just a few comments.

src/builder.rs

src/lib.rs

tnull

Thanks! I think beyond checking for the node alias and listening addresses before broadcasting, we should also modify the default_user_config method in Config to, if any of the two are unconfigured:

a) set UserConfig::accept_forwards_to_priv_channels to false
b) set ChannelHandshakeConfig::announced_channel to false
c) set ChannelHandshakeLimits::force_announced_channel_preference to true

Additionally, we'll want to return an error from connect_open_channel if any of the two are unconfigured and we try to open an announced channel. To this end, it might be bit cleaner if we'd split the method in two (open_channel and open_announced_channel) rather than having it take a simple bool.

TLDR: We should use the configured listening addresses and node alias as indicators whether we are a forwarding node or not. If we're not, we should disallow announced channels.

Let me know if you'd be up for these additional changes, otherwise I'm happy to pick them up as a follow-up.

README.md

src/config.rs

src/lib.rs

enigbe · 2024-08-07T11:56:23Z

Thanks! I think beyond checking for the node alias and listening addresses before broadcasting, we should also modify the default_user_config method in Config to, if any of the two are unconfigured:

a) set UserConfig::accept_forwards_to_priv_channels to false b) set ChannelHandshakeConfig::announced_channel to false c) set ChannelHandshakeLimits::force_announced_channel_preference to true

Additionally, we'll want to return an error from connect_open_channel if any of the two are unconfigured and we try to open an announced channel. To this end, it might be bit cleaner if we'd split the method in two (open_channel and open_announced_channel) rather than having it take a simple bool.

TLDR: We should use the configured listening addresses and node alias as indicators whether we are a forwarding node or not. If we're not, we should disallow announced channels.

Let me know if you'd be up for these additional changes, otherwise I'm happy to pick them up as a follow-up.

Thanks for the review. I am happy to keep working on this until it is ready.

tnull · 2024-08-27T08:20:03Z

Thanks for the review. I am happy to keep working on this until it is ready.

Thanks again! Do you still intend to do this in this PR, or would you prefer we land this and do additional changes in a follow up?

Btw. this also needs a rebase already, and there will be larger code changes upcoming in the LDK/BDK/rust-bitcoin upgrade PR, which will likely also lead to further rebase conflicts.

enigbe · 2024-08-27T09:14:35Z

Thanks for the review. I am happy to keep working on this until it is ready.

Thanks again! Do you still intend to do this in this PR, or would you prefer we land this and do additional changes in a follow up?

Btw. this also needs a rebase already, and there will be larger code changes upcoming in the LDK/BDK/rust-bitcoin upgrade PR, which will likely also lead to further rebase conflicts.

Apologies for the delay. I am almost done and will be pushing changes today. I'll rebase and get it ready for another look before the end of the day.

tnull · 2024-08-27T09:27:21Z

Apologies for the delay. I am almost done and will be pushing changes today. I'll rebase and get it ready for another look before the end of the day.

No worries! Cool, thank you!

enigbe · 2024-08-29T09:10:54Z

Thanks for the review. I am happy to keep working on this until it is ready.

Thanks again! Do you still intend to do this in this PR, or would you prefer we land this and do additional changes in a follow up?
Btw. this also needs a rebase already, and there will be larger code changes upcoming in the LDK/BDK/rust-bitcoin upgrade PR, which will likely also lead to further rebase conflicts.

Apologies for the delay. I am almost done and will be pushing changes today. I'll rebase and get it ready for another look before the end of the day.

Hi @tnull, I have rebased and pushed recommended changes. Unfortunately, the integration tests are flaky and I am uncertain about why. Currently investigating.

enigbe · 2024-09-05T08:55:11Z

Thanks for the review. I am happy to keep working on this until it is ready.

Thanks again! Do you still intend to do this in this PR, or would you prefer we land this and do additional changes in a follow up?
Btw. this also needs a rebase already, and there will be larger code changes upcoming in the LDK/BDK/rust-bitcoin upgrade PR, which will likely also lead to further rebase conflicts.

Apologies for the delay. I am almost done and will be pushing changes today. I'll rebase and get it ready for another look before the end of the day.

Hi @tnull, I have rebased and pushed recommended changes. Unfortunately, the integration tests are flaky and I am uncertain about why. Currently investigating.

Hi @tnull, thanks for your review so far. Have you had some time to check out the recent changes I have made? I have addressed the comments raised and would be grateful for any further feedback or recommendation.

tnull

Hi @tnull, thanks for your review so far. Have you had some time to check out the recent changes I have made? I have addressed the comments raised and would be grateful for any further feedback or recommendation.

Excuse the delay here! Did another round, already looks pretty good, just a few comments.

To make CI pass you'll need to adjust all prior uses of connect_open_channel/connectOpenChannel in the bindings tests (i.e., in bindings/kotlin/ldk-node-jvm/lib/src/test/kotlin/org/lightningdevkit/ldknode/LibraryTest.kt for Kotlin and bindings/python/src/ldk_node/test_ldk_node.py for Python).

There are also a few references to connect_open_channel left in tests and comments which should be renamed accordingly.

src/builder.rs

tnull · 2024-09-06T09:11:28Z

src/builder.rs

+mod tests {
+	use lightning::routing::gossip::NodeAlias;
+
+	use crate::{builder::sanitize_alias, BuildError};


nit: Given these tests are in a sub-module of builder, I think you don't need to import these types at all here?

src/config.rs

src/lib.rs

What this commit does: Implements a method `set_node_alias` on NodeBuilder to allow callers customize/set the value of the node alias. This method sanitizes the user-provided alias by ensuring the following: + Node alias is UTF-8-encoded String + Node alias is non-empty + Node alias cannot exceed 32 bytes + Node alias is only valid up to the first null byte. Every character after the null byte is discraded Additionally, a test case is provided to cover sanitizing empty node alias, as well as an alias with emojis (copied and modified from rust-lightning) and a sandwiched null byte.

What this commit does: Broadcasts node announcement with the user-provided alias, if set, else, uses the default [0u8;32]. Additionally, adds a random node alias generating function for use in the generation of random configuration.

alias sanitization - Skips broadcasting node announcement in the event that either the node alias or the listening addresses are not set. - Aligns the InvalidNodeAlias error variant with the others to make it work with language bindings. - Simplifies the method to set the node alias. - Cleans up the alias sanitizing function to ensure that protocol- compliant aliases (in this case, empty strings) are not flagged. Additionally, removes the check for sandwiched null byte. - Finally, adds the relevant update to struct and interface to reflect changes in Rust types.

…onfigured

What this commit does: + Updates the sanitization function for node alias to return NodeAlias + Updates the node alias type in the configuration to NodeAlias and implements a conversion to/from String for bindings + With this update, regardless of where the alias is set, i.e. in the set_node_alias or directly, sanitization occurs.

What this commit does: + Decomposes connect_open_channel into two different functions: open_channel and open_announced_channel. This allows opening announced channels based on configured node alias and listening addresses values. + This enforces channel announcement only on the condition that both configuration values are set. + Additionally, a new error variant `OpenAnnouncedChannelFailed` is introduced to capture failure. Note: I thought I added the `InvalidNodeAlias` variant in the previous commit

What this commit does: + Replaces calls to `connect_open_channel` with `open_channel` and `open_announced_channel` where appropriate. Status: Work In Progress (WIP) Observation: + The integration tests are now flaky and need further investigation to ascertain the reason(s) why and then to fix.

What this commit does: + Removes the wrapping Arc from the channel config. This is a missed update after rebasing.

This commit addresses changes necessary to: - fix failing tests for generated bindings - remove unnecessary error variant previously introduced to capture failure associated with opening announced channels, and re-use existing variants that better capture the reasons, i.e. `InvalidNodeAlias` and `InvalidSocketAddress`, why opening an announced channel failed. - correct visibility specifiers for objects, and - cleanup nitpicks Specific modifications across several files include: - updating the UDL file, as well as tests related to python and kotlin that call `open_channel` and/or open_announced_channel - repositioning/rearranging methods and struct fields - introducing enums (`ChannelAnnouncementStatus` & `ChannelAnnouncementBlocker`) to capture and codify channel announceable eligibility, providing reasons for unannounceable channels - modifying `can_announce_channel` to utilize the aforementioned enums, as opposed to simply returning a boolean value. - cleaning up and renaming `connect_open_channel` to `open_channel_inner`, and maintaining a boolean flag for channel announcement - updating documentation, unit, and integration tests that factor all these changes

tnull · 2024-09-26T03:00:26Z

Seems CI is failing. Let me know when this is ready for another round of review!

… addresses This commit addresses flaky test issues related to conditional channel opening between nodes, considering node aliases and listening addresses. Changes in test modules: - Add/modify helper functions to randomize channel announcement flags - Generate random node aliases based on announcement flags: * Set custom alias if announce_channel is true * Use default alias otherwise - Update channel opening logic to account for node and channel announcements

enigbe · 2024-09-27T10:54:05Z

Seems CI is failing. Let me know when this is ready for another round of review!

I have made some changes to address flaky tests that were failing in CI. They are all passing now with the exception of Rust Tests / build(windows-latest, 1.63.0) which runs endlessly until it is cancelled. It appears stuck building the project.

I am currently investigating it. I would be grateful for another review while I try to fix the build.

Edit:

I was able to replicate the issue locally (on Windows 11 Home) using rust 1.63.0. The build consistently hangs while compiling the secp256k1-sys crate (see image below).

If you have time, it would be helpful if you could try running the build locally to see if it's replicable or investigate whether this is related to a specific environment setup.

I am uncertain about why this is happening but I will keep looking into known issues related to secp256k1-sys on this version of rust.

tnull

Thanks and excuse the delay once more! This generally LGTM, although I found a few nits and disgree with the test changes in the last commit. I think I'll land this as is and address the changes in a quick follow-up as we're expecting considerable changes across the codebase in #358 and follow-up PRs, which would likely make rebasing this over and over again pretty painful.

src/builder.rs

src/config.rs

src/lib.rs

src/config.rs

tests/common/mod.rs

tests/integration_tests_rust.rs

tnull · 2024-10-07T12:58:54Z

Now opened a follow-up PR to address the remaining feedback here: #366

enigbe · 2024-10-17T07:31:55Z

Thank you @tnull for your patient review of this and for cleaning up the nits in #366.

tnull · 2024-10-17T08:06:08Z

Thank you @tnull for your patient review of this and for cleaning up the nits in #366.

Sure, I hope you don't mind I tackled them in a follow-up. I mainly wanted to make sure this lands in 0.4 and wanted to spare you the rebase conflicts that would have ensued..

enigbe mentioned this pull request Jul 25, 2024

Allow to set node alias #304

Closed

enigbe changed the title ~~Set node alias~~ WIP: Set node alias Jul 29, 2024

tnull reviewed Jul 30, 2024

View reviewed changes

src/builder.rs Outdated Show resolved Hide resolved

src/builder.rs Outdated Show resolved Hide resolved

src/builder.rs Outdated Show resolved Hide resolved

src/builder.rs Outdated Show resolved Hide resolved

src/lib.rs Outdated Show resolved Hide resolved

enigbe force-pushed the feat-set-node-alias branch from 63e791a to 8791d7c Compare August 6, 2024 12:35

enigbe changed the title ~~WIP: Set node alias~~ Set node alias Aug 6, 2024

enigbe marked this pull request as ready for review August 6, 2024 14:48

tnull reviewed Aug 7, 2024

View reviewed changes

enigbe force-pushed the feat-set-node-alias branch from cfd764b to 3775bad Compare August 29, 2024 07:41

enigbe requested a review from tnull August 29, 2024 09:07

tnull reviewed Sep 6, 2024

View reviewed changes

enigbe added 12 commits September 23, 2024 22:56

feat: broadcast node announcement with set alias

e54bfe0

What this commit does: Broadcasts node announcement with the user-provided alias, if set, else, uses the default [0u8;32]. Additionally, adds a random node alias generating function for use in the generation of random configuration.

docs: clarify node announcement broadcast logic

8e73296

refactor: update UserConfig if node alias/listening addresses are unc…

7ad7029

…onfigured

docs: cleanup documentation

059a30e

fix: change channel config type in open_(announced)_channel

1160034

What this commit does: + Removes the wrapping Arc from the channel config. This is a missed update after rebasing.

fix: remove broken intra doc link

6c3deaf

fix: remove unstable feature is_some_and

6aff282

enigbe force-pushed the feat-set-node-alias branch 2 times, most recently from c2589f3 to a740401 Compare September 24, 2024 08:12

enigbe force-pushed the feat-set-node-alias branch from a740401 to 0af5df6 Compare September 24, 2024 09:54

enigbe force-pushed the feat-set-node-alias branch 2 times, most recently from 59f77b2 to 5d5d1cd Compare September 26, 2024 23:16

enigbe force-pushed the feat-set-node-alias branch from 5d5d1cd to 4fd1cb8 Compare September 27, 2024 09:07

enigbe requested a review from tnull September 27, 2024 10:54

tnull approved these changes Oct 7, 2024

View reviewed changes

tnull merged commit c9ebeb6 into lightningdevkit:main Oct 7, 2024
12 of 13 checks passed

tnull mentioned this pull request Oct 7, 2024

Follow-ups to #330 #366

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Set node alias #330

Set node alias #330

enigbe commented Jul 25, 2024

tnull left a comment

tnull left a comment

enigbe commented Aug 7, 2024

tnull commented Aug 27, 2024 •

edited

Loading

enigbe commented Aug 27, 2024

tnull commented Aug 27, 2024

enigbe commented Aug 29, 2024

enigbe commented Sep 5, 2024

tnull left a comment

tnull Sep 6, 2024

tnull commented Sep 26, 2024

enigbe commented Sep 27, 2024 •

edited

Loading

tnull left a comment

tnull commented Oct 7, 2024

enigbe commented Oct 17, 2024

tnull commented Oct 17, 2024

Set node alias #330

Set node alias #330

Conversation

enigbe commented Jul 25, 2024

What this PR does:

Related issue(s):

tnull left a comment

Choose a reason for hiding this comment

tnull left a comment

Choose a reason for hiding this comment

enigbe commented Aug 7, 2024

tnull commented Aug 27, 2024 • edited Loading

enigbe commented Aug 27, 2024

tnull commented Aug 27, 2024

enigbe commented Aug 29, 2024

enigbe commented Sep 5, 2024

tnull left a comment

Choose a reason for hiding this comment

tnull Sep 6, 2024

Choose a reason for hiding this comment

tnull commented Sep 26, 2024

enigbe commented Sep 27, 2024 • edited Loading

Edit:

tnull left a comment

Choose a reason for hiding this comment

tnull commented Oct 7, 2024

enigbe commented Oct 17, 2024

tnull commented Oct 17, 2024

tnull commented Aug 27, 2024 •

edited

Loading

enigbe commented Sep 27, 2024 •

edited

Loading