Implement local channel tracking by Router at channel_update #207

ariard · 2018-10-12T01:32:17Z

Add test_channel_update_local_channel

Issue #149

ariard · 2018-10-12T02:08:21Z

A lot of shorts locks picking, maybe need some more care.

TheBlueMatt · 2018-10-15T21:44:44Z

I don't think calling into the Router from ChannelManager is the right approach here - better to keep this data in the Channel up-to-date and expose it via list_channels().

…

On October 12, 2018 2:08:37 AM UTC, ariard ***@***.***> wrote: A lot of shorts locks picking, maybe need some more care. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #207 (comment)

ariard · 2018-11-16T02:15:39Z

Heyy I rebased this stuff and changed some to avoid useless lock but sorry don't understand your last comment because how PeerHandler is supposed to filter our local channels to Router without accessing ChannelManager channels ? Need handle_local_channel on ChannelMessageHandler to get them no ?

TheBlueMatt · 2018-11-16T16:51:30Z

My point was that we shouldn't even need to modify the Router DB for this - we should keep the fee knowledge in the Channel object itself and then the user can use list_usable_channels()'s return value as a get_route() argument and we can use the info in get_route that way. Would need a little bit of augmentation of the information provided in ChannelDetails to include feerate information, but I think we'd have less layer violations that way (Router shouldn't need to know about what channels are ours).

ariard · 2018-11-17T03:06:12Z

Hmm so #149 is about using feerates from ChannelDetails to improve get_route ? Sorry last comment doesn't align with your first comment in #149 "I think the obvious solution is to track local channels in Router"..

TheBlueMatt · 2018-11-21T05:15:48Z

Ugh, oops, indeed, not sure if I misspoke or just thought different when I wrote that but it seems like a nontrivial layer violation (and one that would make it harder to stub in a custom router) to do it that way?

…

On Nov 16, 2018, at 22:06, ariard ***@***.***> wrote: Hmm so #149 is about using feerates from ChannelDetails to improve get_route ? Sorry last comment doesn't align with your first comment in #149 "I think the obvious solution is to track local channels in Router".. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

ariard · 2018-12-07T02:40:21Z

Rebased and updated with IRC comments (11-21-2018)

TheBlueMatt

Nice! This looks good modulo a few small things to fix.

TheBlueMatt · 2018-12-11T21:35:31Z

src/ln/channel.rs

@@ -2040,6 +2046,14 @@ impl Channel {

 	}

+	/// Set channel fields with remote peer forwarding parameters, used mainly by ChannelDetails to feed the Router
+	pub fn channel_update(&mut self, msg: &msgs::ChannelUpdate) {
+		self.their_to_self_delay = msg.contents.cltv_expiry_delta;


to_self_delay is the time before their commitment transaction loses the CSV delay, CLTV_EXPIRY_DELTA is the required difference between an incoming HTLC and the corresponding outgoing HTLC, they're very different values.

urgh, ugly from my part, corrected, was thinking to_self_delay was CLTV_EXPIRY_DELTA while writing this by distraction, even if I'm pretty sure I used it correctly as CSV in others times

TheBlueMatt · 2018-12-11T21:37:44Z

src/ln/channel.rs

+	/// Set channel fields with remote peer forwarding parameters, used mainly by ChannelDetails to feed the Router
+	pub fn channel_update(&mut self, msg: &msgs::ChannelUpdate) {
+		self.their_to_self_delay = msg.contents.cltv_expiry_delta;
+		self.their_htlc_minimum_msat = msg.contents.htlc_minimum_msat;


This should be sanity-checked against funding_satoshis (see new_from_req), and while ideally we'd sanity-check against the channel_limits we dont keep those around and I think its probably OK to let counterparties update such things if they need to temporarily disable a channel. This needs to be documented in Config, though, noting that a counterparty can increase this value once the channel is established beyond the minimum, but this is equivalent to them just rejecting all HTLCs so we can't enforce it anyway.

Okay, added comments in Config and sanity-check against channel_value_satoshis (funding_satoshis) and if fail reject the whole update, but should we send back a ChannelError:Close here, or as you said interpret it as temporary disabling of channel?

I think if they send back something completely bogus, nothing wrong with a ChannelError::Close.

Updated, but don't do comparison for others fields because I think we don't have reference bases

TheBlueMatt · 2018-12-11T21:39:00Z

src/ln/channelmanager.rs

@@ -2776,6 +2792,17 @@ impl ChannelMessageHandler for ChannelManager {
 		handle_error!(self, self.internal_announcement_signatures(their_node_id, msg), their_node_id)
 	}

+	fn handle_channel_update(&self, msg: &msgs::ChannelUpdate) -> Result<(), HandleError> {
+		let mut channel_state_lock = self.channel_state.lock().unwrap();


While technically I think its safe without it, probably best to keep consistency and add a total_consistency_lock.read().unwrap() at the top.

TheBlueMatt · 2018-12-11T21:39:08Z

src/ln/channelmanager.rs

@@ -8130,4 +8157,5 @@ mod tests {
 		assert_eq!(spend_txn.len(), 1);
 		check_spends!(spend_txn[0], closing_tx);
 	}
+


nit: stray newline.

TheBlueMatt · 2018-12-13T02:50:57Z

src/ln/channelmanager.rs

+		let channel_state = channel_state_lock.borrow_parts();
+		if let Some(channel_id) = channel_state.short_to_id.get(&msg.contents.short_channel_id) {
+			if let Some(chan) = channel_state.by_id.get_mut(channel_id) {
+				chan.channel_update(&msg);


Need to check the source of the message ie their_node_id as in all the other handler functions.

So refactored function with an internal part to catch easily MsgHandleErrInternal

TheBlueMatt

Oops, sorry, guess I didnt give this one a good shake, why are you tracking the HTLC minimum and fee info? See comment on get_route but the fees a node takes are always calculated on the basis of the announced fees for a given outbound channel. ie the channels from us dont matter for fee calculation, only the HTLC minimum needs to be respected.

TheBlueMatt · 2018-12-14T23:19:49Z

Also this needs the corresponding updates in get_route so that we do enforce that requirement.

ariard · 2018-12-15T00:50:55Z

Was thinking we needed to track our local channel to do cycle payment to ourselves, because BOLT 7 say "SHOULD accept channel_updates for its own channels (even if non-public), in order to learn the associated origin nodes' forwarding parameters". If we have topology A <--> B <--> C, what does forwarding parameters mean here ? Policy apply by B on link B -> C, or on link A <- B, or on link A -> B as relaying node ? Because if it means the last option, HTLC minimum_msat on A -> B is useless as it gonna be also enforced on B -> C (and seems to me that what really interested us is the lowest HTLC_minimum_msat of the whole payment route)

TheBlueMatt · 2018-12-15T04:34:23Z

Hmmmmmm, now I'm really confused. That requirement in the spec may be bogus. At a high level, if A is routing via B to C, the only fees taken are by B and they are the fees B announces on the B->C channel (the rationale being its up to A/the source of an HTLC to figure out what they want to charge to forward along a route, ie you care about the action of forwarding, not accepting). That said, the htlc_minimum_msat value is defined as "the minimum HTLC value (in millisatoshi) that the channel peer will accept" ie B should be announcing the value that we sent it in our channel_open/channel_accept, and I dont see a way to change this value at runtime, so maybe the "SHOULD accept channel_updates for its own channels (even if non-public), in order to learn the associated origin nodes' forwarding parameters." requirement is just bogus? Probably worth asking some other folks and investigating what others do and fixing the spec to make it much clearer in any case.

In any case we definitely need include our counterparty's current htlc_minimum_msat in route calculations (and need some tests for route calculations with htlc_minimums).

TheBlueMatt · 2021-03-04T00:50:54Z

The spec isn't wrong here, but its kinda a layer violation implied - I believe its really about learning the inbound fees so that you can include them in route hints in invoices. There's no other reason we'd need that data, but, indeed, route hints are important.

valentinewallace · 2021-03-12T22:25:16Z

Superseded by #841 :)

ariard force-pushed the 149-local_channel_tracking_route_gen branch from 5dbf16e to 8501947 Compare November 16, 2018 02:11

ariard force-pushed the 149-local_channel_tracking_route_gen branch from 8501947 to c13ee0f Compare December 7, 2018 02:38

TheBlueMatt reviewed Dec 11, 2018

View reviewed changes

ariard force-pushed the 149-local_channel_tracking_route_gen branch from c13ee0f to 3333e6d Compare December 13, 2018 01:27

TheBlueMatt reviewed Dec 13, 2018

View reviewed changes

Track remote peer forwarding parameters for local channel

1b6093f

ariard force-pushed the 149-local_channel_tracking_route_gen branch from 3333e6d to 1b6093f Compare December 14, 2018 01:12

TheBlueMatt reviewed Dec 14, 2018

View reviewed changes

TheBlueMatt added the Needs BOLT Clarification label Dec 30, 2018

TheBlueMatt removed the Needs BOLT Clarification label Mar 4, 2021

TheBlueMatt mentioned this pull request Mar 4, 2021

Expose channel fees in ChannelDetails #824

Closed

TheBlueMatt added this to the 0.0.14 milestone Mar 8, 2021

valentinewallace mentioned this pull request Mar 12, 2021

Expose counterparty forwarding info in ChannelDetails #841

Merged

valentinewallace closed this Mar 12, 2021

Implement local channel tracking by Router at channel_update #207

Implement local channel tracking by Router at channel_update #207

Uh oh!

Conversation

ariard commented Oct 12, 2018

Uh oh!

ariard commented Oct 12, 2018

Uh oh!

TheBlueMatt commented Oct 15, 2018 via email

Uh oh!

ariard commented Nov 16, 2018

Uh oh!

TheBlueMatt commented Nov 16, 2018

Uh oh!

ariard commented Nov 17, 2018

Uh oh!

TheBlueMatt commented Nov 21, 2018 via email

Uh oh!

ariard commented Dec 7, 2018

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt commented Dec 14, 2018

Uh oh!

ariard commented Dec 15, 2018

Uh oh!

TheBlueMatt commented Dec 15, 2018

Uh oh!

TheBlueMatt commented Mar 4, 2021

Uh oh!

valentinewallace commented Mar 12, 2021

Uh oh!

Uh oh!