bitcoin-dev-project/warnet

Support Channel Policies in Lightning Edges

Closed this issue · 2 comments

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.

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.

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).