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

Support Channel Policies in Lightning Edges #227

Closed
carlaKC opened this issue Jan 18, 2024 · 2 comments · Fixed by #315
Closed

Support Channel Policies in Lightning Edges #227

carlaKC opened this issue Jan 18, 2024 · 2 comments · Fixed by #315

Comments

@carlaKC
Copy link
Contributor

carlaKC commented Jan 18, 2024

To allow more realistic mimicking of the real world lightning graph, add support for setting channel policies on lightning edges.

In lightning, one channel A ---- B will have two different sets of channel policies:

  • Set by A: applies to all payments sent A ----> B
  • Set by B: applies to all payments sent B ----> A

These can in theory be set on open, but it's difficult to do for the non-opening party (ie, when A opens to B, setting B's channel policy requires a complex interception API in LND. I'd suggest opening the channel fully and then using UpdateChannelPolicy to set each side of the channel's policy. One exception to this is the cltv_expiry_delta, which applies across channels. This can be set on a node level, and set in LND's config using --bitcoin.timelockdelta=.

Channel level policies -> Update Request API

  • Base fee rate -> base_fee_msat
  • Proportional fee rate -> fee_rate_ppm

These will need to be specified for the source and target node in the XML file.

Out of Scope/Bonus points:
Channel policies in LN take some time to propagate through the network. We can use GetChanInfo to check that the whole network has seen the update. This is more trouble that it's worth initially, but would certainly be a nice to have for setting the whole network up in a known starting state.

@pinheadmz
Copy link
Contributor

I think the best place for this will be in the ln_init.py scenario. That script already has logic to wait for channel opens to confirm and send commands to the LN nodes.

@carlaKC
Copy link
Contributor Author

carlaKC commented Mar 12, 2024

For max_htlc_in_flight we can only (easily) set this value for the accepting party using a config option: default-remote-max-htlcs. I think that it makes sense to just set this on a per-node basis and be okay with one value per node (this happens anyway irl)

For the opening party it's sadly only available on the OpenChannel API, which is a little inconsistent (but is what it is).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

2 participants